peafl64

Instrumentieren einer Usermode-Binärdatei mit NOPs

Instrumentieren einer Kernelmode-Binärdatei mit Prozess-ID-Filterung

Instrumentieren einer Kernelmode-Binärdatei mit Thread-ID-Filterung und ausführlicher Ausgabe

So ersetzen Sie Windows-Treiber

Zuerst müssen Sie prüfen, ob Ihr Rechner per BIOS oder UEFI bootet.
Bei Hyper-V-Maschinen: Gen-1-Maschinen basieren auf BIOS, Gen-2-Maschinen auf UEFI.
Wenn Ihre Maschine auf BIOS basiert, müssen Sie winload.exe patchen:

• Besorgen Sie sich eine Kopie von winload.exe von Ihrer VM und finden Sie die Funktion ImgpValidateImageHash darin
• Patchen Sie den Rückgabewert so, dass in rax immer 0 zurückgegeben wird. Ersetzen Sie zum Beispiel im letzten Codeblock der Funktion mov eax, edi durch xor eax, eax
• Kopieren Sie das gepatchte winload in den system32-Ordner und führen Sie bcdedit /set path \Windows\system32\winload2.exe aus

Wenn Ihre Maschine per UEFI bootet, verwenden Sie das Dienstprogramm EfiGuard, um winload.efi zu patchen.
Befehls-Spickzettel bei Verwendung des Hyper-V-Managers:

1. Erstellen Sie eine neue Festplatte für die virtuelle Maschine
2. Verwenden Sie die mitgelieferte FAT.vhdx im Tools-Ordner (oder erstellen Sie selbst eine), die das UefiShell+EfiGuard-Modul enthält, zusammen mit der neuen Festplatte
3. Ändern Sie die Bootreihenfolge der Maschine, sodass die neue Festplatte zuerst kommt
4. Führen Sie nach dem Booten in der UefiShell die folgenden Befehle aus:

Instrumentieren Sie dann den Treiber Ihrer Wahl. Damit ein instrumentierter Treiber auf einem Windows-Rechner geladen werden kann, muss er signiert sein; ein selbstsigniertes Zertifikat reicht aus, um die Anforderungen des Betriebssystems zu erfüllen:

Wenn der instrumentierte Treiber bereits vom System verwendet wird, verwenden Sie diese Befehle (als Administrator), um die Treiberdatei zu ersetzen:

Führen Sie dann aus:

WinAFL-Fuzzing

Die Integration mit WinAFL erfolgt durch Kompilieren eines Harness mit den mitgelieferten Headern.
Neben den Headern gibt es example.c, ein Beispielprogramm, das deren Verwendung zeigt.
Die mitgelieferten Header sind eine leichte Abwandlung der bereits von WinAFL bereitgestellten Header, um die Integration mit einem anderen statischen Binärinstrumentierungswerkzeug namens Syzygy zu ermöglichen.

kAFL-Fuzzing

Die Art und Weise, wie wir mit kAFL integrieren, ist ziemlich einfach.
Normalerweise läuft ein kAFL-Harness auf einer virtuellen Maschine und kommuniziert über spezielle „Hypercalls“ mit dem Frontend des Fuzzers.
Diese Hypercalls weisen den Fuzzer an, viele Dinge zu tun, unter anderem Coverage-Daten von IntelPT zu laden und als AFL-Bitmap zu parsen.
Da peafl64 das IntelPT-Tracing überflüssig macht, müssen wir eine Möglichkeit vorbereiten, die Coverage-Daten an den Fuzzer zu übertragen.
Daher haben wir qemu und kvm um „Hypercalls“ erweitert, die es dem (Usermode-)Harness, der in einer VM läuft, ermöglichen, die mit dem Hilfstreiber gesammelten Coverage-Daten zu senden.

ESXi-Einrichtung

Dies betrifft speziell die Einrichtung auf ESXi, sollte aber auch für andere Virtualisierungsplattformen wie AWS relevant sein.
Die Einrichtung ist ziemlich einfach:

• Erstellen Sie eine Ubuntu-Maschine
• Stellen Sie sicher, dass die Option „Expose hardware assisted virtualization to the guest OS“ in der CPU-Konfiguration der Maschine aktiviert ist
• Klonen Sie das sbi_kAFL-Repository
• Installieren Sie kAFL normal wie im kAFL-Repository beschrieben, aber führen Sie statt des Schritts install.sh qemu den Befehl install.sh qemu_sbi aus

Um mit kAFL und peafl64 zu fuzzen, müssen wir eine Fuzzing-Maschine einrichten:

• Kompilieren Sie den Hilfstreiber und signieren Sie ihn
• Kompilieren Sie einen Harness mit den Headern, die in unserem kAFL-Fork enthalten sind
• Laden Sie auf der VM den Hilfstreiber
• Führen Sie den kAFL-Loader aus

Abgesehen davon ist das Fuzzing mit unserem kAFL-Fork dasselbe wie normales Fuzzing mit kAFL.

Ausführungsablauf

Schritte im Überblick:

1. Einfügepunkte für den Instrumentierungscode bestimmen
2. Anweisungen und Strukturen finden, die angepasst werden müssen
3. Den Instrumentierungscode in die gewünschten Funktionen einfügen
4. Anpassen:
   • Relative Anweisungen
   • Sprungtabellen
   • Ausnahmehandler
   • PE-Header
   • Verschiedene PE-Konfigurationen (Load-Config)
5. Das PE mit den instrumentierten Sektionen neu aufbauen

Zuerst verwenden wir IDA, um die relevanten Anweisungen und Stellen zu finden und zu analysieren.
Die Analyse erstellt eine Datei dump.json, die all diese Informationen im JSON-Format enthält.
instrument.py enthält die Instrumentierungslogik, und der Ablauf selbst ist in der Funktion process_pe beschrieben.
Um die Binärdatei zu instrumentieren, duplizieren wir ihre ausführbaren Sektionen, in denen sich der gesamte instrumentierte Code befinden wird.
Als Nächstes verarbeiten wir alle relativen Anweisungen und bestimmen, wie und ob wir sie behandeln müssen. Angenommen, wir haben einen kurzen Sprung (short jmp) von Adresse X zu Adresse Y. Wir fügen zwischen X und Y Instrumentierungscode ein, und nun befindet sich das Ziel an Adresse Z (Z = Y + len(instrumentation)).
Das bedeutet, dass wir den Sprung modifizieren müssen. Wenn Adresse Z nun außerhalb des Bereichs kurzer Sprünge liegt, müssen wir den Sprung von short in far umwandeln. (instrument.py:expand_relative_instructions)
Zum Beispiel:

• short jmp 0x57 (eb 55) -> near jmp 0x604 (e9 ff 05 00 00)

Das gilt auch für Anweisungen wie call, loop und bedingte Sprünge.
Ein weiterer häufiger Fall, der behandelt werden muss, sind RIP-relative Anweisungen, die in x64-Assembly eingeführt wurden:

• call [rip+0x1000]

Wir aktualisieren die folgenden Dinge, sodass sie auf den instrumentierten Code verweisen: Relokationstabelle, Exporttabelle, Load-Konfiguration, das TLS-Verzeichnis und Ausnahmedatensätze.
Die Aktualisierungen erfolgen, indem alle Adressen von den ursprünglichen Sektionen auf ihre instrumentierten Gegenstücke umgestellt werden. (instrument.py:update_addr)
Die Header werden aktualisiert, um die Änderungen an der PE-Struktur widerzuspiegeln – hinzugefügte Sektionen, geänderter Einstiegspunkt und PE-Größe. (instrument.py:update_pe_headers)

Darüber hinaus kann peafl64 den Windows-Kernel instrumentieren. Dazu analysiert und aktualisiert es die Dynamic Value Relocation Table (DVRT) und die SSDT und behandelt PatchGuard-Besonderheiten.

Die DVRT ist eine vom Compiler erzeugte Tabelle, die die Positionen von Adressen beschreibt, die beim Laden des PE geändert werden müssen.
Sie wird verwendet, um KASLR zu verbessern, und trägt zur Abschwächung der Spectre-Schwachstelle bei (1, 2, 3).
Die DVRT wird mit einer Reihe von Klassen geparst, die die Struktur der Tabelle nachbilden (drt.py; instrument.py:get_updated_dynamic_relocs)

Das Behandeln und Aktualisieren der SSDT war nicht ganz so einfach.
Ihre Adresse wird nicht exportiert, daher mussten wir uns entweder auf Symbole oder auf Heuristiken verlassen, um sie zu finden.
Unsere Lösung verwendet einen heuristischen Ansatz, der NtWaitForSingleObject als konstanten Marker für alle Windows-10-Versionen nutzt und die Adresse der SSDT relativ dazu findet. (instrument.py:ntoskrnl_update_KiServiceTable)
Dieser Ansatz funktioniert für alle Windows-10-Kernel, muss aber für andere Kernelversionen angepasst werden.

TODO

• x64 unterstützen
• Neue Ausnahmehandler (cxx4)
• Leistung des IDA-Dumpers verbessern
• LOAD_CONFIG-Struktur vollständig parsen
• Tests hinzufügen
• Mehr Windows-Kernelversionen standardmäßig unterstützen
• Mit Nyx (dem neuen kAFL) integrieren