CVE-2020-0022

Vielen Dank an Insinuator für ihren fantastischen Blogbeitrag und Code!

Ergebnisse

Alle im Insinuator-Beitrag genannten Schritte wurden abgeschlossen, und weitere sind hinzugekommen. Da dies sehr viele Schritte für eine README.md-Datei sind, wirf gerne einen Blick auf den Beitrag von Insinuator, der oben erwähnt wurde.

Der Exploit ist vollständig bis zu dem Punkt, an dem:

1. Die vom Angreifer kontrollierte, ausreichend große Speicheradresse geleakt wird
2. Der Programmzähler so modifiziert wird, dass er auf eine benutzerdefinierte Adresse zeigt
3. Automatisch Wiederholungen durchgeführt werden, bis die Fehlerwahrscheinlichkeit deutlich sinkt
4. Der Code hinsichtlich Verbindungsabbruchzeit und Speicher-Suchgeschwindigkeit bis zu dem Punkt optimiert ist, an dem weitere Optimierungen die Stabilität des Exploits gefährden würden

Unterschiede und Verbesserungen

Dieser Exploit unterscheidet sich in folgenden Punkten von der Insinuator-Implementierung:

1. Er ist in C geschrieben statt in Python (weil ich C liebe)
2. Er ist modular aufgebaut, wobei jedes Modul für eine bestimmte Aufgabe verantwortlich ist
3. Er wurde auf einem Pixel 3 XL mit Android 9 (PQ3A.190801.002, Sicherheitspatch-Level 2019-08-01) getestet, weil ich genau dieses Gerät zur Verfügung hatte
4. Er leakt Adressen aus libandroid_runtime.so statt aus libicuuc.so, weil das auf diesem Telefon/Ziel besser funktionierte
5. Es sind zwei Beispiel-JOP-Ketten implementiert, eine, die direkt execv aufruft, und eine, die zuerst fork und dann execv aufruft
6. Er wird von einem benutzerdefinierten Ghidra-Skript begleitet, das die Datei libandroid_runtime.so verarbeitet und die Offsets von Funktionen und Gadgets extrahiert (um die Portierung des Exploits auf andere Ziele zu erleichtern)

Demo/Screenshots

Dies ist eine Videodemo, die zeigt, wie der Exploit den PC auf eine benutzerdefinierte Adresse umsetzt:

Die erste Iteration der Kette ist die, die im jop_experiment zu sehen ist. Diese Kette ruft execv direkt auf, ohne fork aufzurufen. Sie ist in Commit ca28fdf zu finden. Dies passiert bei Verwendung dieser Kette:

Die zweite Iteration der Kette ist diejenige, die zuerst fork und dann execv aufruft. Vollständige Details dieser Kette finden sich hier. Dies passiert bei Verwendung dieser Kette:

Zum Glück verfügt das Pixel 3 XL über Schutzmechanismen, die verhindern, dass der Bluetooth-Prozess fork und/oder execv aufrufen kann. Was Wissensaustausch oder das Zeigen von Können betrifft, ist meine Arbeit hier getan. Wenn ich etwas Fortgeschritteneres schreibe und teile, könnte das für Black-Hats zu hilfreich sein.

Fazit zum Exploit

Ich betrachte diesen Exploit als vollständig. Zukünftige Verbesserungen könnten sein:

• Schreiben einer JOP-Kette, die dlsym und dann mprotect aufruft, um eigenen Shellcode auszuführen
• Sammeln und Speichern einer Datenbank mit Offsets für verschiedene Ziele
• Testen des Exploits auf mehreren Zielen, um eine relative Universalität anzustreben
• Verketten des Exploits mit einem Exploit auf OS-Ebene, um Root-Rechte zu erlangen (wie mein früherer CVE-2019-2215-Exploit)
• Und mehr...

All diese Dinge verwandeln dieses Projekt von einem unterhaltsamen Wissensaustausch-Projekt in einen Black-Hat-Exploit, der zur Waffe gemacht werden kann. Daher endet meine Reise hier, vorerst.... Wenn du Fragen hast, melde dich gerne bei mir.

Verwendung

Um den Exploit auszuführen, führe einfach Folgendes aus:

make build run ARGS="00:00:00:00:00:00" 

Wobei 00:00:00:00:00:00 die MAC-Adresse des Ziel-/Opfergeräts ist. Abgesehen von make clean sind die übrigen Build-Ziele nur hilfreich, wenn du versuchst, den Exploit zu modifizieren, zu verbessern oder neu zu implementieren. Es besteht also keine Notwendigkeit, sie im Detail zu erwähnen.

Debugging

• Die Android-gdbserver-Binärdatei befindet sich im NDK-Ordner
• Verwende dies, um das Ziel zu debuggen (nicht empfohlen):

# Auf dem Zielgerät
/data/local/tmp/gdbserver 0.0.0.0:1234 --attach $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}')

# Auf dem Host
adb forward tcp:1234 tcp:1234
gdb-multiarch -q -x ./gdbinit

• Direkt auf dem Telefon über das gdb von Termux (empfohlen):

# Auf dem Host
adb push ./gdbinit /data/local/tmp/gdbinit

# Auf dem Zielgerät
su
/data/data/com.termux/files/usr/bin/gdb -q -x /data/local/tmp/gdbinit -p $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}') 
# ODER
/data/data/com.termux/files/usr/bin/gdb -q -p $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}') 

Du kannst den Bluetooth-Dienst auf dem Angreifer-Rechner neu starten, falls er nicht mehr funktioniert:

sudo systemctl restart bluetooth.service

Hinweise

Dieser Abschnitt erklärt einige der Phänomene, die während der Entwicklung dieses Exploits beobachtet wurden:

• SSP ist deaktiviert (beim Erstellen eines HCI-Socket-fd), um ein Timeout auf dem entfernten Ziel zu verhindern:

• Wir verteilen Heap-Cleaner-Pakete, um die Wahrscheinlichkeit zu verringern, dass das Ziel durch einen unbeabsichtigten Überlauf abstürzt, der die V-Tabellen des über get_message_loop verwendeten base::MessageLoop-Objekts modifiziert:

• Dies wurde im Insinuator-Beitrag nicht gut erklärt. Wir leaken die Adresse eines Pakets, indem wir versuchen, die 32-Byte-malloc-Chunks anzugreifen, die ein Element der verknüpften Liste für jedes Element der partial_packets-unordered_map enthalten. Dies wurde mithilfe des map_experiment herausgefunden Das map_experiment stimmt nicht mit dem überein, was im tatsächlichen Programm geleakt wird. Ich bin daher dem Muster von Insinuator gefolgt und habe ein anderes Muster verwendet (das ich ebenfalls durch Experimentieren gefunden habe).

• Der Absturz, die PC-Überschreibung und der Absturz des Chrome-Signalobjekts sind erfolgreich

• Die JOP-Kette wurde mithilfe des jop_experiment simuliert. Die vollständige (erste, nur-execv) JOP-Kette wird in der JOP_PLAN.md erklärt