Taggat med: Trend Micro

Priser på zero-days

zero days

Det är intressant att titta på prislistor när det gäller zero-days. För den som inte är insatt så kan du få betalt för att identifiera nya sårbarheter och sedan skriva verktyg som utnyttjar dessa med programkod (exploit). Och vice versa så kan du betala för att köpa zero-days.

När du identifierat en (eller flera) sårbarhet och skrivit en exploit så kan du sedan sälja denna till företag såsom Zerodium och Exodus eller använda den vid Pwn2own-tävlingen.

Vad företag som Zerodium sedan gör med zero-dayen när de köpt den är troligtvis att de säljer den vidare till företag såsom Hacking Team eller myndigheter.

Men varför är priser på zero-days så intressant? Jo, för att pengar går att omsätta i tid och resurser. För att någon ska vilja ta sig in i din iPhone så ska de betala 13 miljoner SEK, något förenklat.

Och varför skulle någon vilja betala 13M SEK för att ta sig in i en iPhone? Detta beror på att målobjektet som någon är ute efter använder just en iPhone samt att säkerheten är så pass god. Samt att det verkligen måste spenderas mycket resurser för att lyckas utnyttja en eller flera brister. Andra saker att beakta är interaktionen som behövs för att erhålla kodexekvering, utbrytning ur sandlåda och persistens. Behövs det fysisk tillgång till telefonen eller räcker det med att skicka ett SMS?

Därför lägger även de som köper zero-days även resurser på att försöka sopa igen spåren efter att den utnyttjas med hjälp av anti-forensik. För de vill så klart ha möjlighet att använda zero-dayen mer än endast en gång.

Följande tabell visar på några av prispengarna vid tävlingen Pwn2own som anordnas av The Zero Day Initiative (ZDI), numera ägs av företaget Trend Micro:

Server Side 

  • Apache Web Server on Ubuntu Server – $200,000 (USD)

Virtual Machine Escape (Guest-to-Host)

  • VMware Workstation: $100,000 (USD)
  • Microsoft Hyper-V: $100,000 (USD)

Local Escalation of Privilege

  • Microsoft Windows 10: $30,000 (USD)
  • Apple macOS: $20,000 (USD)
  • Ubuntu Desktop: $15,000 (USD)

Web Browser and Plugins

  • Microsoft Edge: $80,000 (USD)
  • Google Chrome: $80,000 (USD)
  • Mozilla Firefox: $30,000 (USD)
  • Apple Safari: $50,000 (USD)
  • Adobe Flash in Microsoft Edge: $50,000 (USD)

Så upptäckte säkerhetsloggning med OSSEC ett intrång

Detta är en historia om hur min säkerhetsloggning som bl.a. bygger på OSSEC identifierade ett intrång på en av mina webbservrar.

OSSEC är öppen källkod och går under licensen GNU GPLv2 och utvecklades från början av Daniel Cid och företaget Third Brigade som sedermera blev uppköpta av Trend Micro. Dock så lovade Trend Micro att fortsätta hålla OSSEC som öppen källkod, vilket det fortfarande är.

OSSEC är en mjukvara som går under kategorin HIDS (host-based intrusion detection system) och har bl.a. funktioner för att analysera loggfiler efter suspekta mönster, detektera rootkits och utföra aktiva åtgärder såsom att blockera i brandvägg.


Det går att installera OSSEC som fristående installationer på varje server och sedan skicka vidare larm med hjälp av rsyslog, syslog-ng eller filebeat (föredetta logstash-forwarder) eller använda OSSEC:s inbyggda funktionalitet för att skicka loggar krypterat. Det finns även Windows-klienter till OSSEC.

Jag har konfigurerat OSSEC som en tripwire-funktionalitet, dvs att OSSEC kontrollerar checksummor på viktiga filer. Eftersom många webbattacker går ut på att modifiera webbsidor så har jag även lagt in så att OSSEC-larmar på förändringar i filer som ligger under webbkataloger. Standard så kontrollerar OSSEC enbart integritet på ett antal viktiga systemfiler, därför är det viktigt att lägga till ytterligare filer som du vill hålla koll på.

Jag brukar lägga till ungefär följande rad i /var/ossec/etc/ossec.conf filen:

 <directories realtime="yes" report_changes="yes" restrict=".htaccess|.php|.html|.js">/var/www/domän.se/</directories>

Och även följande rad om du vill larma på nya filer:

<alert_new_files>yes</alert_new_files>

Skulle du få många nya larm om temporära filer som skapas i någon katalog så kan du alltid lägga ignore på den katalogen enligt följande:

<ignore>/var/www/katalognamn</ignore>

Men observera dock vilken katalog du ignorerar så inte det går att utnyttja av en angripare.

Vidare bör du ställa ner intervallet då övriga filer kontrolleras som är standard på 22h. Du gör det med följande rad i ossec.conf:

<frequency>14400</frequency>

Även så måste du ändra följande fil: /var/ossec/rules/local_rules.xml och lägga till följande rad för att få larm om nya filer:

<rule id=”554″ level=”7″ overwrite=”yes”>
<category>ossec</category>
<decoded_as>syscheck_new_entry</decoded_as>
<description>File added to the system.</description>
<group>syscheck</group>
</rule>

Det är för att regeln med id 554 standard är satt som level=”0″ vilket betyder att du inte får några larm.

Intrånget

Det larm som dök upp från OSSEC som fick mig att höja på ögonbrynen är följande:

Den som är observant på ovan larm ser att includ_once() är en felstavning av PHP-funktionen include_once(). Givetvis så kontrollerade jag filen manuellt och upptäckte då att någon hade manuellt modifierat footer.php. Detta är ett vanligt förekommande förfarande när det gäller hackade WordPress-installationer.

Efter vidare undersökning så identifierade jag Filesman-phpbakdörren men även en till bakdörr. Denna bakdörr la jag in min egen bakdörr i så att den loggade alla försök att utnyttja bakdörren samt att lösenordet till bakdörren loggades. Om du är intresserad av bakdörrar till php så kan du kolla in min samling på Github Gist här.

Du kan med fördel även importera larm från OSSEC till Splunk eller ELK-stacken (Elasticsearch, Logstash och Kibana).

Filesman PHP-bakdörr