Lehrstuhl für Systemsicherheit

Transkript

1 Lehrstuhl für Systemsicherheit Automatically Detecting Backdoors In Software SPRING 7 Berlin, Juli 2012 Felix Schuster

2 Agenda Einführung Ansätze zur automatisierten Identifizierung von Hintertüren WIESEL: Toolkit zur Identifizierung von Hintertüren Ausblick 2

3 Einführung Hintertüren Es gibt eine Reihe von denkbaren Hintertürklassen: 1. Manipulierte Authentisierung 2. Versteckte Befehle oder Dienste 3. Absichtlich platzierte klassische Verwundbarkeiten 4. Manipulierte oder unsichere kryptographische Verfahren 5. Andere Datenlecks oder Aufzeichnung von Daten 6. (Manipulierte oder gefährliche Ausgaben) z.b. Infizierung von ausführbaren Dateien durch FTP-Server 3

4 Einführung Hintertüren Die meisten Hintertüren basieren auf Auslösern: 1. Extern induzierte Daten Z.B. Schlüsselwörter wie etwa spezielle Usernames 2. Extern induzierte Ereignisse (Seitenkanal) Abfolge von Ereignissen (z.b. Login-Versuche) Dauer von Ereignissen 3. Globaler oder lokaler Kontext Z.B. Uhrzeit oder lokaler Zeit-Offset, CPUID 4

5 Einführung Hintertüren Beispiele RuggedCom ROS Authentisierung, 2012 ProFTPD HELP-Befehl, 2010 Passwort für festen Benutzer factory lässt sich von MAC-Adresse ableiten. Durch Angreifer installierte Hintertür. Wird dem Befehl HELP ein bestimmtes Schlüsselwort angehängt, lassen sich beliebige Shell-Befehle ausführen. ZTE Android, 2012 Auf ZTE Mobiltelefonen können über das Aufrufen eines vorinstallierten Programms Systemrechte erlangt werden. 5

6 Problemstellung Wie lassen sich Hintertüren automatisiert erkennen oder deren Auslösung verhindern? Bisher vor allem Veröffentlichungen im Hardware-Bereich. Einige Veröffentlichungen zur Verhinderung (silencing) der Auslösung von Hintertüren in letzter Zeit. Zielen vor allem auf die Verhinderung der Auslösung von Hintertüren. Neu-Sortierung von externen Ereignissen Abkapselung von Komponenten (z.b. kein Zugriff auf time()) Zurücksetzen von Komponenten vor jeder Ausführung... 6

7 Problemstellung Weniger (?) Veröffentlichungen zur Erkennung von Hintertüren. Statische Analyse von Software Dynamische Analyse von Hardware Z.B. Ausbrennen von während des Testens nicht verwendeten Schaltkreisen. 7

8 Ansätze Fokus der Forschungsgruppe auf dynamischer Erkennung in nativen Binärprogrammen Symbolische Ausführung (S²E, nur x86) Differentielles Debugging Firmware von Embedded Devices ist explizites Analyseziel. Erschwernisse durch unübliche Prozessorarchitekturen wie MIPS Erschwernisse durch häufig proprietäre Formate und Betriebssysteme in Firmwares Gebräuchliche Werkzeuge wie PIN können häufig nicht verwendet werden. 8

9 Ansätze Eine allgemeine Lösung ist nicht möglich. Auffinden von Buffer-Overflow Verwundbarkeiten ist bspw. Unterproblem. Fokussierung auf klar abgegrenzte Hintertürklassen notwendig Manipulierte Authentisierung Versteckte Befehle 9

10 Ansätze Differentielles Debugging Begriff des Differentiellen Debuggings wurde im Kontext von Zynamics BinNavi gerpägt. Prinzip 1. Aufzeichnung mehrerer Traces eines Programms für unterschiedliche Eingaben 2. Identifikation von Entscheidungsstellen mittels einfacher Mengenoperationen oder Graphenanalyse Identifikation von exklusiver Funktionalität (Handler) analog 10

11 Ansätze Differentielles Debugging Entscheider: Knoten aus Schnittmenge mit Kindern in allen Exklusivmengen Naiver Ansatz Funktioniert überraschend gut auch für komplexe Programme Anwendbar auf Funktions- und Basic-Block-Ebene 11

12 Ansätze Differentielles Debugging Automatisierte Identifikation von für die Erkennung von Hintertüren wichtigen Programmteilen Authentisierungsfunktion Zentraler Command-Dispatcher Gibt es BasicBlocks die für keinen Testcase durchlaufen wurden? Wieviele Kanten führen zum Auth-BB oder semantisch ähnlichen? Wieviele Befehle existieren? Existieren unbekannte Befehle? Command-Handler Welche Syscalls können erreicht werden? 12

13 Problematik Nicht immer sind Entscheidungen explizit im Flussgraphen einer Funktion sichtbar Conditional-Instructions wie cmovz auf x86 erweitern Flowgraph um implizite, virtuelle Kanten Auf MIPS und ARM noch häufiger anzutreffen. 13

14 WIESEL Python Toolkit/Framework für Differentielles Debugging auf verschiedenen Plattformen. gdbserver als Debugging-Engine Berücksichtigung von virtuellen Kanten auf Basic-Block-Ebene Unterstützung von aktuell MIPS und x86 Interface zur Beschreibung von Protokollen Block-basierter Ansatz wie beim Fuzzing-Toolkit Sulley 14

15 WIESEL Protokollbeschreibung 15

16 WIESEL Protokollbeschreibung 16

17 WIESEL Protokollkompilierung 17

18 WIESEL Erkennung von Entscheidern 18

19 WIESEL Erkennung von Entscheidern Problem Häufig trennen sich Pfade wiederholt kurzzeitig für einige Events vor der eigentlichen Entscheidungsfunktion. Z.B. wird bei ProFTPD u.a. für jedes Zeichen eines Befehls iterativ TO_UPPER() aufgerufen Naive Schleifen-Eliminierung und abweichungstolerante Vergleiche von Sequenzen liefern gute Resultate. 19

20 WIESEL Erkennung von Hintertüren Einfache Heuristik: Sämtliche nicht besuchte Kanten die zum identifizierten Auth-BB führen sind verdächtig. Sämtliche nicht besuchte BBs sind verdächtig. 20

21 Ausblick Semantische Analysen Automatisierte Behandlung von vermuteten Hintertüren Binary-Rewriting, z.b. Logging von Besuchen verdächtiger BBs Überprüfung von Embedded Firmwares Gibt es BBs die ähnlich sind zu einem identifizierten Auth-BB? Problem der Emulierung Unterstützung von Forks 21

22 Vielen Dank! Gibt es Fragen?