otsmr/blackbox-fuzzingFuzzing von IoT-Geräten am Beispiel des Routers TL-WR902AC
Dies ist die HTML-Version meiner Studienarbeit, die als PDF hier heruntergeladen werden kann.
Fuzzing hat sich zu „einer der effektivsten Methoden“ entwickelt, um Fehler in Software zu finden. Mit dieser oder ähnlichen Behauptungen beginnen viele aktuelle Arbeiten zum Thema Fuzzing [google-scholar]. Das Hauptziel unserer letzten Studienarbeit zum Thema „Internet of Vulnerable Things“ war es, einen speicherbezogenen Fehler zu finden und anschließend einen Exploit für diese Schwachstelle zu schreiben. Wir konnten eine Schwachstelle durch das Reverse Engineering der Firmware finden, aber es wurden keine speicherbezogenen Fehler gefunden. Einen Pufferüberlauf durch manuelles Reverse Engineering einer Binärdatei zu finden, ist nicht nur zeitaufwendig, sondern erfordert auch viel Erfahrung. Fuzzing zielt gleichzeitig darauf ab, der „effektivste Weg“ zu sein, um solche speicherbezogenen Schwachstellen zu finden. Google zum Beispiel hat OSS-Fuzz eingeführt, das kontinuierlich Open-Source-Software fuzzt und bereits über 10.000 Schwachstellen in 1.000 Projekten gefunden hat [oss-fuzz].
Das Ziel dieser Studienarbeit ist es erneut, eine speicherbezogene Schwachstelle zu finden, diesmal jedoch mithilfe von Fuzzing. Die angestrebte Schwachstelle soll über das Netzwerk ausnutzbar sein, ohne Kenntnis der Administrator-Anmeldedaten. Dieses Papier beschreibt den Weg zur Erreichung dieses Ziels. Dazu ist das Papier in zwei Teile gegliedert. Der erste Teil konzentriert sich darauf, wie man ein vielversprechendes Ziel findet, welche Werkzeuge verwendet werden können und was ein gutes Fuzzing-Ziel ausmachen sollte. Der zweite Teil beschreibt dann, wie man einen Harness entwickelt und debuggt, der in der Lage ist, eine bestimmte Funktion in einer Binärdatei zu fuzzen. Anschließend wird der entwickelte Harness von AFL++ verwendet, um die Zielfunktion zu fuzzen. Im Folgenden werden ein kurzer Hintergrund und der aktuelle Stand der Technik im Bereich IoT-Geräte-Fuzzing dargestellt.
Alle im Rahmen dieser Studienarbeit erstellten Dateien werden ebenfalls vollständig auf GitHub veröffentlicht und können über die folgende URL abgerufen werden: otsmr/blackbox-fuzzing.
Fuzzing von IoT-Geräten ist nicht so einfach wie das Fuzzing eines Open-Source-Projekts. Oft ist der Quellcode proprietär, was Gray-Box-Fuzzing, bei dem der Quellcode für die beste Fuzzing-Leistung instrumentiert wird, unmöglich macht [afl-persistent]. Außerdem wird die CPU-Architektur von Fuzzern oft nicht nativ unterstützt, was einen Emulator wie QEMU [qemu] erfordert, was ebenfalls die Fuzzing-Geschwindigkeit verlangsamt [afl-persistent]. Ein weiteres Problem sind die Hardware-Peripheriegeräte, was die Entwicklung eines allgemeinen Ansatzes erschwert. Die Arbeit „Embedded Fuzzing: A Review of Challenges, Tools, and Solutions“ [embedded-fuzzing] gibt einen Überblick über verschiedene Fuzzing-Strategien, wie hardwarebasiertes Embedded-Fuzzing. Die meisten dieser Strategien benötigen den Quellcode des Zielprogramms, z. B. wenn der Quellcode von Fuzzern wie AFL auf ARM-basierte IoT-Geräte portiert wird, um den Fuzzer auf der IoT-Hardware auszuführen. Auch das Ausführen des Fuzzers auf der Hardware des Geräts führt zu Leistungsproblemen, da diese häufig über CPUs mit geringer Leistung verfügen, die langsamer sind als normale Desktop-CPUs. Ein weiterer in dieser Arbeit vorgestellter Ansatz ist emulationsbasiertes Embedded-Fuzzing. Dabei wird entweder ein einzelnes Zielprogramm in einem Emulator ausgeführt, um coverage-guided Fuzzing durchzuführen, oder das gesamte System.
Die oben genannten Ansätze zielen alle direkt auf eine Binärdatei ab, indem sie einen Emulator verwenden oder den
Quellcode instrumentieren. Diese Ansätze erfordern ein Fuzzing-Setup, das oft speziell für ein einzelnes IoT-Gerät
maßgeschneidert werden muss und schwer zu verallgemeinern ist. Aus diesem Grund haben Forscher ein Programm
IoTFuzzer entwickelt, das ein automatisiertes Fuzzing-Framework sein soll, das darauf abzielt,
„Speicherkorruptionsschwachstellen ohne Zugriff auf ihre Firmware-Images zu finden
[iotfuzzer].“
IoTFuzzer basiert auf der Beobachtung, dass die meisten IoT-Geräte eine mobile App zur Steuerung haben und solche
Apps Informationen über das Protokoll enthalten, das zur Kommunikation mit dem Gerät verwendet wird. Das Programm
identifiziert und verwendet dann programmspezifische Logik wieder, um die Testfälle zu mutieren und IoT-Ziele effektiv zu
testen [iotfuzzer].
Ein Harness beschreibt eine Sequenz von API-Aufrufen, die die vom Fuzzer bereitgestellten Eingaben verarbeiten. Im Gegensatz zu einer normalen Anwendung, die oft keinen Harness benötigt, muss eine Bibliothek, die wiederverwendbare Funktionen implementiert, mit den richtigen Parametern und auch in der richtigen Reihenfolge aufgerufen werden, damit der Zustand zwischen mehreren gemeinsamen Funktionsaufrufen aufgerufen werden kann. Wenn die Bibliothek zufällig gefuzzt wird, ohne die Zustandsmaschine aufzubauen, wird das wahrscheinlich nicht erfolgreich sein und stattdessen eine Menge falsch-positiver Abstürze erzeugen, wenn die Abhängigkeiten der Bibliothek nicht erzwungen werden. Dies kann zum Beispiel passieren, wenn eine Puffergrößenprüfung vom Fuzzer übersprungen wird, was zu einem scheinbaren Pufferüberlauf führt.
In diesem Papier werden normale Anwendungen gefuzzt, aber wegen der Hardware-Abhängigkeiten bei der Verwendung von Sockets und Multithreading müssen wir auch für sie einen Harness erstellen. Der Harness wird im Kontext der Binärdatei geladen und kann interne Funktionen des Zielprogramms aufrufen, wie in Code 10 gezeigt.
Der Begriff „Corpus“ beschreibt gültige Eingabebeispiele oder Testfälle und dient als grundlegende Referenz für die Erzeugung neuer Eingabedaten während des Fuzzing-Prozesses. In Code 10 wäre dies beispielsweise eine HTTP-Anfrage. Fuzzer nutzen diesen Corpus, um mutierte oder diversifizierte Testfälle zu erzeugen, was die Erkennung von Softwareschwachstellen durch die Erkundung verschiedener Eingabeszenarien unterstützt.
Der zeitaufwendigste Teil des Blackbox-Fuzzing ist das Finden einer potenziell verwundbaren Funktion in der Firmware.
Der erste Schritt besteht darin, interessante Binärdateien zu finden, die zum Beispiel über das Netzwerk erreichbar sind,
unsichere Funktionen verwenden oder keine Sicherheitsfunktionen wie Stack-Canary aktiviert haben, was ein Schutz vor
Pufferüberläufen ist. Unsere letzte Arbeit
([iovt])
hat bereits beschrieben, wie man die Firmware aus dem Zielrouter extrahiert und wie man eine potenziell gefährliche
Binärdatei findet. Dazu wurde das Tool EMBA [emba] verwendet. EMBA bewertet alle
in der Firmware gefundenen Binärdateien nach der Anzahl unsicherer Funktionen wie strcpy, Netzwerkzugriff und
Sicherheitsmechanismen wie Stack-Canary oder dem NX-Bit, die bei der Ausnutzung eines Pufferüberlaufs interessant werden,
was in Code 1 zu finden ist.
