PDF-Malware: Probleme, Eigenschaften & Schutz, Teil 2

Bisher war keinem der Versuche Erfolg beschieden, dass PDF-Format durch ein anderes Dateiformat zu ersetzen. Administratoren müssen deshalb auch weiterhin mit den PDF-Dateien und deren Sicherheitsproblemen leben müssen. Unser Autor hat im ersten Teil dieses Berichts gezeigt, wie die PDF-Dateien aufgebaut sind und welche Bedrohungen dadurch entstehen können. Hier stellt er nun die verschiedenen Schutztechniken der modernen Windows-Systeme vor, und erläutert wie sie gegen die Gefahren helfen können, die durch schadhafte PDF-Dateien drohen.

Zu Beginn dieses zweiten Teils wollen wir zunächst noch einmal zusammenfassen, nach welchem generellen Schema infizierte PDF-Dateien ihre schädlichen Aktionen ausführen können:

• Wenn das Dokument mit einem PDF-Reader gelesen wird,
• wird automatisch ein Programmcode in JavaScript ausgeführt.
• Dieses Skript füllt den Heap mit Maschinencode (Shellcode) und steuert einen Schwachstelle an, die entweder in der PDF-Sprache oder in JavaScript existiert.
• Dadurch wird der Shellcode auf dem Heap ausgeführt, der dann einen Trojaner oder ein anderes Schadprogramm vom Web lädt und ausführt.

Schäden vermeiden: Mögliche Abwehr- und Schutzmaßnahmen

Was können Administratoren nun dagegen unternehmen, dass die Programmierer solchen Schadprogramme solche Schwachstellen für ihre Zwecke ausnutzen? Eine Lösung, die vor allen Dingen von den Anbietern der PDF-Reader immer wieder propagiert wird, ist es, die Ausführung von JavaScript im Reader entsprechend zu unterbinden. Sie lässt sich zumeist bei den Einstellungen auf „disable“ setzen. Diese Art der Vorgehensweise ist besonders dann sinnvoll, wenn es sich um gerade erst entdeckte Schwachstellen handelt: Durch das „Abstellen“ der JavaScript-Engine wird es auch unmöglich, dass eine Heap-Spray-Aktion, wie sie zuvor geschildert wurde, durch das Programm ausgeführt wird.

Eine weitere bewährte Abwehrtechnik besteht darin, die PDF-Reader nur mit einem Benutzerkonto Accounts auszuführen, das geringe oder wenigstens nur normale Zugriffsrechte besitzt. Da der Shellcode in vielen schädlichen PDF-Dokumenten versucht, ein Schadprogramm im Verzeichnis System32 abzulegen, benötigt das Programm dazu administrative Rechte. Werden dem Programm die administrativen Rechte entzogen, so ist das Download-Programm zwar noch dazu in der Lage, einen Trojaner aus dem Netz herunterzuladen – es wird aber bei der Ausführung dieses Programms scheitern, dass es den Trojaner nicht in System32 abspeichern kann. Zudem existieren eine ganze Reihe von Schadprogrammen und Trojaner, die administrative Rechte benötigen, um sich selbst in das Betriebssystem zu integrieren.

Zu den ebenfalls sehr erfolgreichen Abwehrtechniken gehört der Gebrauch der DEP (Data Execution Prevention) — ein Sicherheitsfeature, dass in den Windows-Systemen mit dem sehr sperrigen Begriff Datenausführungsverhinderung bezeichnet wird.

In einem Windows-Betriebssystem werden Daten im Speicher entweder als „Daten“ oder „Ausführbarer Code“ (executable) gekennzeichnet. Der zuvor schon beschriebene Heap-Speicher ist vom System als Datenbereich angelegt – er ist nicht dafür gedacht, dass sich an dieser Stelle ausführbarer Code befindet! Aber bevor die DEP-Technik mit dem Service Pack 2 für Windows XP für die Windows-Betriebssysteme zur Verfügung stand, haben die CPUs auch Instruktionen direkt ausgeführt, die im Speicher an Stellen abgelegt waren, die eigentlich nur für Daten gedacht waren und sind.

Wird DEP eingeschaltet (Bild 1), so verändert sich die Art und Weise, wie der Prozessor in diesen Fällen reagiert: Er wird nun keinen Code (auch keinen Shellcode) mehr ausführen, der sich im Hauptspeicher an Plätzen befindet, die wie der Heap für Daten reserviert sind.

Die Programmer sind in der Verantwortung

Aber auch die Programmierer der PDF-Reader sind hier in der Verantwortung: Sie müssen die Programme so entwickeln, dass Speicherbereich wie der Heap vom Programm ausdrücklich nur als Datenbereich verwendet werden können. Zudem müssen sie sicherstellen, dass DEP für ihre Programme eingeschaltet ist. Wenn die Anbieter der entsprechenden Programme dazu nicht willens oder nicht in der Lage sind, können Administratoren noch den Einsatz des Microsoft Enhanced Mitigation Expierence Toolkits (EMET) erwägen: Mit seiner Hilfe ist es möglich, den Einsatz von DEP für ganz spezifische Programme zu erzwingen.

Allerdings dürfen all diese Maßnahmen nicht darüber hinweg täuschen, dass die Entwickler von Schadsoftware auch Wege gefunden haben, den DEP-Schutz zu umgehen: Sie schreiben keinen selbstentwickelten Shellcode mehr in den Speicherbereich des Heaps. Sie entwickeln stattdessen den von ihnen benötigten Programmcode dadurch, dass sie die bereits existierenden Anweisungen durchsuchen, die von ausführbaren Dateien (exe- und DLL-Dateien) in den Adressraum für Prozesse geladen wurden.

Diese Technik wird als Return-Oriented Programming (ROP) bezeichnet und die einzelnen Teile an geliehenen Programmcode werden als ROP-Gadgets bezeichnet. Erfahrene Malware-Entwickler können in der Regel voraussehen, an welche Speicherstellen im Hauptspeicher der ausführbare Code geladen wird. Auf diese Weise sind sie dann dazu in der Lage, sind Teile dieses Programmcodes für ihre ROP-Gadgets „auszuleihen“ und so auch Schwachstellen in Anwendungen auszunutzen, die durch DEP eigentlich davor gefeit sein sollten.

Zufällige Auswahl des Speicherplatzes kann schützen

Um diese Art von Problemen zu bekämpfen, wurde ab Windows Vista eine weitere neue Schutztechnik eingeführt, die als ASLR – Address Space Layout Radomization bezeichnet wird. Durch den Einsatz dieser Technik wird sichergestellt, dass ausführbare Dateien nicht immer an die gleiche Stelle des Hauptspeichers geladen werden. Es wird eine (Semi-) Zufallsadresse im Hauptspeicher errechnet, so dass es für die Autoren der Schadsoftware weitaus schwerer wird, die Programmstücke zu finden, die sie für ihre ROP-Gadgets benötigen.

Wer allerdings von dieser Technik profitieren will, muss dazu eine neuere Windows-Version verwenden, da Windows XP sie nicht zur Verfügung stellt. Zusätzlich müssen die Entwickler einer Anwendung die ausführbaren Dateien für die ASLR-Unterstützung markiert haben. Auch hier steht Administratoren aber wieder der Einsatz von EMET als Ersatz zur Verfügung, wenn die entsprechende Anwendung nicht für diese Technik vorbereitet wurde.

Aber auch Programme von Softwareherstellern, die ihre Anwendungen mit der ASLR-Unterstützung versehen haben, können gegenüber ROP-Angriffen verwundbar sein. Dieser Fall tritt dann ein, wenn sie in ihren Programmen DLL-Bibliotheken verwenden, die eben nicht diesen ASLR-Schutz unterstützen. Das ist besonders häufig bei den Shell-Erweiterungen der Fall, die beispielsweise den Windows-Explorer mit zusätzlichen Funktionalitäten beim Kontextmenü (Rechtsklick) ausstatten.

Wer beispielsweise das bekannte Winzip-Programm auf einem Windows-Rechner installiert, bekommt zusätzlich eine Erweiterung installiert, die einen Menüeintrag zum Kontextmenü des Windows-Explorers und all der Anwendungen hinzufügt, die von den Standard-Dialogboxen „open“ und „save“ in Windows Gebrauch machen. Glücklicherweise unterstützt diese Shell-Erweiterungs-DLL der Winzip-Software auch die ASLR-Technik, so dass hier keine Gefahr besteht.

Sicherheit auch durch Isolation: Sandboxes können helfen

Leider sind aber nicht alle Software-Hersteller so umsichtig, so dass Administratoren gerade dann, wenn eine Software eine solche DLL für eine Shell-Erweiterung installieren will, entsprechend wachsam sein sollten. Eine weitere Abwehrtechnik, die aktuell immer populärer wird und deshalb in diesem Rahmen auch nicht unerwähnt bleiben sollte, ist das sogenannte „Sandboxing“ – die Isolation eines Programms in einem abgeschirmten Bereich.

Mit Hilfe dieser Technik wird eine Applikation mehr oder minder vollständig von den Ressourcen des darunterliegenden Betriebssystems abgeschirmt. So können Administratoren spezielle Programme installieren, die einen solchen „Sandkasten“ zur Verfügung stellen, um wenig vertrauenserweckende Programme entsprechend abzuschirmen. Zudem wird die Fähigkeit solche Abschirmungen zu errichten auch in immer mehr Standardprodukten integriert: Einige Beispiele sind der Internet Explorer ab der Version 7, Microsoft Office ab der Version 2010 und der Acrobat Reader von Adobe ab der Version X.

Die meisten Sandbox-Anwendungen setzten auf Sicherheitsfeatures des Windows-Betriebssystems wie etwa Integritäts-Level und eingeschränkte Token auf: So können sie Exploits und Malware innerhalb der Sandbox behalten. Auch Maschinencode wie der im ersten Teil unseres Artikels ausführlich erläuterte Shellcode kann so nicht aus dieser Absperrung „ausbrechen“. Je nach der Art, wie die Sandbox implementiert wurde, besitzt sie nur lesenden Zugriff auf Dateisystem und Registry (das ist beim Acrobat Reader X der Fall) oder ist wie bei Google Chrome komplett vom Rest des Betriebssystems isoliert.

Nur mehrfache Schichten können wirklich helfen

Wie bei vielen anderen Sicherheitsprobleme kann auch hier wiederum nur der grundsätzliche Rat an die Systembetreuer und Administratoren ergehen: Es gibt keinen besseren Schutz von Schwachstellen und Angriffen – und das gilt auch für die Schwachstellen in den PDF-Dateien – als sowohl das Betriebssystem als auch wichtigen Anwendungen immer auf dem aktuellen Stand zu halten.

Wenn die Anbieter eines Programms der Sicherheit nicht genügend Aufmerksamkeit schenken und kein Wechsel auf ein anderes Programm möglich ist, sollten Administratoren selbst tätig werden und entweder Microsofts EMET-Lösung zur Absicherung eines bestimmten Programms verwenden oder die Programme gleich in einer Sandbox-Umgebung einsetzen. Zwar hat sich unser Autor in diesem Artikel auf die PDF-Dateien und die entsprechenden Reader-Programme konzentriert, aber alle hier gezeigten Probleme und Lösungsansätze gelten ebenso für andere Dateitypen und Programme, die mit Dokumenten zu tun haben: Das gilt auch für die Office-Programme und -Dokumente von Microsoft.

Noch ein wichtiger Hinweis zum Abschluss: Unser Autor hat sich bei seinen Erläuterungen auf die Abwehr von Malware konzentriert, die „in the wild“ auftauchen kann und immer wieder auftaucht. Wer eine Systemumgebung betreibt, bei der es um sehr hohe Sicherheitsanforderungen geht und damit rechnen muss, dass genau gezielte Angriffe auf seine IT und Anwendungen durchgeführt werden, wird zu weiter gehenden Schutzmaßnahmen greifen müssen, denn ich diesen Fällen kennt der Angreifer die Systeme, Programme und Umgebungen sowie ihre Schwachstellen zu gut. Dann sind es Whitelisting-Lösungen, die nur genau getestete und sichere Programme zulassen, die eine entsprechende Sicherheit bieten können.

Didier Stevens/ fms