zurück zum Artikel

Malware auf der Spur

Daniel Bachfeld

Kriminelle verschleiern die Spuren ihrer Malware im Internet mit diversen Methoden. Doch mit speziellen Tools kann man die Wege zurückverfolgen und herausfinden, über welche Schwachstelle ein Schädling eingedrungen ist.

Während man sich früher Viren und Trojaner über den Browser hauptsächlich nur beim Besuch dubioser Webseiten einfangen konnte, reicht dazu heute die Morgenlektüre auf einer populären News-Seite. Zuletzt installierten infizierte Werbebanner auf Handelsblatt.de und zeit.de über Browser-Lücken sogenannte Scareware. Dabei versteckten Kriminelle in Werbebannern ein spezielles JavaScript, die in einem Iframe weiteren Code nachluden, der seinerseits wieder auf eine andere Seite zeigte, wo dann letztlich das Exploit-Toolkit Neosploit verschiedene Lücken in den Plug-ins für QuickTime, Java und den Adobe Reader durchprobierte.

Um den eigentlichen Ursprungsort eines Angriff zu verschleiern, gehen die Kriminellen mehrstufig vor. Zum einen betten sie in gehackte Webseiten oder infizierte Flash-Werbebanner keine Links im Klartext ein, sondern codieren URLs über lange Zeichenketten, die ein Java- oder ActionScript erst wieder zur Laufzeit zusammenbaut – oft ist sogar das Skript selbst noch codiert. Zum anderen benutzen die Malware-Programmierer mehrfache Umleitungen, um den Browser über mehrere Sprünge zum eigentlichen Schadcode zu führen. Das alles hat den Zweck, sowohl Anwender als auch Webseitenbetreiber und sogar Antivirenspezialisten in die Irre zu führen und ihnen die Arbeit zu erschweren.

Glücklicherweise gibt es Tools und Hilfsmittel respektive Dienste, die für den Menschen so gut wie unlesbares JavaScript in mehr oder minder verständlichen Code zurückführen können. Damit kann man die Verfolgung aufnehmen oder zumindest nachvollziehen, welche Lücken die Angreifer versucht haben, auszunutzen. Die Tools Malzilla und Jode helfen bei der manuellen Analyse, während die Dienste jsunpack und wepawat mit ihrer automatischen Analyse dem Analysten zur Seite stehen. Wir stellen alle vier Werkzeuge kurz vor.

Das Windows-Tool Malzilla [1] hilft dem Malware-Jäger, der Bedeutung eines verschwurbelten (englisch obfuscated) JavaScripts in infizierten Webseiten auf die Schliche zukommen. Dazu lädt es nach Angabe der URL den kompletten HTML-Code herunter und zeigt ihn an. Grundsätzlich nutzen Virenautoren zwei Verfahren, um eingebettete Sprungziele, Nachlade-URLs und weiterer Code unleserlich zu machen. Eine einfache Methode ist beispielsweise, eine URL mittels Base64 oder über das Universal Character Set [2] (UCS) zu kodieren. Malzilla enthält eine Reihe von Dekodern, um solche Zeichenketten wieder zu dekodieren und für den Analysten lesbar zu machen.

Die andere Methode ist, eine URL erst zur Laufzeit per JavaScript anhand verschiedener Daten wieder zusammenzubauen. Malzilla kann die Ausführung von JavaScript jedoch emulieren und die Ergebnisse des Durchlaufs anzeigen. Nicht selten kombinieren die Virenautoren die beiden Methoden, sodass man mehrere Durchläufe in Malzilla benötigt, um der Malware auf die Spur zu kommen.

Im oberen Fenster zeigt Malzilla den geladenen HTML-Quelltext der Seite an. Verdächtige Einträge lassen sich meist bereits mit bloßem Auge erkennen.

Für erste Tests nimmt man die URL einer infizierten Webseite und trägt sie ins Adressfeld von Malzilla ein. Beispiele für eigene Experimente findet man auf Seiten wie www.malwaredomainlist.com oder www.malwareurl.com. Allerdings sollte man die dort angegebenen URLs nicht ohne spezielle Vorkehrungen im Browser öffnen. Malzilla trifft einige Vorkehrungen, um eine Infektion des Analyse-Systems zu verhindern. So führt es den Code mit speziellen JavaScript-Bibliotheken aus, die nicht die lokalen Ressourcen beeinflussen können. Ein Angreifer müsste also schon eine Lücke in Malzilla ausnutzen, um einen Trojaner einzuschleusen. Dennoch empfiehlt es sich nicht, den selben PC für Malware-Analysen und Online-Banking zu verwenden – man weiß ja nie. Besser ist es, die Tests in einer virtuellen Umgebung, etwa mit dem kostenlosen VirtualBox [3] durchzuführen.

Der Button "Get" ruft die eingegebene URL auf und Malzilla liest den kompletten HTML-Code ein. Im Textfenster lässt sich der Code auf verdächtige Einträge oder Skripte durchsuchen. Praktischerweise kann Malzilla im HTML-Code enthaltene JavaScript-Abschnitte automatisch markieren und an den Decoder schicken. Im Fenster "Decoder" findet sich dann der Codeabschnitt, den man mit dem Button "Run Script" ausführen kann.

Lässt man das in die Seite eingebettete Skript im oberen Decoder-Fenster laufen, offenbart es unteren Fenster einen versteckten Iframe zu einem weiteren Server.

Ließ sich ein Skript erfolgreich ausführen, meldet Malzilla "Script compiled" und zeigt das Ergebnis im unteren Fenster an. Oftmals handelt es sich um einen im normalen Browser versteckt geöffneten IFrame, der auf eine weitere Seite zeigt oder ein weiteres JavaScript, das es nun abermals zu entschleiern gilt. Handelt es sich bei dem Ergebnis um ein weiteres Skript, kopiert man es einfach aus dem Ergebnisfenster in das Decoder-Fenster und startet es erneut mit "Run Script". Handelt es sich nur um einen Link wie im Bild links, kann man die URL als neuen Startpunkt für Malzilla verwenden, um sich weiter zum Ursprungsort des Angriffs vorzuarbeiten – im Beispiel die Seite oughwa.com/in4.php. Das dort abgelegte Skript leitet die Malzilla-Anfrage auf den Server apomith.com um, auf dem die eigentlichen Exploits lauern.

Der Link im Iframe führt über einen weiteren Redirect auf eine Seite, die einen Java-Exploit enthält.

Manchmal kann Malzilla ein Skript jedoch nicht vollständig ausführen, weil es bestimmte JavaScript-Funktionen wie document.createElement() nicht unterstützt – was auch für die auf apomith.com eingebetteten Skripte zutrifft. An dieser Stelle muss man dann entweder das JavaScript abändern und die nicht unterstützte Funktion durch eine andere, ähnliche JavaScript-Funktionen ersetzen oder auf ein anderes Tools setzen, etwa jsunpack – doch dazu später mehr.

Malzilla kann jedoch verschleierte Codesequenzen auch ohne einen emulierten Durchlauf teilweise entschleiern, indem es seine zahlreichen Dedoderfunktionen einsetzt. Etwa stellenweise mit der escape-Funktion verschleierten Code kann es automatisch dekodieren und das Ergebnis in eine Datei ausgeben. Daneben bietet Malzilla weitere Dekodieroptionen zum manuellen Rumprobieren. Wie man diese in welchen Fällen benutzt, zeigen die zahlreichen Tutorials auf der Projektseite des Tools.

Der auf apomith.com dekodierte Code offenbart, dass die Kriminellen versuchen, den Besucher sowohl mit einem PDF-Exploit als auch einem Java-Expoit zu infizieren. Dabei haben sie es insbesondere auf Anwender des Internet Explorer abgesehen, wozu sie laut Code testen, ob der Microsoft-Browser das Adobe-Reader-ActiveX-Control geladen hat und in welcher Version es installiert ist. Um eine mögliche Lücke in Java auszunutzen, lädt die Seite apomith das Java-Archiv jjj.jar auf den Rechner und startet es.

Jode legt die im Archiv enthalten Klassen als einzelne Java-Quellcode-Dateien ab.

Da Malzilla nur JavaScript verarbeiten kann, benötigt man zur Analyse des Java-Archivs jjj.jar ein weiteres Tool: den Java-Decompiler Jode [4]. Der konvertiert den Java-Byte-Code der im Archiv zusammenfassten Java-Klassen in für Menschen lesebaren Java-Code. Jode ist selbst in Java geschrieben und daher auf verschiedenen Betriebssystemen lauffähig. Es benötigt keine Installation, es genügt das Jode-Archiv (jode-1.x.jar) in ein Verzeichnis abzulegen. Allerdings sollte man den Ablageort in die Java-Umgebung-Variable CLASSPATH aufnehmen; wie man das macht, erläutert die Jode-Dokumentation.

Offenbar soll das Java-Applet einen Server auf Port 4444 lauschen lassen.

Um das Archiv jjj.jar mit dem Exploit-Code zu analysieren, lädt man es vom Server auf die Festplatte und dekompiliert es mit dem Befehl java jode.decompiler.Main --dest srcdir jjj.jar. Jode erzeugt drei Java-Quelltexte und ein Unterverzeichnis. Wie der Exploit nun arbeitet und welche Schwachstelle er im Java-Plug-in des Browser ausnutzt, würden genauere Tests zeigen. Im vorgeführten Beispiel haben wir uns damit begnügt, zu sehen, dass die Datei PayloadX.Java offenbar einen Backdoor auf Port 4444 öffnet.

Wem die Bedienung oder Installation der Tools zu aufwändig oder riskant ist oder wer eine Webseite mal eben von unterwegs ohne eigenen PC auf ihre "Bösartigkeit" untersuchen möchte, kann auch auf Online-Dienste zurückgreifen. Der für iDefense tätige Malware-Analyst Blake Hartstein stellt den Dienst jsunpack [5] zur Verfügung, der auf dem von ihm entwickelten Analyse-Toolkit jsunpack-ng beruht.

jsunpack dekodiert und analysiert die JavaScripte in einer verdächtigen Webseite automatisch.

Jsunpack dekodiert wie Malzilla verschleiertes JavaScript und versucht deren Arbeitsweise zu interpretieren sowie eine Einschätzung abzugeben, ob die Seite infektiös ist und worauf das Risiko beruht. Zum Start benötigt es nur eine URL. Bei der bereits mit Malzilla untersuchten Domain www.bowwow.co.uk zeigte sich jedoch ein interessanter Unterschied: jsunpack folgte zuerst einem offenbar von Crackern in die Webseite eingebauten, unverschlüsselten Link zu einer anderen Seite. Dort analysierte das Tool im Weiteren verschlüsselt vorgefundene JavaScript-Codeteile und stieß schließlich auf einen PDF-Exploit. Das später im HTML-Quelltext auftauchende, ebenfalls von Crackern eingebettete verschleierte JavaScript ignorierte jsunpack. Warum man es in einer manipulierten Seite mehrere Umleitungen zu PDF-Exploits gibt, ist unklar. Nach Meinung des Malware-Spezialisten Thorsten Holz handelt es sich möglicherweise um eine Mehrfachinfektion, die auf Angriffe verschiedener Cracker zurückzuführen ist.

Jsunpack fasst die Ergebnisse seiner Analysen in einem kurzen Bericht zusammen. Allerdings arbeitet es nicht immer zuverlässig und meldete auf einigen getesteten, nachweislich manipulierten Seiten keinerlei verdächtige Hinweise.

Wepawet erwartet zum Start eine URL oder eine gespeicherte HTML-Datei.

Der von der Computer Security Group der University of California betriebene Dienst Wepawet [6] ist erheblich zuverlässiger und zudem in der Lage, etwa bei Angriffen auf das Adobe-Flash- und das -Reader-Plug-in konkret die ausgenutzte Schwachstelle zu benennen. Da Exploits aktuellen Studien zufolge fast ausschließlich Lücken in Adobes Produkten ausnutzen, dürfte man mit Wepawet eine hohe Erfolgsquote bei der Analyse haben. Aber auch darüber hinaus kann Wepawet zahlreiche Exploits erkennen, wozu es die Ergebnisse der Online-Malware-Scanner Anubis [7] und Virus Total [8] hinzuzieht.

Wepawet erwartet wie jsunpack eine URL, dekodiert alle verschleierten JavaScript-Codesequenzen und stellt sie in einer Übersicht dar. Zudem führt es alle relevanten Aktivitäten der Skripte auf, beispielsweise ob und von wo weitere Skripte nachgeladen, welche ActiveX-Controls der Internet Explorer geladen hat oder wohin Redirects führen. Den Redirects folgt es automatisch und führt dort weitere Analysen durch, ohne dass man das Tool mit weiteren URLs füttern müsste

Das wichtigste zuerst: Wepawet listet auf, welche Schwachstellen ein Exploit in einer Webseite ausnutzen will.

Wer also auf die Schnelle prüfen will, was eine verdächtige Seite macht, findet in Wepawet ein großartiges Tool. Ohne größere Einarbeitung liefert es tiefergehende Erkenntnisse über den Ablauf eine Angriffs – und erspart einem damit aufwändigere manuelle Analysen.Wie bei Virenscannern gilt auch hier: Je mehr Augen über etwas Verdächtiges schauen, desto größer die Erfolgsquote. Daher sollte man sich nicht auf ein Werkzeug verlassen, sondern sie miteinander kombinieren. (dab [9])

URL dieses Artikels:
https://www.heise.de/-940407

Links in diesem Artikel:
[1] http://malzilla.sourceforge.net/
[2] http://de.wikipedia.org/wiki/Universal_Character_Set
[3] http://www.virtualbox.org/
[4] http://jode.sourceforge.net/
[5] http://jsunpack.jeek.org/dec/go
[6] http://wepawet.cs.ucsb.edu/index.php
[7] http://anubis.iseclab.org/index.php?action=home
[8] http://www.virustotal.com/de/
[9] mailto:dab@ct.de

Copyright © 2010 Heise Medien