Dipl.-Inform. Carsten Eilers

Am 12. Juni hat Microsoft ein Security Advisory veröffentlicht, in dem vor einer 0-Day-Schwachstelle in den XML Core Services gewarnt wird. Betroffen sind alle Windows-Versionen ab Windows XP bis Windows 7 und Windows Server 2008 sowie Microsoft Office 2003 und 2007. Die Schwachstelle wird laut Microsoft über den Internet Explorer ausgenutzt. Da auch Microsoft Office von der Schwachstelle betroffen ist, dürfte ein Angriff außer über präparierte Webseiten auch über präparierte Office-Dokumente möglich sein. Microsoft schreibt dazu im Security Advisory aber nichts.

Microsoft hat ein Fixit-Tool veröffentlicht, das den aktuell ausgenutzten Angriffsvektor versperrt. Weitere Details wurden nicht verraten.

Am 13. Juni wurden dann in Microsofts Security Research & Defense Blog weitere Details veröffentlicht. Inzwischen hat Microsoft selbst erkannt, dass die so gerne vorgeschlagenen Schutzmaßnahmen "Ausschalten von ActiveX und Active Scripting" und "Besuchen Sie nur vertrauenswürdige Webseiten" weder praktikabel noch brauchbar sind. Aber das sei nur am Rande erwähnt, so wie Microsoft die nutzlosen Ratschläge wohl auch nur noch pro Forma gibt. Viel interessanter ist die Beschreibung des oben schon erwähnten Fixit-Tools: Es verwendet das Windows Application Compatibility Toolkit, um die Bibliothek msxml3.dll, msxml4.dll oder msxml6.dll bei jedem Laden des Internet Explorers so zu ändern, dass die ursprünglich uninitialisierte Variable, die der Auslöser der Schwachstelle ist, initialisiert wird.

"Staatlich gesponserte Angriffe"

Google hat Microsoft bereits am 30. Mai über Angriffe über diese Schwachstelle informiert. Laut Google erfolgen die Angriffe sowohl über präparierte Webseiten als auch über präparierte Office-Dokumente. ZDNet berichtet, dass die Angriffe der Auslöser für Googles Entscheidung waren, die Benutzer in Zukunft vor "state-sponsored attackers" zu warnen. Dabei beruft man sich auf eine "source close to these investigations".

Drive-by-Infektionen entdeckt

Von Sophos wurde am 19. Juni ein Exploit für die Schwachstelle auf der Website einer nicht genannten "European medical company" gefunden. Alle für die Drive-by-Infektion benötigten Dateien befanden sich auf der kompromittierten Website:

• deploy.html
• faq.htm
• deployJava.js
• movie.swf

Über den Ablauf der Drive-by-Infektion hat Sophos wenig verraten: deploy.html enthält die Schwachstelle (wohl eher den Exploit dafür, die Schwachstelle ist ja in den XML Core Services) und lädt deployJava.js. Der JavaScript-Code sammelt dann Informationen über den Webbrowser. Außerdem versucht deploy.html, die Datei movie.swf mit dem Parameter "?apple=[langer Hexadezimal-String]" aufzurufen. Zuletzt wird noch ein iframe mit faq.htm geladen.

Etwas mehr Informationen über den Angriff gibt es bei Symantec: deploy.html wird demnach als iframe in die kompromittierten Seiten eingebunden. Die SWF-Datei ist für das Heap Spraying und Bereitstellen des Shellcodes zuständig. Die von deployJava.js gesammelten Informationen über Browser und System werden benötigt, um Heap Spraying und Shellcode an die verschiedenen Windows- und Sprachversionen anzupassen. Wird der Shellcode dann ausgeführt, lädt er, wie bei Drive-by-Infektionen üblich, weiteren Code nach. Wie der Exploit funktioniert, wurde z.B. von ESET beschrieben. Es wurde auch schon ein Modul für das Metasploit-Framework veröffentlicht.

Ein einfacher Proof-of-Concept, um einen Absturz auszulösen, sieht z.B. so aus:

<object classid="clsid:f6D90f11-9c73-11d3-b32e-00C04f990bb4" id="foo"></object>
<script> document.getElementById("foo").object.definition(0); </script>

Erster Schritt eines Advanced Persistent Threats?

Am 20. Juni meldete Sophos dann eine identische Drive-by-Infektion auf der Websites eines "European aeronautical parts supplier". Der einzige Unterschied besteht darin, dass die Datei deploy.html hier exploit.html genannt wurde.

Graham Cluley von Sophos spekuliert dann etwas: "So, what's going on?":

• Es besteht vermutlich ein Zusammenhang zwischen der Schwachstelle und Googles Warnung vor staatlich gesteuerten Angriffen. Cluley schreibt sogar "We know that ...", aber eigentlich ist es doch eher eine Behauptung von ZDNet.
• Um große Unternehmen anzugreifen, nehmen die Angreifer öfter den Umweg über kleinere, i.a. schlechter geschützte Zulieferer.
• Der Angreifer, der den Drive-by-Code auf der Website des "aeronautical parts supplier" platziert hat, kann davon ausgehen, das irgendwann ein Mitarbeiter z.B. eines Waffenherstellers oder eines Verteidigungsministeriums die Seite besucht. Er muss also nur darauf warten, bis sein eingeschleuster Schadcode sich von einem entsprechenden Rechner meldet.

Wie gesagt, ist das alles nur Spekulation. Aber wenn Graham Cluley recht hat, dürfte dass der erste Schritt im Rahmen eines Advanced Persistent Threats sein. Die werden zwar i.A. über gezielte E-Mails ausgelöst, aber wer sagt denn, dass nicht jemand gezielt auf die Website des "aeronautical parts supplier" gelockt wird/wurde/werden sollte?

CVE-2012-1875 - "Same ID Property Remote Code Execution Vulnerability"

Die sog. "Same ID Property Remote Code Execution Vulnerability" im Internet Explorer wurde am 12. Juni im Rahmen des normalen Patchdays behoben (MS12-037). Sie wurde bereits zuvor für Angriffe ausgenutzt ("Microsoft is aware of limited attacks attempting to exploit the vulnerability.").

Entdeckt wurde die Schwachstelle als 0-Day-Angriff am 1. Juni von McAfee. Der Exploitcode funktioniert auf allen "major" Windows-Versionen, namentlich genannt werden Windows Vista und 7. Zum Umgehen von Data Execution Prevention (DEP) setzt der Exploit Return-oriented Programming (ROP) ein. Auch die Address Space Layout Randomization (ASLR) wird umgangen, dafür ist der Exploit aber auf das Vorhandensein einer alten Java Virtual Machine angewiesen, deren msvcr71.dll ASLR nicht unterstützt. Ist diese DLL nicht vorhanden, führt der Exploit zu einem Absturz. Anders sieht es unter Windows XP aus, hier kommt der Exploit ohne Komponenten von Drittherstellern aus. Eine Analyse des Exploits gibt es bei dem Alienvault Labs.

Schnell gepatcht, oder auch nicht

Fällt Ihnen an dieser Stelle auch etwas auf? Die von McAfee am 1. Juni gemeldete Schwachstelle wurde am 12. Juni bereits behoben, die von Google am 30. Mai gemeldete Schwachstelle ist noch offen. Letzteres ist eigentlich der Normalfall, innerhalb von 12 Tagen eine Schwachstelle zu analysieren, einen Patch zu entwickeln und ausreichend zu testen, ist nur in absoluten Ausnahmefällen möglich. Da Microsoft in den "Acknowledgments" mehrere Beteiligte aufführt ("Dark Son of VulnHunt for reporting ..." und Qihoo 360 Security Center, Yichong Lin von den McAfee Labs und Google Inc. "for working with us on ...") könnte das mal wieder einer der Fälle sein, in denen eine vertraulich gemeldete Schwachstelle unabhängig davon von Dritten entdeckt und nicht gemeldet, sondern ausgenutzt wurde. Der Patch wäre dann schon fast fertig gewesen, als McAfee den Exploit an Microsoft gemeldet hat. Genau so war es z.B. bei der 0-Day-Schwachstelle im Internet Explorer, die im Dezember 2009 im Rahmen der Operation Aurora ausgenutzt wurde. Die konnte auch in sehr kurzer Zeit gepatcht werden, da sie Microsoft bereits seit September 2009 bekannt war und der Patch sowieso für die Veröffentlichung am nächsten Patchday vorgesehen war.

Microsofts Security Bulletin MS12-037 ist übrigens in einem Punkt nicht mehr aktuell: Bei der Veröffentlichung war noch kein Proof-of-Concept-Code verfügbar, inzwischen wurde ein Modul für das Metasploit-Framework veröffentlicht. Der PoC basiert auf dem "in the wild" entdeckten Exploit.

Drive-by-Infektionen entdeckt

Auch diese Schwachstelle wird im Rahmen von Drive-by-Infektionen ausgenutzt. Symantec berichtet, dass u.a. die Website von Amnesty International Hong Kong kompromittiert wurde, um einen iframe mit dem Exploit einzuschleusen. Wie üblich lädt der anfangs eingeschleuste Code weiteren Schadcode nach, in diesem Fall das Remote Administration Toolkit (RAT) "Trojan.Naid".

Symantec hat mehrere der Drive-by-Infektionen beschrieben. In einem eingeschleusten iframe wird eine HTML-Seite geladen, die getarnten (obfuscated) JavaScript-Code enthält. Darüber wird eine SWF-Datei eingebettet, von beidem zusammen wird dann der Exploit ausgelöst. Die SWF-Datei ist dabei wie im Fall der Exploits für CVE-2012-1889 für das Heap Spraying und die Bereitstellung des Shellcodes zuständig.

Was ist da los?

Zwei 0-Day-Schwachstellen, die für Drive-by-Infektionen genutzt werden - das ist ungewöhnlich. Eigentlich setzen die Cyberkriminellen dafür Exploits für ältere Schwachstellen ein, die bereits behoben wurden. Genug ungepatchte Systeme finden sie damit allemal. Ein 0-Day-Exploit ist für so einen "Schrotschuss-Angriff" eigentlich viel zu wertvoll. Es ist also gut möglich, dass wirklich ein Staat hinter den Angriffen steckt. Und dann wird es Zeit, über die Folgen staatlicher Cyberangriffe zu diskutieren. Bei einem virtuellen Wettrüsten, bei denen alle möglichen Staaten Schwachstellen als Waffen sammeln statt sie an die betroffenen Hersteller zu melden, wird es nur einen Gewinner geben: Die Cyberkriminellen, die gefundene 0-Day-Schwachstellen dann zum einen gewinnbringend an die Staaten verkaufen können und zum anderen die von den Staaten eingesetzten 0-Day-Exploits später für ihre eigenen Zwecke anpassen können.

Carsten Eilers