CVE-2020-0022

Molte grazie a Insinuator per il loro fantastico post sul blog e codice!

Risultati

Tutti i passaggi menzionati nel post di Insinuator sono stati completati, e altri ancora. Sono molti passaggi da inserire in un file README.md, quindi sentiti libero di dare un'occhiata al post di Insinuator menzionato sopra.

L'exploit è completamente completo fino al punto in cui:

1. L'indirizzo di un'area di memoria sufficientemente grande controllata dall'attaccante viene trapelato
2. Il program counter viene modificato per puntare a un indirizzo personalizzato
3. Vengono effettuati tentativi automatici fino al punto in cui le probabilità di fallimento diminuiscono significativamente
4. Il codice è ottimizzato in termini di tempo di disconnessione e velocità di ricerca in memoria fino al punto in cui un'ulteriore ottimizzazione compromette la stabilità dell'exploit

Differenze e Miglioramenti

Questo exploit differisce dall'implementazione di Insinuator nei seguenti modi:

1. È scritto in C invece che in Python (perché amo il C)
2. È scritto in modo modulare, dove ogni modulo è responsabile per un compito specifico
3. È stato testato su un Pixel 3 XL con Android 9 (PQ3A.190801.002, Livello di Patch di Sicurezza 2019-08-01) perché era quello che avevo a disposizione
4. Trapela indirizzi in libandroid_runtime.so invece che in libicuuc.so, perché funzionava meglio su questo telefono/target
5. Ha due catene JOP di esempio implementate, una che chiama execv direttamente e una che chiama fork e poi execv
6. È accompagnato da uno script Ghidra personalizzato che elabora il file libandroid_runtime.so ed estrae gli offset di funzioni e gadget (per facilitare il porting dell'exploit su altri target)

Demo/Screenshot

Questo è un video demo che mostra l'exploit che modifica il PC per puntare a un indirizzo personalizzato:

La prima iterazione della catena è quella che può essere vista in jop_experiment. Questa catena chiama execv direttamente senza chiamare fork. Può essere trovata nel commit ca28fdf Questo è ciò che accade usando questa catena:

La seconda iterazione della catena è quella che chiama fork e poi execv. I dettagli completi di questa catena si trovano qui. Questo è ciò che accade usando questa catena:

Fortunatamente, Pixel 3 XL ha protezioni che impediscono al processo bluetooth di chiamare fork e/o execv. In termini di condivisione della conoscenza o di esibizione, il mio lavoro qui è fatto. Se scrivessi e condividessi qualcosa di più avanzato, potrebbe essere troppo utile per i black-hat.

Conclusione dell'Exploit

Considero questo exploit completo. Miglioramenti futuri potrebbero essere:

• Scrivere una catena JOP per chiamare dlsym e poi mprotect per eseguire shellcode personalizzato
• Raccogliere e salvare un database di offset per diversi target
• Testare gli exploit su più target per puntare a una universalità relativa
• Concatenare l'exploit con un exploit a livello di sistema operativo per ottenere privilegi di root (come il mio precedente exploit CVE-2019-2215)
• E altro ancora...

Tutte queste cose trasformano questo progetto da un divertente progetto di condivisione della conoscenza in un exploit black-hat che può essere armato, quindi è qui che il mio viaggio finisce, per ora.... Se hai domande, sentiti libero di contattarmi.

Utilizzo

Per eseguire l'exploit, basta eseguire:

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

Dove 00:00:00:00:00:00 è l'indirizzo MAC del dispositivo target/vittima. Oltre a make clean, gli altri target di build sono utili solo se stai cercando di modificare, migliorare o reimplementare l'exploit, quindi non c'è bisogno di menzionarli in dettaglio.

Debug

• Il binario android gdbserver si trova nella cartella NDK
• Usalo per eseguire il debug del target (non consigliato):

# 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

• Direttamente sul telefono tramite gdb di termux (consigliato):

# 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}') 

Puoi riavviare il servizio bluetooth sulla macchina attaccante nel caso smetta di funzionare:

sudo systemctl restart bluetooth.service

Note

Questa sezione spiega alcuni dei fenomeni osservati durante lo sviluppo di questo exploit:

• SSP è disattivato (quando si crea un fd socket HCI) per prevenire un timeout sul target remoto:

• Stiamo spruzzando pacchetti heap cleaner per ridurre la probabilità che il target vada in crash a causa di un overflow involontario che modifica le vtable dell'oggetto base::MessageLoop usato tramite get_message_loop:

• Questo non è stato ben spiegato nel post di Insinuator. Stiamo trapelando l'indirizzo di un pacchetto cercando di colpire i chunk malloc da 32 byte, che includono un elemento di lista collegata per ogni elemento nella unordered_map partial_packets. Questo è stato scoperto usando map_experiment Il map_experiment non corrisponde a ciò che viene trapelato nel programma reale, quindi ho semplicemente seguito lo schema di Insinuator e ne ho usato un altro (che ho anche trovato per sperimentazione).

• Il crash e la sovrascrittura del PC mandano in crash con successo l'oggetto segnale di chrome

• La catena JOP è stata simulata usando jop_experiment. La catena JOP completa (prima, solo execv) è spiegata in JOP_PLAN.md