CVE-2020-0022

Un grande ringraziamento a Insinuator per il loro fantastico post sul blog e codice!

Risultati

Tutti i passaggi menzionati nel post di Insinuator sono stati completati, e anche di più. Sono molti passaggi da inserire in un file README.md, quindi sentiti libero di consultare il post di Insinuator menzionato sopra.

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

1. Viene divulgato l'indirizzo di un'area di memoria sufficientemente grande e controllata dall'attaccante
2. Il program counter viene modificato per puntare a un indirizzo personalizzato
3. Vengono effettuati nuovi tentativi automaticamente fino al punto in cui le probabilità di fallimento diminuiscono in modo significativo
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 piuttosto che in python (perché amo il C)
2. È scritto in modo modulare, dove ogni modulo è responsabile di un compito specifico
3. È stato testato su un Pixel 3 XL con Android 9 (PQ3A.190801.002, Security Patch Level 2019-08-01) perché è quello che avevo in giro
4. Divulga indirizzi in libandroid_runtime.so piuttosto che in libicuuc.so, perché su questo telefono/bersaglio funzionava meglio
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 bersagli)

Demo/Screenshot

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

La prima iterazione della catena è quella che si può vedere in jop_experiment. Questa catena chiama execv direttamente senza chiamare fork. Può essere trovata nel commit ca28fdf. Questo è ciò che accade quando si usa 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 quando si usa questa catena:

Fortunatamente, Pixel 3 XL ha protezioni che impediscono al processo bluetooth di chiamare fork e/o execv. In termini di condivisione di conoscenza o di esibizionismo, il mio lavoro qui è finito. 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 bersagli
• Testare gli exploit su più bersagli per puntare a una relativa universalità
• Combinare l'exploit con un exploit a livello di sistema operativo per ottenere privilegi di root (come il mio precedente exploit per CVE-2019-2215)
• E altro...

Tutte queste cose trasformano questo progetto da un divertente progetto di condivisione di conoscenza a un exploit black-hat che può essere armato, quindi è qui che il mio viaggio finisce, per ora.... Se avete domande, non esitate a 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 bersaglio/vittima. Oltre a make clean, il resto degli obiettivi di build è utile solo se stai cercando di modificare, migliorare o reimplementare l'exploit, quindi non c'è bisogno di menzionarli in dettaglio.

Debugging

• Il binario android gdbserver si trova nella cartella NDK
• Usalo per fare debug del bersaglio (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 dell'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:

• L'SSP viene disattivato (quando si crea un fd di socket HCI) per prevenire un timeout sul bersaglio remoto:

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

• Questo non era ben spiegato nel post di Insinuator. Stiamo divulgando 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 di partial_packets. Questo è stato capito usando map_experiment map_experiment non corrisponde a ciò che viene divulgato nel programma reale, quindi ho semplicemente seguito lo schema di Insinuator e ho usato un altro schema (che ho anche trovato per esperimentazione).

• 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 (la prima, solo execv) è spiegata nel JOP_PLAN.md