Potentially Dangerous Files

Transkript

1 Potentially Dangerous Files Das "Portable Document Format" ist seit seiner Entstehung zu weit mehr geworden, als einem Format zur Darstellung von Dokumenten. Viele nützliche Funktionen wurden im Laufe der Zeit hinzugefügt. Allerdings bergen insbesondere die Skriptingfunktionen per JavaScript ein hohes Missbrauchspotenzial, das von Malwareautoren in steigendem Masse ausgenutzt wird. Ralf Benzmüller Leiter der G Data Security Labs Karsten Tellmann imalware-analyst der G Data Security Labs Das Portable Document Format hat in den letzten Jahren in weiten Bereichen der digitalen Welt einen festen Platz eingenommen. Heutzutage sind über das Internet mehr als 200 Millionen PDF-Dateien frei zugänglich und Privatanwender, Firmen und Regierungen nutzen es in den unterschiedlichsten Anwendungsbereichen. Die erste PDF-Version wurde 1992 veröffentlicht. Mit den Jahren wurden immer weitere Funktionen in der FormatSpezifikation festgelegt und PDF ist heute in allen Bereichen der geschäftlichen Kommunikation und Dokumentenspeicherung ein fest etablierter Standard. Software zum Darstellen von PDF-Dateien ist auf fast allen Rechnern installiert. Die allgemeine Verfügbarkeit macht das PDF-Format höchst interessant für die Verbreitung von Malware. Mit den Fähigkeiten des Formats wächst auch dessen Komplexität und damit die Gefahr von Schwachstellen. Dies lässt sich deutlich an der gestiegenen Anzahl von Sicherheitslücken in den letzten Jahren feststellen. Die Anzahl der PDF-bezogenen Schwachstellen hat sich 2009 gegenüber 2008 von 38 auf 74 fast verdoppelt. Die Anzahl der Malware, die PDF als Trägerplattform verwenden, hat sich im vergangenen Jahr von 780 auf 2394 ungefähr verdreifacht. Immer öfter werden PDF-Sicherheitslücken auch in sog. Exploit-Toolkits eingesetzt. Solche Toolkits machen PDFSchwachstellen auch Malwareautoren verfügbar, die keine fundierten Kenntnisse über Exploits besitzen. Abb. 1: PDF-bezogene CVE-Einträge Die Kombination aus hohem Verbreitungsgrad der Software, hoher Anzahl an Schwachstellen und einfacher Integration in Malware machen PDF zu einem gefährlich unterschätzten Medium. Die Verbreitungswege sind genauso vielfältig wie die Angriffsmöglichkeiten. Angriffe können breit angelegt oder aber sehr gezielt sein. Mögliche Quellen sind z.b. Downloads oder eingebettete Dokumente auf kompromittierten Webseiten, Anhänge von s oder Peer- 1

2 to-peer Tauschbörsen. Gezielte Angriffe werden oft als Rechnung, Bewerbung oder Angebot getarnt. Die Motivation der Angreifer reicht vom Aufbau eines Botnetzes über Klickbetrug mit Adware bis hin zur Spionage. Aufbau einer PDF-Datei Um zu verstehen, wie PDFs als Träger von schädlicher Software missbraucht werden können, ist ein grundlegendes Verständnis des Dokumentenaufbaus notwendig. Prinzipiell besteht jedes PDF aus folgenden Elementen: in einem PDF mehrere Cross Reference Table und Trailer auftauchen. Der Einfachheit halber wird dieser Fall hier nicht näher betrachtet. Objekte Für die Betrachtung von schädlichen PDF-Dateien ist der Aufbau der einzelnen Objekte interessant. Der Inhalt dieser Objekte kann unterschiedlichste Dinge beschreiben: Text, Positionierung, Formatierung, Bilder, Navigation und vieles mehr. Für unsere Betrachtung sind einige Möglichkeiten besonders interessant: Zum Einen kann JavaScript in ein Objekt eingebunden werden, welches automatisch zum Bespiel beim Öffnen des Dokumentes oder beim Betrachten einer bestimmten Seite im PDF ausgeführt wird. Zum Anderen kann ein Objekt einen sogenannten Stream enthalten. Dieser Datenstrom ermöglicht das Einbetten von kodierten Elementen in ein PDF. So können z.b. JPG- Bilder oder komprimierte Texte in Streams abgelegt werden. Die Textkomprimierung erfolgt häufig mittels des Deflate Kodierungsalgorithmus. Der Inhalt eines Streams kann aufgrund dieser Kodierung nicht durch blosse Betrachtung mit einem Texteditor erschlossen werden. Das nutzen Malwareautoren, um schädlichen Programmcode zu verstecken. PDF-Exploit In einem typischen Szenario läuft das wie folgt ab: Eine bekannte Sicherheitslücke wird in einer Acrobat-JavaScript- Methode ausgenutzt. Hierzu wird innerhalb eines kodierten Stream-Objekts ein JavaScript abgelegt, welches beim Öffnen des Dokumentes automatisch 1. Header Gibt an, welche Version der PDF-Spezifikation dem Dokument zugrunde liegt. 2. Eine Reihe von Objekten Beschreiben den Inhalt des Dokuments. Innerhalb der Objekte werden Text, Formatierung, Bilder, Skripte u.ä. definiert. 3. Cross Reference Table Gibt an, an welcher Byte-Position im Dokument welches Objekt steht und in welcher Version es vorliegt. 4. Trailer Beschreibt, wie viele Objekte im Dokument enthalten sind, welches davon das Root-Element ist, also zuerst betrachtet wird, und an welcher Byte- Stelle im Dokument die Cross Reference Table zu finden ist. Beim Öffnen eines Dokumentes wird zuerst im Trailer nachgeschaut, welches das Root- Objekt des Dokumentes ist und an welcher Stelle der Cross Reference Table es zu finden ist. Für die Darstellung relevante Informationen werden verarbeitet und Verweise auf weitere Objekte werden mit Hilfe des Cross Reference Table verfolgt, bis sämtliche Objekte verarbeitet wurden. Änderungen an bereits bestehenden Dokumenten werden mittels inkrementellem Update durchgeführt. Diese Methode führt dazu, dass ausgeführt wird. Zusätzlich wird der JavaScript-Code mit gängigen Techniken verschleiert, um eine signaturbasierte Erkennung und eine manuelle Analyse zu erschweren. Theorie Ziel eines Exploits ist es, den eigenen Code auszuführen. Da die exakte Speicherbelegung des attackierten Prozesses in der Regel nicht bekannt ist, muss der Speicher zunächst so präpariert werden, dass der

3 eigentliche Schadcode später auch erreicht werden kann. In den meisten Fällen wird das Skript daher zunächst einen sog. Heap-Spray durchführen. Dazu werden Codesequenzen erzeugt, die aus zwei Teilen bestehen: 1. Eine Abfolge von No-Operation-Befehlen (NOPsled) und 2. der eigentliche Schadcode. Die NOPsled wirkt wie eine Rutschbahn und vergrössert die Chance, dass der Einsprungspunkt im Speicher letztlich zum Schadcode führt. Nun wird im JavaScript der eigentliche Exploit durchgeführt. Hierzu wird eine Acrobat- JavaScript-Methode mit speziell präparierten Argumenten aufgerufen. Der reguläre Programmfluss wird so manipuliert, dass das Programm in dem präparierten Speicherbereich landet. Der Schadcode besteht aus Assembler-Befehlen - dem Shellcode - die in den meisten Fällen entweder schädliche Dateien aus dem Internet auf den Rechner laden und ausführen oder eine Bindshell öffnen, mit der sich der Angreifer direkt mit dem System verbinden kann. Praxis Die im Folgendem gezeigten Beispiele (s. Seite 4) stammen aus einem Exploit, der die im Dezember 2009 unter der Bezeichnung CVE bekannt gewordenen Schwachstelle ausnutzt. Über die Weihnachtsfeiertage sind verschiedene Variationen dieses Angriffs beobachtet worden, wobei das hier betrachtete Beispiel zu den Ersten gehört die In the wild gesichtet wurden. Diese Sicherheitslücke betrifft alle Version von Adobe Reader und Acrobat bis einschliesslich Version 9.2. Am wurde die Version 9.3 veröffentlicht, in der diese Sicherheitslücke geschlossen ist. Wenn das richtige PDF-Stream- Objekt gefunden ist, kann der Inhalt mit dem passenden Algorithmus dekodiert werden. Das auf diese Weise erhaltene Script ist in Abbildung 3 dargestellt. Durch die Dekodierung entsteht der in Abbildung 4 dargestellte JavaScript-Code. In der Variable s1 steht eine Folge von hexadezimalen Werten, die nachfolgend in einer for-schleife verarbeitet wird. Dort wird auf jedes Zeichen von s1 die XOR-Operation mit dem hexadezimalen Wert 5C angewandt und das ASCII-Zeichen des resultierenden Werts bestimmt. Das so erzeugte JavaScript steht nach dem Schleifendurchlauf in s2 (vgl. Abbildung 4) und wird mit der eval-methode ausgeführt. Zuerst wird die Methode NS() ausgeführt, welche den Heap- Spray realisiert. In der Variable "nop" wird das Zeichen für die NOPs definiert. Üblicherweise werden dazu Unicode-Zeichen genutzt, im vorliegenden Fall, um vier Mal den Wert 0x90 zu schreiben. 0x90 steht in Assembler für die NOP- Instruktion. In der while- Schleife wird aus diesen vier Zeichen eine NOPsled mit passender Länge konstruiert. Die folgende for-schleife hängt an diese NOPsled den in der Variable "sc" definierten Shellcode an und speichert diese Kombination 4096 Mal hintereinander in das Array "memory". So entsteht im Heap des Arbeitsspeichers ein 256MB grosser Block mit NOPsleds und Shellcodes. Nach diesen Vorbereitungen kann der Exploit ausgeführt werden. Im vorliegenden Fall wird dazu eine Schwachstelle genutzt, die auf zuvor freigegebenen Speicher erneut zugreift. Der Fehler passiert in der Methode "Doc.media.newPlayer", die mit einem NULL-Objekt initialisiert wird. Der Parameter, der beim Aufruf der Funktion "util.printd" übergeben wird, enthält eine Sprungadresse, die im Idealfall den zuvor präparierten Bereich adressiert. Die normale Verarbeitung des Programms bricht ab und die Instruktionen des Heap-Sprays werden angesteuert. So wird letzten Endes der Shellcode ausgeführt. Der initiierte Fehler führt dann dazu, dass Acrobat bzw. Reader nach dem Exploit abstürzen. Erwähnenswert ist hier noch, dass zu Beginn des JavaScripts die Versionsnummer des verwendeten Readers ermittelt wird. Häufig sind für bestimmte Software eine zu dieser Version passende Schwachstelle erstellt. Insbesondere durch Exploit- Packs generierte PDF-Dateien fragen in der Regel drei bis vier Versionen ab und starten dann den passenden Angriff.

4 Abb. 3: Deflate kodiertes JavaScript Abb. 4: Obfuscated JavaScript Abb. 5: CVE im Klartext 4

5 Gegenmassnahmen Der Virenschutz hat die Aufgabe, aktuellen Schadcode zu finden und dessen Ausführung zu verhindern. Das Beispiel zeigt, dass es für Angreifer sehr einfach ist, viele Varianten der gleichen Ausgangsdatei zu erstellen (der Wert 5C kann beliebig geändert werden). Daher sollte der Virenschutz stets auf dem neuesten Signaturstand gehalten werden. Signaturbasierte Ansätze von Virenschutzprogrammen stossen dennoch schnell an ihre Grenzen. Daher setzen viele Antiviren-Programme mittlerweile auf proaktiven Schutz und verhaltensbasierte Erkennung. In sensiblen Unternehmensbereichen können Buffer-Overflow- Protection-Produkte zusätzliche Sicherheit bieten. Eine weitere Pflichtaufgabe ist das Patch-Management. Je aktueller die Software und das Betriebssystem sind, desto geringer ist die Chance, dass ein Angriff erfolgreich ist. PDF- Verarbeitungs- und Darstellungsprogramme sollten regelmässig aktualisiert werden. Abgesehen von den aktuellen Patches enthalten neuere Versionen oft zusätzliche Sicherheitseinstellungen. Es gibt aber noch andere Möglichkeiten, den PDF- Attacken zu entgehen. Aus der Schusslinie Der Adobe Reader bzw. Acrobat ist der am meisten verwendete PDF-Betrachter. Exploits für Software von Marktführern werden viel häufiger in Malware verwendet als für weniger verbreitete Alternativen. Es existieren viele kostenlose, alternative Programme wie z.b. Foxit Reader, PDF-XChange Viewer, Sumatra oder GSview 1, die häufig dem Marktführer in puncto Funktionalität und Ergonomie in nichts nachstehen. Data Execution Prevention (DEP) In modernen Windows- Betriebssystemen wird zwischen Speicherbereichen mit ausführbarem Programmcode und Bereichen mit Daten unterschieden. Normalerweise sollte der Bereich mit Daten keinen ausführbaren Programmcode enthalten. Es gibt allerdings (meist begründete) Ausnahmen. Die Datenausführungsverhinderung, kurz DEP, unterbindet die Ausführung von Programmcode in als nicht ausführbar gekennzeichneten Bereichen des Arbeitsspeichers. Da die vorgestellte Heap-Spray Technik (normalerweise) nur Speicher im Datenbereich belegt, kann man den vorgestellten Angriff mit der Aktivierung von DEP für Adobe Reader effektiv unterbinden. Standardmässig ist DEP nur für Microsoft-Produkte aktiviert und muss für die meisten andere Produkte gesondert aktiviert werden. Das sollte zuvor aber individuell getestet werden. Seit Version 9.0 aktivieren Adobe Reader und Acrobat DEP automatisch bei der Installation. Da es jedoch mittlerweile Methoden 2 gibt, sich dem Zugriff durch DEP zu entziehen, sollte 1 Eine umfangreiche Liste von Programmen zur Darstellung und Verarbeitung von PDF Dateien gibt es bei Wikipedia: PDF-Software 2 Siehe man sich nicht alleine auf diese Schutzmassnahme verlassen 3. Methode Holzhammer: JavaScript deaktivieren Ähnlich wie vor Jahren die Makrofunktionen in Word- (und anderen Office-)Dokumenten werden aktive Inhalte in PDFs nur von den wenigsten Nutzern benötigt. In diesem Fall kann man die Ausführung von JavaScript in den PDF- Darstellungsprogrammen deaktivieren. In den meisten PDF- Programmen geht das so: STRG+K => JavaScript => Häkchen bei "JavaScript aktivieren" entfernen Aber auch hier ist die Schutzwirkung nicht umfassend. Nicht alle Exploits brauchen JavaScript, z.b. wenn sie eine Schwachstelle des Programms direkt ausnutzen 4. Da Angriffe dieser Art aber in der Regel JavaScript benutzen, um den Heap-Spray durchzuführen, kann so die Ausführung des Shellcodes oft verhindert werden. Feinschliff: Acrobat JavaScript Blacklisting Seit Version und 9.2. des Adobe Reader und Acrobat existiert das JavaScript Blacklist Framework. Es bietet die Möglichkeit, die Ausführung von Funktionen in Acrobat und Reader gezielt zu blockieren. Wer auf JavaScript nicht verzichten kann, hat so die 3 Weitere Informationen zu DEP finden Sie unter: Dies betrifft beispielsweise Schwachstellen in der Verarbeitung von JBIG2 kodierten Streams 04/quickpost-jbig2decode-trigger-trio/

6 Möglichkeit bestimmte (gefährdete) Acrobat-JavaScript- Funktionen abzuschalten. Dies ist über den folgenden Registry- Key möglich: HKLM\SOFTWARE\Policies\ Adobe\product\version\Fea turelocdown \cjavascriptperms\tblack List In diesem Key werden sämtliche Funktionen, die nicht mehr ausgeführt werden sollen, jeweils durch den Pipe-Operator getrennt eingetragen 5. Folgende Funktionen sind gute Kandidaten: Collab.getIcon Doc.getAnnots Doc.syncAnnotScan DocMedia.newPlaye r Spell.customDictionaryOpe n Util.printf Leider setzt das Framework fundiertes Wissen über die Funktionsweise von Registry und Acrobat voraus und Änderungen sollten nur mit angemessener Absicherung erfolgen. Verwundbare Funktionen lassen sich so aber gezielt aus dem Verkehr ziehen, bis ein Patch für die Schwachstelle verfügbar ist. Gut eingestellt Ausser den Einstellungen bzgl. JavaScript bieten auch andere Grundeinstellungen der PDF- Darstellungsprogramme Potenzial, um die Sicherheit bei der Anzeige von PDF-Dateien zu erhöhen. Dazu zählen z.b. die Berechtigungen bzgl. der Ausführung von Dateien und Multimediainhalten oder die Rechte zum Nachladen von Daten aus dem Internet. Welche Einschränkungen sinnvoll sind, variiert je nach Anwender. Spitz, pass auf! Neben den technischen Schutzmassnahmen sind auch die Nutzer gefragt. Ein erster Schritt ist schon getan, wenn PDF als Gefahrenquelle erkannt ist. Aufmerksame Mitarbeiter können dann verdächtige PDFs ignorieren und/oder den Sicherheitsverantwortlichen melden, wenn ein PDF zu unvorhergesehenem Verhalten des PDF- Readers führt. Sorgsam geschulte und wachsame Mitarbeiter können die technisch erlangte Sicherheit effektiv ergänzen. Fazit Das PDF-Format hat die Funktion eines statischen Darstellungsformates längst hinter sich gelassen. Die vielen neuen Funktionen bergen Gefahren, denen sich jeder Nutzer bewusst sein sollte. Die Verwendung von PDFs zur Verbreitung von Malware, insbesondere über Webseiten, steigt permanent. Alle PDF-Nutzer sollten gebührende Vorsicht walten lassen und über den Einsatz von technischen Schutzmassnahmen nachdenken. 5 Das Video unter e-reader-javascript-blacklist-framework/ veranschaulicht die Funktionsweise.