IE 0-Day (CVE-2012-4969) – JavaScript only

Die folgende Analyse gibt einen Einblick in einige interessante technische Details, die bereits in unserem ersten Übersichtsartikel zu diesem aktuellen Exploit vorgestellt wurden.

Die schädliche Seite befindet sich in einem Unterverzeichnis einer erotischen Dating-Seite. Auf dem Webserver sind viele verschiedene Seiten gespeichert, wobei die betreffende Domain vor mehr als drei Jahren registriert wurde. Darüber hinaus waren wir in der Lage die Nutzung veralteter Social Network Software zu überwachen, was darauf hindeutet, dass wir es mit einer gehackten Website und nicht mit einer eigens für diesen Angriff registrierten Webseite zu tun haben. Deshalb veröffentlichen wir nicht den betroffenen Domain-Namen, sondern konzentrieren uns auf die von uns beobachteten technischen Details.

Im ersten Teil des Skripts wurde ein Feld (Array) erzeugt und ein neues “img”-Tag in das erste Element dieses Array eingefügt. Das entspricht dem in der ursprünglichen Exploit-Version (exploit.html) verwendeten Code, wie von Eric Romang erstmals berichtet. Darüber hinaus lädt ein Iframe weiteren Code vom gleichen Server in die Webseite. Der restliche Code ist verschleiert.

Die vom Iframe geladene HTML-Seite ist nicht verschleiert und enthält zwei interessante Elemente:

1. Einen Funktionsaufruf für document.execCommand(“selectAll”), der notwendig ist, um den Exploit zu starten.
2. Das Quellattribut des ersten Array-Elements ist auf
   YMjf\u0c08\u0c0cKDogjsiIejengNEkoPDjfiJDIWUAzdfghjAAuUFGGBSIPPPUDFJKSOQJGH festgelegt, was dem String der ursprünglichen Version (protect.html) entspricht.

An diesem Punkt wird klar, dass die Website CVE-2012-4969 ausnutzt. Die ursprüngliche Exploit-Version benutzt eine Flash-Datei, um mittels JIT-Spray entsprechend den Anforderungen des Exploits den Speicher vorzubereiten. Deshalb werfen wir einen näheren Blick auf den verschleierten Teil des Skripts und suchen die Flash-Datei:

Das unverschleierte Script lässt sich in zwei Teile unterteilen. Der erste Teil (Abbildung 3) gibt die Funktion “heaplib()” an, die aus der heaplib.js-Bibliothek stammt. Sie wurde von dem Sicherheitsexperten Alexander Sotirov entwickelt.

Der zweite Teil des Scripts Skripts (Abbildung 4) deklariert die Variable “code”, der der Shellcode zugewiesen ist und der nach erfolgreicher Auswertung ausgeführt wird. Nach der Überprüfung der Browserversions des Opfers und der Version des Betriebssystems wird die heaplib-Bibliothek genutzt, um Heapspraying auszuführen.

1. In diesem Fall wird nur Internet Explorer Version 8.x unter Windows XP angegriffen.
2. Es ist keine Flash-Datei einbezogen. Die Heapspray-Technik, die sich die heaplib.js-Bibliothek zunutze macht, wird eingesetzt, um den dynamischen Speicher des Opfers für den Exploit vorzubereiten. Deshalb wird für einen erfolgreichen Angriff nur JavaScript benötigt.

Der bei diesem Angriff verwendete Shellcode ist ein typischer Download- und Ausführungscode, der auf diesen speziellen Exploit abgestimmt ist. Er lädt vom gleichen Server eine Datei herunter, die sich unter /theme/f5.jpg befindet. Der Name gibt vor, dass wir es mit einer Bilddatei zu tun haben, aber in Wirklichkeit handelt es sich um einen binären Payload, der vom Shellcode sofort ausgeführt wird.

Bei Ausführung des Payloads, der Bot-Hauptkomponente, wird ein neuer Prozess ausgelöst und eine weitere Komponente heruntergeladen, die sich auf dem gleichen Webserver unter /module/z5.jpg befindet. Diese Prozesse werden im Windows Task-Manager angezeigt und der Bot versucht nicht, seine Aktivitäten zu verbergen.

Um die Persistenz der Malware zu gewährleisten, kopiert sich die Bot-Hauptkomponente in das Verzeichnis %SYSDIR%:\Users\%Username%\AppData\Local\838e5661\juschedj.exe, wobei der Name des Java Updaters von SUN Microsystems imitiert wird. Darüber hinaus wird im Windows Autorun-Verzeichnis (%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup) eine Verknüpfungsdatei mit dem Namen MSupdate.lnk erzeugt, die auf die zuvor kopierte Datei verweist und es der Malware ermöglicht, nach einem Neustart erneut aktiv zu werden.

Bemerkenswert ist dabei, dass keinerlei Packer vorhanden ist, wobei jedoch die intensive Nutzung der String-Verschleierung eine statistische Analyse erschwert. Alles in allem vermeidet der Bot verdächtige Aktionen und hat damit gute Chancen von verhaltensbasierten Erkennungssystemen unentdeckt zu bleiben.

Bei der heruntergeladenen Datei handelt es sich um ein weiteres Binärprogramm, das als Tor-Client identifiziert wurde und unter Verwendung der folgenden Parameter von der Bot-Hauptkomponente direkt gestartet wird:

Der Tor-Client versucht sich über versteckte Dienste des Tor-Netzwerks mit einem Command-and-Control-Server (C&C) zu verbinden. Wenn die erste Adresse nicht erreichbar ist, wird nach einigen Versuchen eine andere Adresse kontaktiert:

1. anhmgho2efkywudt.onion/ct2.php (ursprünglicher Dienst)
2. xtrb3h5gyswyzdc5.onion/ct2.php (Ersatzadresse zur Absicherung)

Die G DATA SecurityLabs haben kürzlich eine andere Malware analysiert, die ebenfalls auf einen versteckten Tor-Dienst zurückgreift, um den C&C-Server zu verbergen - Die Strategie scheint unter den Malware-Autoren beliebt zu werden.

Nach einer erfolgreichen Verbindung mit dem Tor-Netzwerk, sammelt die Malware einige Hardware-Eigenschaften und sendet eine HTTP-POST-Anfrage an den C&C-Server. Die in Abbildung 5 aufgeführte, anonymisierte Anfrage zeigt die folgenden Schlüsselbefehle, die an den C&C-Server gesendet werden: id, v, cf, os, d.

Die Malware wiederholt dieses Verfahren regelmäßig, um vom C&C-Server neue Befehle zu empfangen.
Die Anzahl der vom C&C-Server akzeptierten, integrierten Befehle ist zwar begrenzt, unterstützt jedoch das Herunterladen und Entschlüsseln weiterer Binärdateien, was das System extrem flexibel macht. Vorausgesetzt, dass der C&C jetzt nur "leere" Antworten zu senden scheint und dass die wesentliche Funktion des Bots in Download&Execute besteht, ist es wahrscheinlich, dass das Ziel dieses Angriffs darin besteht, die Bots in einem "Pay-per-Install"-Modell zu verkaufen

Seit der Veröffentlichung des ersten Artikels zum IE 0-Day von Eric Romang am 14. September und der Veröffentlichung des MetaSploit-Moduls am 17. September haben Sicherheitsexperten und die Underground Community dieser Sicherheitslücke viel Aufmerksamkeit geschenkt.

Mindestens 10 verschiedene Versionen des Exploits wurden mittlerweile beobachtet, zumeist bei gezielten Angriffen eingesetzt, wie sie von Anup Ghosh (CEO von Invincea), Microsofts Yunsun Wee, Direktor von Trustworthy Computing, und anderen konstatiert wurden.

Bislang konnten wir nur Attacken mit modifizierten Versionen des ursprünglich veröffentlichten Exploit-Codes beobachten, die verschiedene Flash-Dateien verwenden, um den Speicher für den Exploit entsprechend vorzubereiten. Jetzt haben wir jedoch die ersten Versionen entdeckt, die ausschließlich auf JavaScript zurückgreifen und auf den normalen Internet-Nutzer abzielen. Aufgrund unserer Analyse glauben wir, dass es sich bei dem für diese aktuelle Attacke verwendeten Exploit um eine raffiniertere Version der von Eric Romang publizierten ursprünglichen Exploit-Version handelt. Es kann davon ausgegangen werden, dass die Integration in die populären Exploit-Packs, wie Blackhole, bald folgen wird.

Microsofts beispielhafte und schnelle Reaktion in Form der Veröffentlichung verschiedener Instruktionen, einem Fix-it und schließlich einem Out-of-Cycle-Patch am 21. September deutet ebenfalls auf die möglichen Auswirkungen des Exploits hin. Jedem IE-Nutzer wird empfohlen, das bereitgestellte Sicherheitsupdate sofort zu installieren, sofern dies nicht bereits durch die automatische Update-Funktion geschehen sein sollte.