Dipl.-Inform. Carsten Eilers

Am 16. September hat Eric Romang erstmals über Angriffe über eine neue 0-Day-Schwachstelle im Internet Explorer 7 und 8 berichtet. Nach den Angriffen über die 0-Day-Schwachstellen in Java hat er einige der für die Angriffe genutzten Server überwacht. Am Morgen des 14. September ist ihm auf einem davon ein neues Verzeichnis mit vier Dateien aufgefallen:

• 111.exe
• Moh2010.swf
• Protect.html
• exploit.html

Bei einem ersten Test stellte er fest, das ein Windows XP Pro SP3 auf dem aktuellen Stand samt ebenfalls aktuellem Adobe Flash Player infiziert wurde. Bei weiteren Untersuchungen fand er heraus, dass der Angriff über die Datei exploit.html ausgelöst wird, die ein Array mit img-Tags erstellt und die Flash-Datei Moh2010.swf lädt. Das Flash-Applet darin verteilt über Heap-Spraying Shellcode im Speicher und lädt danach die Datei Protect.html mit dem eigentlichen Exploitcode in einen iframe. Zuvor wird geprüft, ob die eigene Website in den Flash Website Storage Settings enthalten ist. Der Exploit-Code wird nur beim ersten Aufruf geladen, wird bei einem erneuten Besuch auf der Website ein Eintrag dafür gefunden, wird der Exploit nicht erneut ausgeführt.

Der Exploit-Code in Protect.html manipuliert dann das zuvor erzeugte img-Array, um den Shellcode anzuspringen und die Datei 111.exe nachzuladen, die dann ein Programm installiert, das bei jedem Einloggen automatisch gestartet wird.

17.9 - Weitere Analysen und Metasploit-Modul veröffentlicht

Am 17. September wurde von den AlienVault Labs eine Analyse des Exploits veröffentlicht. Moh2010.swf wurde demzufolge schon zuvor im Rahmen gezielter Angriffe eingesetzt, um Exploits mit einem Heap Spray vorzubereiten.

Protect.html prüft, ob es in einem Internet Explorer 7 oder 8 unter Windows XP läuft, bevor die Schwachstelle ausgenutzt und der eingeschleuste Schadcode ausgeführt wird. Installiert wird dann das Remote Administration Toolkit Poison Ivy, das beispielsweise auch beim Angriff über die 0-Day-Schwachstellen in Java zum Einsatz kam.

Laut einer Analyse von VulnHunt handelt es sich bei der Schwachstelle um eine Use-After-Free-Schwachstelle in der Funktion CMshtmlEd::Exec(), es wird auf ein bereits freigegebenes Objekt im Speicher zugegriffen. Betroffen sind demnach Internet Explorer 7, 8 und 9.

Für das Exploit-Framework Metasploit wurde ein Modul zum Testen der Schwachstelle veröffentlicht. Diese Exploit-Code wurde erfolgreich mit dem Internet Explorer 7, 8 und 9 unter Windows XP, Vista und 7 getestet. Ein Video des Moduls im Einsatz hat Eric Romang bereitgestellt.

17.9 - Microsoft veröffentlicht Security Advisory

Ebenfalls am 17. September veröffentlichte Microsoft ein Security Advisory. Der Schwachstelle wurde die CVE-ID CVE-2012-4969 zugewiesen. Laut Microsoft sind der Internet Explorer 6, 7, 8 und 9 unter allen unterstützten Windows-Versionen betroffen. Microsoft empfiehlt den Einsatz des Enhanced Mitigation Experience Toolkit (EMET), um das Ausnutzen der Schwachstelle zu erschweren. Das schützt aber nicht vor allen möglichen Angriffen.

Als weiterer Workaround wird das Ausschalten aktiver Inhalte bzw. das Ändern der Sicherheitseinstellungen für das Internet und das lokale Intranet auf "hoch" empfohlen, was zwar vor einer Ausnutzung der Schwachstelle schützen kann, aber auch die Nutzung des Internets ziemlich effektiv verhindert. Die meisten Websites sind heutzutage ohne JavaScript kaum zu nutzen.
Der Rat, im Gegenzug vertrauenswürdige Websites zu den "Trusted Sites" hinzuzufügen, ist gefährlich, da auch eigentlich vertrauenswürdige Websites nach einer Kompromittierung oder zum Beispiel durch präparierte Werbebanner Schadcode verbreiten können. Entsprechend ist auch die Möglichkeit, vor dem Ausführen aktiver Inhalten die Zustimmung des Benutzers einzuholen, nicht besonders zielführend - die Gefahr, an der falschen Stelle zuzustimmen, ist viel zu groß.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) warnt vor der Schwachstelle und rät vom Einsatz des Internet Explorers ab.

18.9. - Drei weitere Exploits entdeckt, FixIt-Tool angekündigt

Die AlienVault Labs melden die Entdeckung von drei weiteren Exploits, einer davon schleust das RAT "PlugX" ein. Die Angriffe scheinen sich gegen bestimmte, nicht genannte Industrien zu richten, die Hintermänner scheinen Chinesen zu sein.

Microsoft hat ein FixIt-Tool für die nächsten Tage angekündigt.

19.9. - Es gib nichts Neues...

Am 19. September gab es nichts neues über die Schwachstelle oder die Angriffe darüber zu vermelden. Was ja nicht die schlechteste Nachricht ist.

20.9. - FixIt veröffentlicht, Update angekündigt

Siehe auch in der Einleitung: Microsoft hat die sofortige Veröffentlichung des FixIt-Tools sowie die Veröffentlichung eines Updates für den morgigen Freitag (21.9.) angekündigt.

21.9. - Microsoft veröffentlicht das Update

Update 21.9.:
Microsoft hat das Security Bulletin MS12-063 veröffentlicht, das Update steht ab sofort zur Verfügung. Außer der aktuell ausgenutzten 0-Day-Schwachstelle werden damit vier weitere, vertraulich an Microsoft gemeldete Use-after-Free-Schwachstellen behoben. Falls Sie sich über die schnelle Veröffentlichung des Updates wundern (normalerweise kann man nicht innerhalb einer Woche einen Patch entwickeln und ausführlich testen): Microsoft bedankt sich im Security Bulletin bei "An anonymous researcher, working with TippingPoint's Zero Day Initiative, for reporting the execCommand Use After Free Vulnerability (CVE-2012-4969)". Vermutlich war Microsoft die Schwachstelle also schon seit längerem bekannt und der Patch bereits mehr oder weniger fertig und getestet, als die Angriffe über die Schwachstelle begannen.

Microsoft hat zuvor schon Details über die Schwachstelle, das FixIt-Tool und die Angriffe veröffentlicht. Das FixIt-Tool installiert Code, der die Schwachstelle in der betroffenen Library MSHTML.DLL bei jedem Laden der DLL patcht. Dabei wird genau so vorgegangen wie beim Beheben der Schwachstelle im heute veröffentlichten Update. Hinsichtlich der Angriffe wird darauf hingewiesen, dass alle bekannten Exploits Plugins von Drittherstellern benötigen, um den Schadcode über Heap-Spraying einzuschleusen und/oder Schutzmaßnahmen wie ASLR zu umgehen.
Ende des Updates

Carsten Eilers