Vom Patch zum Exploit - Fallbeispiel

Transkript

1 Vom Patch zum Exploit - Fallbeispiel Februar 2009 Autor: Renato Ettisberger SWITCH 2009

2 1. Einleitung Kurz nachdem eine Sicherheitslücke öffentlich bekannt wird, tauchen bereits die ersten Exploits dafür auf. Diese Zeitspanne ist mit den Jahren immer kürzer geworden, teilweise geschieht dies innerhalb weniger Stunden. Der Grund dafür ist hauptsächlich darin zu suchen, dass die Angreifer die von den Herstellern bereitgestellten Patches analysieren. Ist die Ursache der Sicherheitslücke erst einmal gefunden, lässt sich in aller Regel ein Exploit dafür entwickeln. Im April 2008 haben Forscher eine Arbeit zum Thema Automatic patch-based exploit generation veröffentlicht [1]. Sie kommen darin zu dem Schluss, dass sich durch automatisierte Analysen von Security-Patches entsprechende Exploits für diese Schwachstellen automatisch erzeugen lassen - und dies innerhalb von Minuten. Als Beweis wurde die Methode anhand von fünf Schwachstellen geprüft. Den Forschern ist es dabei lediglich gelungen, eine DoS-Attacke auszuführen. Jeder der sich mit dem Entwickeln von Exploits befasst, weiss genau, wie komplex einzelne Schwachstellen sind, beziehungsweise wie schwierig es ist, diese auszunutzen. Ein DoS- Angriff ist noch lange kein Exploit. So gesehen ist der Titel dieses Dokuments zugegebenermassen etwas provokativ. Es gilt aber festzuhalten, dass Angreifer mit der Analyse von Patches eigene Exploits entwickeln können. Anhand eines einfachen Beispiels wird dieser Prozess im Folgenden aufgezeigt. 2. Fallbeispiel: QuickTime Player Konkret betrachten wir eine Schwachstelle in Apple s QuickTime Player Software. Betroffen sind dabei QuickTime-Versionen 7.3 und älter. Die Schwachstelle ist bei neueren Versionen behoben. Als Ausgangspunkt der Analyse nutzen wir sofern vorhanden das vom Hersteller publizierte Advisory: Abbildung 1: Advisory des Herstellers Offensichtlich handelt es sich um einen Overflow, der im Zusammenhang mit dem Handling von RTSP-Daten auftreten kann. RTSP ist in diesem Fall die Abkürzung für Real Time Streaming Protocol. Dies ist ein weiterer Hinweis für den Analysten. RFC befasst sich mit dem RTS- Protokoll. Das Dokument rfc2326.txt wird sich im weiteren Verlauf der Analyse noch als hilfreich erweisen. 1 SWITCH /13

3 Abbildung 2: Auszug RFC2326 Als Nächstes benötigen wir die gepatchte und die ungepatchte Version von QuickTime. Beide sind auf der Seite von Apple verfügbar 2. Hier ist es entscheidend, unmittelbar aufeinander folgende Versionen für die Analyse zu verwenden. Ansonsten müssen wir uns mit sehr vielen Änderungen, die nichts mit der Sicherheitslücke selbst zu tun haben, herumschlagen. Selbstverständlich lässt sich dies nicht vollständig ausschliessen. Mit der Wahl der unmittelbar folgenden Versionen kann man dieses Problem aber auf das absolute Minimum reduzieren. Für unser Beispiel sind die Versionen 7.3 und interessant. Die Analyse erfolgt auf Windows. Nachdem wir zuerst die verwundbare Version (7.3) installiert haben, gilt es, den Fehler in den von QuickTime geladenen Modulen zu lokalisieren. Im schlimmsten Fall muss die Analyse bei allen Modulen erfolgen, inklusive des Binarys selbst. Dies ist ein zeitintensiver Prozess. Abbildung 3: Von QuickTime verwendete Module Dank des Advisories haben wir jedoch einen Hinweis, der uns die Arbeit erleichtern könnte. Das Problem tritt bei der Verarbeitung von Real Time Streaming auf. Drei Module beinhalten den String TimeStreaming. Es sind dies QuickTimeStreaming.qtx, QuickTimeStreamingAuthoring.qtx und QuickTimeStreamingExtras.qtx. Wir analysieren zuerst das QuickTimeStreaming.qtx Modul. Für die Analyse benötigen wir ein Tool, das Veränderungen zwischen unterschiedlichen Soft- 2 Eine weitere Quelle für ältere Softwareversionen ist filehippo.com SWITCH /13

4 wareversionen grafisch darstellen kann. Ein solch frei erhältliches Tool ist eeye s Binary Diffing Suite 3. Abbildung 4: Benutzeroberfläche von EBDS Allerdings baut dieses Tool auf Dateien auf, die mittels IDAPro 5.0 oder einer aktuelleren Version erstellt wurden. Wir laden deshalb die Datei QuickTimeStreaming.qtx in IDA Pro 5.0 und speichern das Resultat unter dem Namen QuickTimeStreaming_old.idb. Der Analyse-Prozess dauert je nach Dateigrösse wenige Minuten oder einige Stunden. Danach deinstallieren wir die Quick- Time-Version und installieren die gepatchte Version (7.3.1). Wiederum wird das Modul Quick- TimeStreaming.qtx mit IDA Pro 5.0 verarbeitet und unter dem Namen QuickTimeStreaming_new.idb gespeichert. Abbildung 5: Binary Diffing Starter 3 SWITCH /13

5 Anschliessend kann die Analyse mit dem Binary Diffing Starter erfolgen. Als Plugin wird Darun- Grim ausgewählt. Da wir lediglich zwei Dateien miteinander vergleichen, ist die Option File Diffing zu wählen. Nachdem wir die Datei xxx_old bei Pre-Path und die Datei xxx_new bei Post- Path selektiert haben, kann die Analyse beginnen. Ist die Analyse beendet, benötigen wir die zweite Applikation innerhalb der Binary Diffing Suite: DarunGrim. Damit lassen sich die Unterschiede zwischen den beiden Dateien grafisch darstellen. Abbildung 6: Oberfläche von DarunGrim Über den Menüpunkt File-> New... wählen wir die durch den Binary Diffing Starter erstellte Datei mit der Endung dg.db (Abbildung 7). Abbildung 7: Auswahl des DB-Files Dann sind die beiden Dateien auszuwählen, wobei eine die ungepatchte und eine die gepatchte Version darstellt. SWITCH /13

6 Abbildung 8: Auswahl der zu untersuchenden Dateien Schliesslich kann die Analyse erfolgen: Abbildung 9: Auswahl der entsprechenden Dateien Abbildung 10: Analyse mittels DarunGrim Das Resultat ist in diesem Fall nach einigen Minuten ersichtlich. Es werden die Funktionen der alten (Subroutine 01) und der neuen Version (Subroutine 02) aufgelistet. SWITCH /13

7 Abbildung 11: Ausgabe von DarunGrim Sortiert man die Ausgabe nach der Match Rate, zeigt sich nachfolgendes Resultat: Abbildung 12: Funktionen geordnet nach deren Match-Rate In diesem Beispiel wurde lediglich eine Funktion verändert. In den meisten Fällen ist dies allerdings nicht der Fall. Meist sind es zwischen 10, 20 oder gar 30 Änderungen. Das Tool erlaubt es uns, die geänderten Anweisungen innerhalb der entsprechenden Funktion anzuzeigen. Die Ausgabe ist in Abbildung 13 zu sehen. SWITCH /13

8 Abbildung 13: Darstellung der Veränderungen Verändert wurden die gelb dargestellten Bereiche. Orange markierte Bereiche sind in der älteren Version nicht vorhanden. Vergrössern wir den Ausschnitt rechts, sehen wir den Grund für die Sicherheitslücke. Abbildung 14: Ursprung der Schwachstelle Bei der dritten Anweisung von oben (cmp ecx 0FFh) wird geprüft, ob der Wert in ecx kleiner oder gleich dem Wert 255 ist. Ist dies der Fall, geht der Programmablauf bei loc_675a28a0 weiter. Ist der Wert in ecx grösser, wird der sich dort befindliche Wert einfach überschrieben. Es handelt sich hier wohl um eine Beschränkung einer Zeichenkettenlänge, einem typischen Patch für einen Overflow-Fehler. SWITCH /13

9 Wir kennen jetzt zwar den Ursprung des Fehlers. Ein Angreifer möchte daraus aber Kapital schlagen und einen Exploit für diese Schwachstelle entwickeln. Dazu ist es notwendig zu wissen, wie der fehlerhafte Code getriggert werden kann. Hier unterstützt uns ein Disassembler. Der Patch ist an Adresse 675A2897 ersichtlich. Interessant ist aber das Kommentarfeld an Adresse 675A2877. Es liefert uns eventuell einen Hinweis, wie wir den Fehler ausnutzen können. Abbildung 15: Disassemblierter Code der gefixten Schwachstelle Dazu benötigen wir die erwähnte Beschreibung in RFC2326.txt und suchen nach dem String Content-Type. In Abbildung 16 ist ein Beispiel einer Client-Server Kommunikation aufgeführt. Dabei taucht auch der String Content-Type auf. Abbildung 16: Beispiel einer Client-Server-Kommunikation mit Content-Type (RFC2326.txt) Als nächsten Schritt können wir QuickTime starten und OllyDbg an den entsprechenden Prozess anhängen. Bevor wir F9 drücken, setzen wir einen Breakpunkt an der Adresse 675A288f, also der cmp ecx, 0FFh Anweisung (siehe folgende Abbildung). SWITCH /13

10 Abbildung 17: Setzen eines Breakpunktes Anschliessend senden wir einen ähnlichen Server-Response wie derjenige in Abbildung 16 (Beispiel aus RFC2326.txt). Dazu dient das folgende Perlscript: #!/usr/bin/perl use Socket; use IO::Socket; $buffer =( application/sdp ); $body=( B x400); $header=( RTSP/ OK\n. CSeq: 1\n. Content-Type: $buffer\n. Content-Length: 270\n. \n. $body\n ); $port = 554; $server = new IO::Socket::INET( print Server started on port $port\n ; $in; while($client_addr = $server->accept()) { $answer = $client_addr->($in,1024,0); print $in; print $client_addr $header; } LocalPort => $port, Listen => 5, Proto => tcp, Reuse => 1) die no socket...$!\n ; Dies bindet einen Server an Port 554. Nachdem wir das Script ausgeführt haben, bauen wir mit QuickTime eine Verbindung zu diesem Server auf (rtsp:// ). SWITCH /13

11 Abbildung 18: Breakpunkt wird getriggert Wie in Abbildung 18 zu sehen ist, wurde der Breakpunkt getriggert. An dieser Stelle wird der Wert von ecx geprüft. Dieser beträgt 0xF oder 15 in Dezimal. Das ist genau die Länge des Strings application/sdp. Folglich beinhaltet ecx die Länge des Strings, der unmittelbar nach dem Content- Type Tag steht. Was passiert, wenn wir diesen String durch beispielsweise 6000 A s ersetzen?... $buffer =( A x6000); $body=( B x400); $header=( RTSP/ OK\n. CSeq: 1\n.... Abbildung 19: Breakpunkt wird erneut getriggert SWITCH /13

12 Wiederum wird der Breakpunkt getriggert. Der Wert von ecx beträgt nun 1770 H (6000 in Dezimal). Aufgrund des Patches wird die Sprunganweisung JBE... nicht ausgeführt, sondern vielmehr der Wert in ecx mit 255 überschrieben. Abbildung 20: Patch schliesst Sicherheitslücke Der Patch verhindert damit, dass die Länge mehr als 255 sein kann. Zur Verifizierung wird jetzt die gepatchte Version von QuickTime deinstalliert und die ungepatchte Version getestet. Das Perlscript bleibt dasselbe. Das Resultat ist in der nächsten Abbildung zu sehen. Durch fehlende Längenüberprüfung des Strings nach dem Content-Type Tag kommt es zu einem Overflow. Dies ermöglicht es dem Angreifer, Daten auf dem Stack zu überschreiben, was schlussendlich zur Kontrolle von eip führt. Von diesem Punkt an ist die Entwicklung eines Exploits ein Kinderspiel. Lediglich der Shellcode muss entsprechend angepasst werden. Abbildung 21: Fehler führt zu einem Overflow SWITCH /13

13 3. Fazit Mit der Analyse von Patches können Angreifer in manchen Fällen sehr rasch einen Exploit entwickeln. Dies ist jedoch nicht immer so einfach wie im eben vorgeführten Beispiel. Auf der anderen Seite hilft die Patch-Analyse auch Security-Teams bei der Beurteilung von Schwachstellen. Zumal es nicht selten vorkommt, dass der Software-Hersteller eine Schwachstelle offiziell als weniger gravierend einstuft, als sie tatsächlich ist. Dieses Dokument finden Sie auch auf unserer Internetseite unter: Referenzen [1] Automatic patch-based exploit generation SWITCH /13