CVE-2020-0022

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

Ergebnisse

Alle im Insinuator-Beitrag erwähnten Schritte wurden abgeschlossen und noch mehr. Es sind viele Schritte, um sie in eine README.md-Datei zu packen, also schauen Sie sich gerne den Beitrag von Insinuator oben an.

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

1. Die Adresse des ausreichend großen, vom Angreifer kontrollierten Speicherbereichs preisgegeben wird
2. Der Programmzähler wird geändert, um auf eine benutzerdefinierte Adresse zu zeigen
3. Automatisch werden Wiederholungen durchgeführt, bis die Fehlerwahrscheinlichkeit deutlich sinkt
4. Der Code wird hinsichtlich Trennungszeit und Speichersuchgeschwindigkeit optimiert, bis weitere Optimierungen die Stabilität des Exploits beeinträchtigen würden

Unterschiede und Verbesserungen

Dieser Exploit unterscheidet sich in folgenden Punkten von Insinuators Implementierung:

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

Demo/Screenshots

Dies ist eine Video-Demo, die zeigt, wie der Exploit den PC ändert, um auf eine benutzerdefinierte Adresse zu zeigen:

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

Die zweite Iteration der Kette ruft fork und dann execv auf. Vollständige Details dieser Kette finden Sie hier. Dies geschieht bei Verwendung dieser Kette:

Glücklicherweise verfügt das Pixel 3 XL über Schutzmechanismen, die verhindern, dass der Bluetooth-Prozess fork und/oder execv aufruft. Was Wissensaustausch oder Vorführung betrifft, ist meine Arbeit hier abgeschlossen. Wenn ich etwas Fortgeschritteneres schreibe und teile, könnte es für Black-Hats zu hilfreich sein.

Schlussfolgerung des Exploits

Ich betrachte diesen Exploit als abgeschlossen. Mögliche zukünftige Verbesserungen sind:

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

All diese Dinge verwandeln dieses Projekt von einem unterhaltsamen Wissensaustausch-Projekt in einen Black-Hat-Exploit, der bewaffnet werden kann, also endet meine Reise hier, vorerst.... Wenn Sie Fragen haben, kontaktieren Sie mich gerne.

Verwendung

Um den Exploit auszuführen, führen Sie einfach 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 restlichen Build-Ziele nur hilfreich, wenn Sie versuchen, den Exploit zu modifizieren, zu verbessern oder neu zu implementieren, daher ist es nicht nötig, sie im Detail zu erwähnen.

Debugging

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

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

# On host
adb forward tcp:1234 tcp:1234
gdb-multiarch -q -x ./gdbinit

• Direkt auf dem Telefon über termux's gdb (empfohlen):

# On host
adb push ./gdbinit /data/local/tmp/gdbinit

# On target
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}') 
# OR
/data/data/com.termux/files/usr/bin/gdb -q -p $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}') 

Sie können den Bluetooth-Dienst auf dem Angreiferrechner 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 einen Timeout auf dem entfernten Ziel zu verhindern:

• Wir streuen Heap-Cleaner-Pakete, um die Wahrscheinlichkeit eines Absturzes des Ziels aufgrund eines unbeabsichtigten Überlaufs zu verringern, der die Vtable des über get_message_loop verwendeten base::MessageLoop-Objekts modifiziert:

• Dies wurde im Insinuator-Beitrag nicht gut erklärt. Wir geben die Adresse eines Pakets preis, indem wir versuchen, die 32-Byte-Malloc-Chunks anzugreifen, die ein LinkedList-Element für jedes Element in der partial_packets unordered_map enthalten. Dies wurde mit dem map_experiment herausgefunden Das map_experiment stimmt nicht mit dem überein, was im eigentlichen Programm preisgegeben wird, also bin ich einfach dem Muster von Insinuator gefolgt und habe ein anderes Muster verwendet (das ich auch durch Experimentieren gefunden habe).

• Der Absturz und die PC-Überschreibung stürzt das Chrome-Signalobjekt erfolgreich ab

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