Am 15. Mai 2013 hat Tavis Ormandy, ein bei Google angestellter Sicherheitsexperte, Informationen zu einer möglichen Schwachstelle im Windows Kernel in seinem Blog veröffentlicht. Details dazu finden sich ebenfalls in unserer Verwundbarkeitsdatenbank. Der Finder einer Schwachstelle hat immer mehrere Möglichkeiten mit selbiger umzugehen:

• Die für uns alle schlechteste Option wäre die Entwicklung eines Exploits und der anschliessende Verkauf dessen auf dem Schwarzmarkt.
• Eine weitere Möglichkeit wäre die Schwachstelle an den Hersteller der Software, in diesem Falle Microsoft, zu melden. Der Hersteller bekäme so die Möglichkeit die Schwachstelle zu schliessen und einen Patch dafür zu veröffentlichen. Danach kann der Finder die Details zur Schwachstelle veröffentlichen. Dies wäre dann eine sogenannte verantwortungsvolle Veröffentlichung (Responsible Disclosure) oder eine koordinierte Veröffentlichung (Coordinated Disclosure).
• Oder man wählt den Weg des Full Disclosure. Hierbei werden alle Details zur Schwachstelle direkt im Internet publiziert. Dies wird meistens gewählt, um den Druck auf den Hersteller zu erhöhen und um Spezialisten die Möglichkeit zu geben, eigenständig Schutzmassnahmen ergreifen zu können.

Natürlich erhöht so ein Full Disclosure auch das Risiko dass die Schwachstelle für kriminelle Zwecke missbraucht wird. Tja, in diesem Fall hat der Finder den Weg des Full Disclosure gewählt. Zusammen mit progmboy, ein versierter Programmierer, hat Tavis einen Proof of Concept (PoC) Exploit erstellt und veröffentlicht. Der Code zu diesem Exploit ist ebenfalls frei im Internet verfügbar.

Kurzanalyse der Schwachstelle und PoC

Auf verschiedenen Webseiten, unter anderem auf heise.de, wurden Artikel über die Schwachstelle und dessen Exploit veröffentlicht. Ebenfalls sind auf der Full Disclosure Mailinglist alle Informationen über die Schwachstelle wie auch der Code des PoC ersichtlich.

Eine Zusammenfassung der veröffentlichten Informationen sieht in etwa so aus:

• Die Funktion EPATHOBJ::pprFlattenRec() des Windows Kernel hat einen Bug.
• Der Code dieser Funktion ist angeblich über 20 Jahre alt.
• Man kann beliebigen Code injizieren und mit den Rechten von SYSTEM ausführen.
• Das Memory wird beschäftigt, um danach den Code zu injizieren (Memory Corruption).
• Der PoC wurde für Windows 7 SP1 32bit geschrieben.

Der veröffentlichte Code des PoC wurde in C++ geschrieben und kann ohne Änderungen kompiliert werden. Das Ziel des PoC ist es, ein Command Prompt Fenster zu erhalten, welches unter den Rechten von SYSTEM ausgeführt wird.

Für eine erfolgreiche Ausführung muss der Exploit mehrmals gestartet werden. Mehrmals heisst hier, dass es schon mal vorkommen kann, dass auch nach dem hundertsten Start ein Erfolg ausbleibt. Ebenfalls ist es während des Tests auch einige Male vorgekommen, dass das System nicht mehr reagierte oder so instabil wurde, dass es sich mit einem BlueScreen verabschiedete. Dies verwundert eigentlich nicht, immerhin handelt es sich ja um eine Memory Corruption Schwachstelle.

Der PoC wurde von mir auf allen 32bit und 64bit Windows Versionen getestet, welche seit Windows XP/2003 von Microsoft herausgebracht wurden. Einzig auf folgenden 32bit Systemen ist der Code ohne Anpassungen lauffähig:

• Windows 2008
• Windows 7
• Windows 8 (BlueScreen und Freezes extrem häufig)

Ebenfalls muss das Software Paket Visual C++ Redistributable for Visual Studio von Microsoft auf dem Rechner installiert sein, damit das Programm ausgeführt werden kann.

Einsatz des Exploits

Mit dem bekannten und für jedermann zugänglichen PoC Code stehen Systeme, welche ein interaktives Login anbieten, zuoberst auf der Liste der gefährdeten Ziele. Hierbei spielt es keine Rolle, ob es sich um ein lokales Endgerät, eine Citrix XenApp Sitzung oder Remote Desktop Verbindung handelt. Wobei natürlich gerade ein Citrix XenApp Server ein hervorragendes erstes Angriffsziel abgibt.

Die erste Frage, die sich hier aber stellt ist ob überhaupt noch Windows 2008 32bit Systeme mit Citrix XenApp im Einsatz sind. Die meisten Installationen sind heutzutage 64bit und für selbige müsste der Code angepasst werden. Somit ist der PoC Exploit, gepaart mit zusätzlichen Angriffsvektoren (z.B. Social Engineering), vor allem für 32bit Endgeräte und deren Windows Domäne gefährlich.

Jetzt gibt es aber viele begabte Programmierer auf dieser Welt und wie in allen Berufen gibt es auch da nicht nur nette. Schnell ist einem klar, dass die Funktionen, welche im PoC Exploit gebraucht werden, in Bibliotheken abgelegt sind, welche sogar von einem Gast Benutzer aufgerufen werden dürfen. Folgende DLLs werden benötigt:

• gdi32.dll
• kernel32.dll
• user32.dll
• shell32.dll

Diese Bibliotheken können nicht nur von einem in C++ geschriebenen Programm aufgerufen werden, sondern von jeglichem auf einem Windows Rechner ausführbaren Programm. Dies beinhaltet auch interpretierten Code wie Java und VBA. Ich bin mir sicher dass der eine oder andere Tüftler den PoC Code schon am Umschreiben und/oder Verbessern ist.

Schutzmassnahmen

Hier wird es sehr trickreich. Vor allem möchte ich die Angreifer in zwei Gruppen teilen:

• Zuerst sind da die Script-Kiddies welche den PoC Code herunterladen, kompilieren und versuchen ihn auf Windows Rechner auszuführen, um so an erhöhte Benutzerrechte zu gelangen.
• Die zweite Gruppe umfasst alle Angreifer die mit dem Code was anfangen können und fähig sind den Code so anzupassen damit er auf 64bit Systemen lauffähig wird. Ebenfalls können dieses Personen den Code so verändern oder mit anderen Exploits paaren, was die Gefahr massiv erhöht.

So, wie wehre ich mich nun gegen den PoC Code? Zu meinem Erstaunen hat sich beim ersten Ausführen der lokal installierte Virenscanner gemeldet und das Ausführen mit einer Warnmeldung verzögert. Hier wurde nicht der Pattern-basierte Scanner aktiv, sondern wurde beim Ausführen in der Sandbox (Umgebung, in der eine Applikation ausgeführt wird um zu schauen was selbige macht) erkannt, dass das Programm auf heikle Systemdateien zugreift. Viele Virenscanner bieten eine Sandbox oder ein ähnliches Verfahren an.

Nach dem Deaktivieren des Virenscanners waren aber keine anderen Schutzmassnahmen auf dem System vorhanden. Hier würde sich nun eine Software Restriction Policy oder eine AppLocker Policy anbieten. In Windows 8 und Server 2012 sind weitere Massnahmen standartmässig aktiv, welche ein Ausführen von unsignierten Applikationen verhindern kann.

Sich gegen den Angriff mit geändertem Code zu wehren, wird ein bisschen schwieriger. Vor allem wenn der Code interpretiert wird. Ich habe mir eine Liste zusammengestellt, was es zu beachten gibt und was für Massnahmen es gibt:

• Virenscanner: Virenscanner mit Sandbox oder äquivalenter Funktion einsetzen
• Whitelisting: AppLocker oder auf pre Windows 7 Systemen Software Restriction Policy einsetzen. (Blog zum Thema)
• System Hardening: Je besser ein System gehärtet wurde, desto schwieriger wird es für einen Angreifer Code auf ein System zu kopieren und auszuführen. (Blog zum Thema)
• Code Signing: Nur signierter Code oder Applikationen zur Ausführung zulassen. VBA oder Java Code lässt sich signieren. Die Interpreter lassen sich so konfigurieren, dass nur signierter Code ausgeführt werden darf. Nicht signierte Applikation lassen sich seit Windows 8/2012 mit On-Board Mitteln blockieren.
• Systemschutz: Zugriffe auf heikle Systembereiche sollten protokolliert (Blog zum Thema) oder noch besser verhindert werden. Um dies zu erreichen gibt es nebst dem Windows Audit-Log auch eine Vielzahl an IDS/IPS Agents für Server und Client Systeme.
• Perimeter Sicherheit: Schutz des Clients durch Umsysteme. Was seit vielen Jahren gang und gäbe ist gilt immer noch. Der Download oder das Empfangen via E-Mail von Executables, Dateien mit Code und Script Code und komprimierten Dateien etc. sollte sehr restriktiv behandelt werden. (Blog zum Thema)
• Restriktiver Datenaustausch: Der Austausch von Daten via Wechseldatenträger sollte eingeschränkt oder unterbunden aber mit Sicherheit protokolliert werden.
• Application Virtualization: Eine weite Möglichkeit ist das Virtualisieren der Applikationen. Hierbei gibt es Lösungen wo man die Zugriffe einer solchen Applikation genauestens festlegen und überwachen kann. (Blog zum Thema)

Diese Liste ist nicht als abschliessend zu betrachten, sondern sollte mehr als Gedankenanregung dienen. Ziel sollte es sein, alles ausführen zu dürfen, was nötig ist und alles andere zu verbieten. Dieses Ziel ist natürlich nicht ganz einfach zu erreichen. Vor allem bei grösseren und komplexen Umgebungen kann es mit viel Aufwand verbunden sein.

Fazit

Ein einzelnes Allheilmittel gibt es, wie in den meisten Fällen, auch hier nicht. Doch man steht dem Problem nicht hilflos gegenüber. Man kann sich mit Windows On-Board Mitteln schon relativ gut gegen die Bedrohung zur Wehr setzen. Unterstützt durch das eine oder andere Software-Produkt, kann man das Risiko auf ein Minimum reduzieren. Wenn man sich schon seit längerem nicht mehr mit dem Hardening der Systeme befasst hat, wäre jetzt sicher eine gute Gelegenheit, die Systeme zu prüfen und gegebenenfalls Massnahmen zur Erhöhung der Sicherheit zu ergreifen.

Über den Autor

Links

• http://blog.cmpxchg8b.com/2013/05/introduction-to-windows-kernel-security.html
• http://heise.de/-1875749
• http://www.microsoft.com/en-us/download/details.aspx?id=30679
• https://vuldb.com/?id.8937