ttdennis/fpickerFrida-basierte In-Prozess-Fuzzing-Suite mit AFL++-Proxy, eigenständigen aktiven/passiven Modi und Shared-Memory-Kommunikation für leistungsstarke, abdeckungsgesteuerte Schwachstellensuche auf verschiedenen Plattformen.
fpicker ist eine auf Frida basierende Fuzzing-Suite, die eine Vielzahl von Fuzzing-Modi für In-Process-Fuzzing bietet, wie zum Beispiel einen AFL++-Modus oder einen passiven Tracing-Modus. Sie sollte auf allen Plattformen laufen, die von Frida unterstützt werden.
Einige Hintergrundinformationen sowie die Gedanken und Ideen hinter fpicker finden sich in einem Blogbeitrag, den ich geschrieben habe.
Fpicker basiert auf früheren Arbeiten an ToothPicker, die im Rahmen meiner Masterarbeit entwickelt wurden. Der Großteil von fpicker wurde während der Arbeitszeit bei meinem Arbeitgeber (ERNW) entwickelt.
Erforderlich für die Ausführung von fpicker:
frida-core-devkit für die jeweilige Plattform, das unter Frida-Releases auf GitHub zu finden ist.
libfrida-core-ios.a, libfrida-core-macos.a oder libfrida-core-linux.a.frida-core.h). Speichern Sie sie je nach Plattform als frida-core-linux.h oder frida-core-ios.h.update_frida_version.sh aus.Nur erforderlich, wenn im AFL++-Modus ausgeführt:
CFLAGS="-DUSEMMAP=1".CFLAGS="-DUSEMMAP=1 -DTARGET_OS_IOS".Fpicker kann für macOS, iOS oder Linux erstellt werden. Das Makefile unterstützt derzeit nur das Erstellen für iOS unter macOS, aber es sollte durchaus möglich sein, fpicker mit einer iOS-Toolchain unter Linux zu bauen.
Führen Sie je nach gewünschtem Ziel aus:
make fpicker-macos
make fpicker-ios
make fpicker-linux
um fpicker zu bauen.
Sobald fpicker gebaut ist, muss als nächstes die Fuzzing-Harness erstellt werden:
Siehe den Beispiele-Ordner für verschiedene Beispiel-Fuzzing-Fälle. Der allgemeine Ansatz ist wie folgt:
examples/test/test.js) (siehe hier für weitere Informationen zu Harnesses)frida-compile test.js -o harness.jsJetzt kann fpicker mit dem Fuzzing beginnen. Der genaue Befehl hängt stark von der Konfiguration und dem Setup ab. Im Folgenden werden einige Beispielfälle aufgeführt. Diese entsprechen weitgehend den Beispielen im Beispiele-Ordner.
afl-fuzz -i examples/test-network/in -o ./examples/test-network/out -- \\
./fpicker --fuzzer-mode afl -e attach -p test-network -f ./examples/test-network/harness.js
./fpicker --fuzzer-mode standalone -e attach -p server-process -f harness.js --input-mode cmd \\
--command "./client-send @@" -i indir -o outdir
./fpicker --fuzzer-mode active --communication-mode shm -e attach -p server-process -f harness.js \\
-i indir -o outdir --standalone-mutator cmd --mutator-command "radamsa"
./fpicker --fuzzer-mode passive --communication-mode send -e attach -p server-process -o outdir -f harness.js
./fpicker --fuzzer-mode active -e attach -p test -D remote -o examples/test/out/ -i examples/test/in/ \\
-f fuzzer-agent.js --standalone-mutator cmd --mutator-command "radamsa"
Jedes Ziel erfordert eine eigene Fuzzing-Harness. Der wichtigste Teil dieser Harness ist die Definition der Einstiegsfunktion von Frida's Stalker, die effektiv bestimmt, an welchem Punkt die Instrumentierung eingefügt wird. Im in-process-Modus ist dies einfach. Die Funktion wäre normalerweise diejenige, die bei jeder Fuzzing-Iteration aufgerufen wird. Es könnte jedoch auch eine andere sein.
Eine minimalistische Harness-Implementierung (im command-Modus) könnte wie folgt aussehen:
// Import the fuzzer base class
const Fuzzer = require("harness/fuzzer.js");
// The custom fuzzer needs to subclass the Fuzzer class to work properly
class TestFuzzer extends Fuzzer.Fuzzer {
constructor() {
// The constructor needs to specify the address of the targeted function and a NativeFunction
// object that can later be called by the fuzzer.
const FUZZ_FUNCTION_ADDR = Module.getExportByName(null, "FUZZ_FUNCTION");
const FUZZ_FUNCTION = new NativeFunction(
FUZZ_FUNCTION_ADDR,
"void", ["pointer", "int64"], {
});
super("test", FUZZ_FUNCTION_ADDR, FUZZ_FUNCTION);
}
}
const f = new TestFuzzer();
exports.fuzzer = f;
Diese Harness konfiguriert die Instrumentierung, um der Funktion FUZZ_FUNCTION zu folgen. Die Instrumentierung beginnt, wenn diese Funktion betreten wird, und endet, wenn die Funktion zurückkehrt. Diese Funktion sollte sorgfältig ausgewählt werden, da sie teuer ist und je mehr (potenziell unwichtige) Teile des Prozesses instrumentiert werden, desto langsamer wird der Fuzzer. Natürlich ist dies eine Abwägung zwischen Geschwindigkeit und angestrebter Coverage. Darüber hinaus unterstützt der Fuzzer derzeit nur Funktionen, die während einer Fuzzing-Iteration nur einmal betreten werden, d.h., die Funktion sollte während eines Fuzz-Falls nicht mehr als einmal aufgerufen werden, da sonst die Coverage-Informationen unzuverlässig werden könnten.
Wenn der in-process-Modus verwendet wird, ist eine weitere Funktion im Fuzzer-Skript erforderlich. Die fuzz-Methode. Sie wird bei jeder Iteration aufgerufen. Sie wird mit zwei Parametern aufgerufen: einem Zeiger auf einen Puffer und der Länge des Puffers. Unsere beispielhafte Zielfunktion nimmt zwei Parameter entgegen: einen Zeiger auf einen Puffer und seine Länge. Daher können wir einfach die Parameter übergeben, die wir in der fuzz-Methode erhalten.
fuzz(payload, len) {
this.target_function(payload, parseInt(len));
}
Im passive-Modus muss ein Callback angegeben werden, der die erforderlichen Daten verarbeitet. Der Fuzzer erwartet, einen Payload-Puffer und dessen Länge zu erhalten. Abhängig von der zu fuzzenden Zielfunktion müssen diese Daten extrahiert werden. Im folgenden Beispiel haben wir wieder eine Funktion mit zwei Parametern: einem Zeiger auf einen Puffer und dessen Länge. Der Parameter args enthält alle potenziellen Parameter, die die Zielfunktion erhält, sodass auf den Längenparameter (in unserem Fall der zweite) mit args[1] zugegriffen werden kann. Anschließend lesen wir den Puffer als Uint8Array und senden ihn mit der Methode sendPassiveCorpus zurück an den Fuzzer.
passiveCallback(args) {
const len = args[1];
const data = new Uint8Array(Memory.readByteArray(args[0], parseInt(len)));
// this encodes the data and sends it back to the fuzzer
this.sendPassiveCorpus(data, len);
}
Für den Fall, dass das Ziel eine Art Vorbereitung benötigt, bevor der Fuzzer starten kann, bietet fpicker eine prepare-Methode, die während der Initialisierung des Fuzzers aufgerufen wird. Die Vorbereitung könnte das Herstellen eines Zustands sein, z.B. durch Instanziieren eines Objekts. Eine solche Vorbereitungsfunktion könnte wie folgt aussehen:
prepare() {
// the object can be attached to the fuzzer instance so that it can be used within the
// fuzz() method later on.
this.required_object = call_native_function_that_creates_object();
}
pficker bietet eine große Auswahl an Modi und Konfigurationen, die im Folgenden erläutert werden. Die meisten dieser Modi können auf verschiedene Weise kombiniert werden. Am Ende dieses Abschnitts befindet sich eine Tabelle, die zeigt, welche Optionen kombiniert werden können und welchen Implementierungsstatus sie haben.
Fpicker hat drei verschiedene Fuzzing-Modi: AFL++-Modus, Standalone-Active-Modus und Standalone-Passive-Modus:
AFL++-Modus: Im AFL++-Modus fungiert fpicker als Proxy zwischen AFL++ und dem Zielprozess. Unter Verwendung der Instrumentierungsfähigkeiten von Frida wird das Coverage-Bitmap von AFL++ gefüllt, während das Ziel mit von AFL++ generierten Eingabedaten gefuzzt wird.
Standalone-Active-Modus: Im Standalone-Active-Modus nutzt der Fuzzer Frida's Stalker-Call-Summaries, um Coverage in Form von Basisblöcken zu sammeln, die während einer Iteration ausgeführt werden. Dies ist nichts Neues und wurde bereits in verschiedenen Formen implementiert. In Kombination mit einigen anderen Fuzzer-Einstellungen kann dies jedoch verschiedene Vorteile bieten. Es ist auch eine gute Alternative, wenn AFL++ in einer bestimmten Umgebung oder einem bestimmten Fall nicht anwendbar oder erwünscht ist.
Standalone-Passive-Modus: Der Passive-Modus ist weniger ein Fuzzer als vielmehr ein Tracer. Im Wesentlichen macht er dasselbe wie der Standalone-Active-Modus. Er sendet jedoch keine eigenen Eingaben. Er hängt sich lediglich an eine bestimmte Funktion an und sammelt Coverage. Sobald neue Coverage beobachtet wird, werden sowohl die Coverage als auch die Eingabe gespeichert.
Während fpicker hauptsächlich als In-Process-Fuzzer konzipiert ist, unterstützt es auch Fuzzing über einen externen Befehl. Dafür bietet fpicker zwei Eingabemodi an.
Eingabemodus In-Process: Im In-Process-Eingabemodus ruft die Harness direkt eine angegebene Funktion im Zielprozess auf. Der Fuzzer sendet den Payload an die Harness und die Harness bereitet den Payload so auf, dass sie die Zielfunktion aufrufen kann.
Eingabemodus CMD: Im Befehlseingabemodus wird der Payload an einen externen Befehl umgeleitet. Dies ist nützlich, wenn es zu komplex ist, die Parameter oder andere Zustände beim direkten Aufruf der Zielfunktion vorzubereiten. Die Coverage-Erfassung muss dennoch an eine bestimmte Funktion angehängt werden. Vielleicht gibt es einen Client, der mit einem Payload versorgt werden kann, der dann die Zielfunktion auslöst.
Der Kommunikationsmodus bestimmt, wie die injizierte Harness mit dem Fuzzer kommuniziert. Dies hängt weitgehend von der Zielanwendung ab. Frida bietet eine API zum Senden und Empfangen von Nachrichten vom injizierten Agentenskript. Diese Art der Kommunikation ist recht teuer. Einer der Faktoren ist, dass die übertragene Nachricht in JSON kodiert werden muss. Das Senden von Binärdaten hingegen ist einfach. Daher bietet fpicker einen zweiten Kommunikationsmodus über gemeinsamen Speicher. Dies funktioniert jedoch nur, wenn gemeinsamer Speicher zwischen dem Fuzzer und der Zielanwendung eingerichtet werden kann, was bedeutet, dass dieser Modus nicht verwendet werden kann, wenn das Ziel per USB mit dem Fuzzer-Host verbunden ist. Im CMD-Eingabemodus bezieht sich der Kommunikationsmodus nur darauf, wie die Coverage-Informationen an den Fuzzer zurückgemeldet werden, nicht darauf, wie der Payload gesendet wird, da dies an einen externen Befehl delegiert wird.
Kommunikationsmodus Send: Im Send-Kommunikationsmodus wird der Payload unter Verwendung von Frida's RPC-Aufrufmechanismus gesendet. Dadurch kann der Fuzzer eine JavaScript-Funktion innerhalb des injizierten Harness-Skripts ausführen. Diese Funktion innerhalb der Harness kann dann alle notwendigen Vorbereitungen treffen, um die Zielfunktion aufzurufen. Sobald die Zielfunktion zurückkehrt, wird die Coverage-Erfassung gestoppt und die Harness kann dem Fuzzer signalisieren, dass die Iteration abgeschlossen ist. Dies geschieht, indem die Coverage-Informationen mit Frida's Send-API an den Fuzzer zurückgesendet werden.
Kommunikationsmodus SHM: Im SHM-Kommunikationsmodus kommunizieren der Fuzzer und das Harness-Skript über gemeinsamen Speicher und Semaphore. Ein Puffer im gemeinsamen Speicher wird verwendet, um den Payload zu senden und die Coverage-Informationen zu empfangen. Anstatt zu senden und zu empfangen, warten die beiden Komponenten auf das Semaphor und geben es frei. Abhängig vom System und Ziel führt dies zu erheblichen Leistungssteigerungen. Insbesondere weil der binäre Payload einmal in den Speicher geschrieben wird und nicht kodiert, dekodiert oder in andere Speicherbereiche kopiert werden muss. Leider führt dieser Modus manchmal zu einer geringen Stabilität beim Ausführen mit AFL++. Ich bin mir noch nicht sicher, warum.
Der Ausführungsmodus kann entweder spawn oder attach sein. Dies ist ziemlich selbsterklärend. fpicker kann entweder an einen laufenden Prozess anhängen oder einen Prozess starten. Ein wesentlicher Unterschied zwischen den beiden Modi ist, dass fpicker im Falle eines Absturzes des angehängten Ziels nicht versucht, es neu zu starten.
Im Standalone-Modus bietet fpicker drei verschiedene Eingabemutationsstrategien. Um es nett zu sagen, die Eingabemutation hat sicherlich noch viel Raum für Verbesserungen.
Standalone-Mutator NULL: Dieser Mutator mutiert den Payload nicht und gibt einfach eine Kopie desselben Payloads zurück. Hauptsächlich zu Testzwecken. Ansonsten nicht wirklich nützlich.
Standalone-Mutator Rand: Ein sehr schlechter Zufallsmutator. Er ersetzt lediglich Werte an zufälligen Stellen im ursprünglichen Payload. Er ändert die Payload-Länge nicht.
Standalone-Mutator Custom: Dieser Mutator kann einen externen Befehl aufrufen, um Payloads zu mutieren. Er schreibt den Payload nach stdin und erhält den mutierten Payload von stdout. Aufgrund seiner flachen Implementierung hat er erhebliche Leistungseinbußen.
Mit der Geräteoption -D usb wählt Frida das erste lokale USB-Gerät aus, z.B. ein iPhone oder Android-Telefon.
Mit der Option -D remote ist es möglich, einen Prozess zu fuzzen, der auf einem Netzwerkgerät läuft. Dazu muss auf dem entfernten Gerät frida-server ausgeführt werden. Als Beispielkonfiguration verwenden Sie SSH mit Portweiterleitung, um den standardmäßigen Listening-Port 27042 von frida-server auf dem entfernten Gerät an einen Socket auf dem lokalen Client zu binden.
ssh -N [email protected] -L 127.0.0.1:27042:127.0.0.1:27042
Auf einem iPhone kann man auch iproxy verwenden, um den Port von einer USB-Verbindung weiterzuleiten. Dies kann besonders nützlich sein, wenn Frida auf einem nicht-standard Port auf einem nicht-gejailbreakten Gerät mit dem Frida-Gadget ausgeführt wird. Bei der Arbeit mit dem Frida-Gadget hat der einzige verfügbare Prozess den Namen Gadget, unabhängig vom Namen der Ziel-App.
iproxy 27042 27042
Verwenden Sie dann frida-ps, um die Konfiguration zu validieren, indem Sie die Prozesse auf dem entfernten Gerät auflisten:
frida-ps -R