Microsoft-Tool lässt Exploits ins Leere laufen

EMET von Microsoft aktiviert zusätzliche Schutzfunktionen moderner Windows-Versionen, die viele Angriffe auf Sicherheitslücken in Programmen abwehren können. Der Teufel steckt dann jedoch wieder im Detail.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 7 Min.
Von
  • Daniel Bachfeld
Inhaltsverzeichnis

EMET kann verschiedene Angrifftechniken zum Ausnutzen von Sicherheitslücken ins Leere laufen lassen oder zumindest die Zuverlässigkeit von Exploits verringern. Zu den dabei eingesetzten Techniken gehört unter anderem die Datenausführungsverhinderung (DEP) und Adress Space Layout Randomisation (ASLR).

Windows überlässt es der Anwendung, beim Laden durch bestimmte Flags zu signalisieren, ob sie die nutzen will. Doch viele Anwendungen machen leider keinen Gebrauch von den von DEP und/oder ASLR obwohl das prinzipiell möglich wäre. Mit EMET lassen sich die Schutzmechanismen nachträglich in fertigen Binaries aktivieren, ohne dass der Quellcode des Programms vorliegen muss.

DEP verhindert, dass ein Angreifer seinen über einen Buffer Overflow auf den Stack oder Heap geschriebenen Code ausführen kann – den Overflow selbst kann es nicht verhindern. Der Angreifer muss aber nicht zwingend sofort seinen eigenen Code ausführen. Vielmehr kann er durch Manipulation der Rücksprungadresse in ein bereits von der Anwendung geladenes Codesegment springen. Üblicherweise versuchen Angreifer in bestimmte Funktionen der C-Bibliothek zu springen (Return-into-libc-Attacke). Da die Funktionen immer an die gleiche Stelle geladen werden, weiß ein Angreifer, an welche Stelle sein Code springen muss.

Microsofts Anti-Exploit-Tool (7 Bilder)

Adobe-PDF

Zwar nutzt der Adobe Reader bereits ab Werk DEP, aktuelle Exploits können diesen Schutz jedoch aushebeln.

Diese Vorhersage soll nun wiederum Adress Space Layout Randomisation (ASLR) erschweren. Windows 7 und Vista wählen für den Speicherort des geladenen Codes eines Prozesses, die dazugehörige DLLs, den Stack und Heaps zufällige Adressen. Das lässt sich zwar auch wieder mit bestimmten Tricks aushebeln, allerdings macht es Exploits unzuverlässiger – und oftmals hat eine Angreifer nur einen Schuss.

Daneben bietet EMET Schutz vor dem Überschreiben von Exception-Handlern (SEH) auf dem Stack oder im Datensegment. Anders als beim Überschreiben von Rücksprungadressen mit Buffer Overflows führen Angreifer hierbei eigenen Code durch das Verbiegen von Funktionszeigern aus. Mit Structured Exception Handler Overwrite Protection (SEHOP) will Microsoft das verhindern. Darüber hinaus alloziert EMET die erste Seite im Speicherbereich (Null Page) einer Anwendung, um bestimmte Exploits in Zusammenhang mit versehentlichen Zugriffen auf Null-Pointer unschädlich zu machen. Das Export Address Table Access Filtering (EAF) kann Zugriffe von eingeschleustem Shellcode auf bestimmte APIs blocken. Die Anti-Heap-Spraying-Funktion soll zudem das mehrfache Verteilen von Schadcode im Speicher vereiteln (wie etwa bei den Tu-Nix-Rutschen im Tatort Internet).

In der Kombination können diese zusätzlichen Schutzfunktionen selbst dann noch Exploits unwirksam machen, wenn DEP und ASLR versagt haben. Unter Windows XP lässt sich so der kürzlich aufgetauchte Exploit für die CoolType-Lücke im Adobe Reader unschädlich machen, wie man im Folgenden sehen wird.

Microsoft integriert die neuen Schutzfunktionen über den Application Compatibility Layer in Windows, der eigentlich ältere Anwendungen zu modernen Windows-Versionen kompatibel machen soll. Dabei lädt Windows beim Start einer unterstützen (und als solche registrierten) Anwendung eine sogenannte Shim-DLL, die API-Aufrufe über sich umleitet und etwa das Verhalten einer alten Windows-Version vorgaukelt.. Die für EMET zuständige Bibliothek heißt passenderweise emet.dll.

Das Tool steht auf Microsofts Seiten zum Download zur Verfügung und erfordert die Laufzeitumgebung .Net 2.0 – ein bereits installiertes .Net 4.0 akzeptierte das Tool in unserem Test nicht. Die Installation des Tools ist selbsterklärend, bringt aber keinerlei Basiskonfiguration mit. Der Anwender muss nun selber Anwendungen auswählen und in die Liste der zu schützenden Programme eintragen.

Ab Version 2.0 hat Microsoft EMET eine grafische Bedienoberfläche spendiert, in der man mit wenigen Klicks eine Anwendung um die Schutzfunktionen erweitern kann. Dazu fügt man unter "Configure Apps" einfach die exe-Datei des jeweiligen Programmes zu der Liste hinzu (siehe Bilderstrecke). In den meisten Fällen sollte man die vorselektierten Schutzoptionen aktiviert lassen, nur wenn die Anwendung anschließend nicht mehr richtig funktioniert, sollte man einige deaktivieren – hier hilft aber leider nur Durchprobieren der einzelnen Optionen. Unter Windows XP fehlt die Option ASLR, da das Verwürfeln der Adressen erst bei Windows Vista eingeführt wurde.

Nach dem Hinzufügen muss man die geschützte Anwendungen gegebenenfalls neu starten. Anschließend lädt diese zusätzlich die Bibliothek emet.dll mit, in der die zusätzlichen Schutzmaßnahmen implementiert sind. Die EMET-Bedienoberfläche ist nur zur Konfiguration notwendig; der Anwender kann sie danach schließen. Zur Kontrolle kann es aber sinnvoll sein, nachzuschauen, ob und welche Anwendungen EMET nutzen.

Für einen einfachen Test der Wirksamkeit von EMET haben wir mit dem Exploit-Framework Metasploit ein präpariertes PDF-Dokument erstellt, das beim Öffnen im ungepatchen Adobe Reader zur Demonstration den Taschenrechner öffnete. Den gleichen Test führten wir mit installiertem EMET aus.

Das infizierte PDF-Dokument startete im Test den Taschenrechner nicht mehr und führte nur zum Absturz des Adobe Reader. Leider lässt EMET keine Rückschlüsse zu, welche der Optionen die Adobe-Reader-Lücke nun davor bewahrt hat, ausgenutzt zu werden.

So weit, so gut. Leider mussten wir feststellen, dass wir keineswegs vor Angriffen durch diese PDF-Datei geschützt waren. Denn das Einbinden des Adobe-Reader-Binaries in EMET schützt kein Stück vor Angriffen auf die Browser-Plug-ins für den Internet Explorer und Firefox. Und wer denkt, dass das Einbinden der Plug-in-Dateien ausreichen würde, um Exploits ins Leere laufen zu lassen, liegt leider falsch. Auch das Hinzufügen von AcroPDF.dll (ActiveX-Control) oder nppdf32.dll (Mozilla-Plugin) zu EMET verhinderte den Start des Taschenrechners beim Laden des infizierten Dokuments im Browser nicht.

Selbst als wir in EMET den bei Firefox für die Verwaltung der Plug-uns verantwortlichen Container plugin-container.exe aktivierten, erschien der böse Taschenrechner noch. Letztlich half es nur, die Browser-Dateien firefox.exe und iexplorer.exe selbst mit EMET vor dem PDF-Exploit zu schützen – das schützt dann aber gleich vor Ungemach durch andere verwundbare Plug-ins.

Wer möchte, kann mit EMET weitere Anwendungen schützen. Sinnvoll sind alle diejenigen, die direkt Daten oder Dateien aus dem Internet verarbeiten, also neben dem Browser auch E-Mail-Clients, Media-Player, Office-Programme und Viewer aller Couleur. Administratoren können im Unternehmen die zu schützenden Programme über das Befehlszeilen-Tool emet_conf.exe auch per Skript zu EMET hinzufügen. Denkbar ist es sogar, Server-Anwendungen vor Angriffen mit dem Tool zu schützen. In ersten Versuchen von heise Security traten keine Probleme auf, die sich auf die damit aktivierten Sicherheitsfunktionen zurückführen ließen. Allerdings weist Microsoft selbst darauf hin, dass manche Programme allergisch darauf reagieren.

Die meisten der Schutzvorkehrungen lassen sich zwar mit ausgefeilten Exploits aushebeln. Doch das bedeutet für die Malware-Entwickler derzeit noch viel Aufwand und zahlreiche Tests. Deshalb kursieren derzeit noch keine Schädlinge, die alle Hürden auf einmal nehmen. Bis es soweit ist, kann EMET die Sicherheit von Windows-Systemen also deutlich erhöhen. (dab) (dab)