Schutzmassnahmen gegen Drive-by-Attacken – Teil II

Dieser Artikel wurde von Renato Ettisberger geschrieben.

Das Problem der Plug-Ins

Im ersten Teil dieser Serie haben wir aufgezeigt, wie wenig Schutz die implementierten Gegenmassnahmen bei Windows XP in Bezug auf Drive-by-Angriffe bieten. Der Hauptgrund dafür ist, dass die Basis-Adressen von DLLs für ein bestimmtes Windows XP-System (Sprach- und Service Pack-abhängig) vorhersehbar sind. Ein Angreifer nutzt diesen Umstand, um daraus Code-Sequenzen zusammenzuhängen (ROP) und damit die „Schutzfunktion“ DEP zu umgehen.

Microsoft hat bei der Entwicklung von Windows Vista, Windows 7 und Windows 8 darauf reagiert. Zum einen ist bei neueren Windows-Systemen der „Protected Mode“ für den Internet Explorer (ab IE7) vorhanden. Ein Angreifer kann sich damit nicht mehr so einfach auf dem System permanent festsetzen. Zum anderen ist neben DEP mit ASLR eine zweite Gegenmassnahme standardmässig aktiviert. ASLR steht für „Address Space Layout Randomization“ und sorgt dafür, dass die DLLs an zufällige Basis-Adressen geladen werden. Damit kann der Angreifer die notwendigen Code-Sequenzen zur Umgehung von DEP nicht mehr zusammenstellen, weil er deren Basis-Adressen nicht mehr kennt. DEP bleibt dadurch effektiv und erstickt den Angriff im Keim – zumindest in den meisten Fällen.

Das folgende Bild zeigt die Auswirkungen von ASLR auf. Es zeigt die Basis-Adressen einiger DLLs des Internet Explorer-Prozesses:

0:016> lm
 start end module name
 012d0000 01376000 iexplore (deferred)
 6d670000 6d6a5000 IEShims (deferred)
 6db90000 6dbbb000 ieproxy (deferred)
 6e660000 6e675000 rasman (deferred)
 6e680000 6e6d2000 RASAPI32 (deferred)
 6ebe0000 6ebed000 wshbth (deferred)
 6ebf0000 6ec02000 pnrpnsp (deferred)
 6ec10000 6ec20000 napinsp (deferred)
 6ec20000 6ec28000 winrnr (deferred)
 6f220000 6fca0000 IEFRAME (deferred)
 70740000 70746000 sensapi (deferred)
 710f0000 710f8000 npmproxy (deferred)
 71640000 71646000 rasadhlp (deferred)
 ...
 76d50000 76dfc000 msvcrt (deferred)
 ...
 ...

Nach einem System-Neustart kontrollieren wir die Basis-Adressen der DLLs erneut:

 0:014> lm
 start end module name
 00e00000 00ea6000 iexplore (deferred)
 6e3c0000 6e3ee000 MLANG (deferred)
 6f6f0000 6f73e000 actxprxy (deferred)
 70650000 70658000 npmproxy (deferred)
 709f0000 70a4a000 netprofm (deferred)
 715d0000 715d6000 rasadhlp (deferred)
 71d90000 71dc8000 fwpuclnt (deferred)
 71ea0000 71ea7000 WINNSI (deferred)
 71eb0000 71ecc000 iphlpapi (deferred)
 72000000 72035000 IEShims (deferred)
 72750000 7277b000 ieproxy (deferred)
 72780000 7278d000 wshbth (deferred)
 72790000 727a2000 pnrpnsp (deferred)
 727b0000 727c0000 napinsp (deferred)
 72830000 732b0000 IEFRAME (deferred)
 73680000 73690000 NLAapi (deferred)
 73960000 73981000 ntmarta (deferred)
 73a60000 73a68000 winrnr (deferred)
 73ab0000 73ac5000 rasman (deferred)
 73ad0000 73b22000 RASAPI32 (deferred)
 ...
 ...
 76820000 768cc000 msvcrt (deferred)
 ...
 ...

Wie zu erkennen ist, werden die DLLs bei einem System-Neustart nicht an dieselbe Basis-Adresse geladen. Beispielsweise verwendet das Metasploit-Modul die DLL „msvcrt.dll“, um mittels ROP einen Speicherbereich als ausführbar zu setzen. Bei Windows Vista/7/8 ist dieser Ansatz nicht mehr möglich, da sich diese DLL und die dort verwendeten ROP-Gadgets nicht mehr an vorhersehbaren Adressen befinden. Damit ist diese Schwachstelle bei neueren Windows-Systemen nicht mehr ausnutzbar, oder doch? Es dürfte kaum erstaunen, dass auch dieses Setup keinen hundertprozentigen Schutz bietet. Vor allem zwei Techniken sind bekannt, mit denen man solche Schwachstellen auf Windows Vista/Windows 7 ausnutzen kann:

• Durch Nutzung von ROP-Gadgets aus DLLs, die nicht an zufällige Basis-Adressen geladen werden können
• Durch ein Info-Leak, mit dem sich die Basis-Adresse einer DLL ermitteln lässt

In diesem Teil konzentrieren wir uns auf Variante 1. Info-Leaks und wie man sie nutzt sind Bestandteil des letzten Artikels der Serie.

ASLR funktioniert – vereinfacht gesagt – nur dann, wenn die DLL oder die ausführbare Datei (EXE) dies auch unterstützt. Dies wird durch Setzen des /dynamicbase Flags erreicht. Bei fast allen Windows-DLLs ist dies in der Zwischenzeit zum Standard geworden. Das sind gute Nachrichten. Allerdings wird ALSR nicht von allen Drittapplikationen oder Plug-Ins unterstützt. In der Vergangenheit waren die prominentesten Vertreter der Adobe Flashplayer oder das Adobe Reader Plug-In. Dies hat sich in der Zwischenzeit ebenfalls zum Guten geändert, ganz im Gegensatz zu älteren Java-Versionen. Erst ab Java-Version 7 wird ASLR unterstützt. Die ältere und immer noch häufig eingesetzte Java-Version 6.x ist hingegen nicht kompatibel mit ASLR.

Mit dem „Process Explorer“ von Microsoft kann man sich anzeigen lassen, welche DLLs ASLR-kompatibel sind. Damit wir die geladenen DLLs beim IE-Prozess sehen können, müssen wir im „Process Explorer“ zuerst unter „View“ die Option „Show Lower Pane“ sowie unter der Option „Lower Pane View“ den Menüpunkt „DLLs“ markieren.

Anschliessend fahren wir den Mauszeiger auf „Name“ im „Lower Pane“ und halten dabei die rechte Maustaste gedrückt. Dann wählen wir „Select Columns…“. Im neuen Fenster unter „DLL“ setzen wir die folgenden Optionen:

Jetzt sind sämtliche DLLs des IE-Prozesses zu sehen, inklusive ob diese ASLR unterstützen oder nicht. Im nachfolgenden Bild sehen wir auch schon ein Problem:

Das Leid mit alten Java-Installationen

Die DLL „msvcr71.dll“ unterstützt kein ASLR und wird daher stets an dieselbe Basis-Adresse, 0x7c340000, geladen. Diese DLL stammt von einer Java 6.x-Installation und wird jedes Mal in den IE-Prozess an die vorhersehbare Adresse geladen. Wichtiger Zusatz zu ASLR: Es wird jeweils nur die Basis-Adresse verändert. Die einzelnen Instruktionen innerhalb einer DLL bleiben zur Basis-Adresse konstant. Alles was ein Angreifer machen muss, um die Schwachstelle auf Windows Vista oder Windows 7 ausnutzen zu können, ist in dieser DLL nach verwertbaren ROP-Instruktionen zu suchen. Diese Methode ist seit längerem bekannt und wird unter anderem auch vom Metasploit-Modul bei Windows 7 verwendet:

Die meisten Drive-by-Exploits, die auf Windows 7 funktionieren, benötigen die alten Java-Plug-Ins zur Umgehung von DEP oder andere, nicht ASLR-kompatible DLLs. Wenn wir keine alte Java-Installation auf dem System haben, fällt dieser beliebte und häufig genutzte Angriffsvektor bei Windows Vista und Windows 7 weg. Fast alle Drive-by-Angriffe gegen neuere Windows-Betriebssysteme verlaufen damit im Sande, es sei denn, es handelt sich um Schwachstellen in Java selber. Doch dazu mehr im letzten Teil der Serie.

Fazit und Ausblick auf den letzten Teil

Mit wenigen Massnahmen – der Deinstallation von Java, der fortlaufenden Aktualisierung aller Software-Programme und der Verwendung eines aktuellen Windows-OS und Browsers – läuft der überwiegende Teil der Drive-by-Angriffe ins Leere. Nehmen wir die bekannten Exploit-Kits als Vergleich, dürfte dies bei fast 100% liegen. Der Grund: Kaum eines dieser Exploit-Kits wie Blackhole, Nuclear, Eleonore usw. nutzt unbekannte und damit ungepatchte Schwachstellen aus.

Allerdings werden Drive-by-Angriffe nicht nur für die Verteilung von 08/15-Schad-Software genutzt, sondern auch von professionelleren Gruppierungen zwecks Industriespionage eingesetzt. Das Know-how und die Ressourcen dieser Gruppierungen sind wesentlich höher. Im letzten Teil der Serie werden wir sehen, dass man die Schwachstelle trotz der oben aufgeführten und umgesetzten Massnahmen immer noch ausnutzen kann. Wir werden auch ein Tool von Microsoft vorstellen, das zusätzliche Hürden aufbaut und so auch einen Grossteil der fortgeschrittenen Angriffe blockiert.