Sfruttamento del firmware Android: firmware non firmato nel SoC CVE-2020-10831 di Samsung

TL; DR  

Spiegheremo come abbiamo sfruttato il firmware Android utilizzando un'API del kernel non documentata che è stata trovata mediante il reverse engineering dell'app "Hidden Factory Settings" di Samsung.
Questa API consente il flashing del firmware non firmato del firmware del touchscreen di Samsung.
Il CVE interessa tutte le serie Samsung S7-S10 che utilizzano il chipset Exynos.

Ispirazione  

Dopo aver letto i progetti zero grande articolo sullo sfruttamento del firmware WiFi per ottenere RCE, ho deciso che avrei dovuto provare a fare qualche esplorazione del firmware per conto mio. 

Panoramica generale del SoC  

I telefoni in questi giorni hanno molto più di una sola CPU che esegue il sistema operativo Android, il che li rende sistemi estremamente complessi. 

La maggior parte dei telefoni Android ha 10-30 diversi "computer" al loro interno, ciascuno con la propria CPU, memoria e spazio di archiviazione. 

Tutte queste unità comunicano su diversi protocolli di comunicazione hardware come IPC, I2C e così via. 

Le principali unità di elaborazione nei telefoni Android sono:

AP / Processore dell'applicazione – Questa è la CPU principale che conosci dalle specifiche del telefono che comunica e gestisce tutte le altre unità di elaborazione ed esegue il sistema operativo Android. 

BP / Processore in banda base / Radio / Modem – Il BP è responsabile della conversione di tutti i dati cellulari ricevuti dalle onde radio in informazioni utilizzabili dal software implementando lo stack LTE. 

GPU - L'unità di elaborazione grafica è responsabile della gestione di tutte le attività relative alla grafica

Ci sono più unità di elaborazione come wifi, Crypto, Camera, Audio ecc... 

Tutti questi componenti insieme chiamati “System on Chip” – SoC

Trovare un bersaglio vulnerabile 

Lo sfruttamento del firmware Android è difficile poiché abbiamo pochissime conoscenze preliminari sull'architettura del firmware e su come il sistema operativo comunica con esso. 

Pertanto, l'utilizzo di informazioni fornite dal produttore può rendere la ricerca estremamente più semplice. 

Dopo aver cercato su Google i lead menzionati, molti forum hanno menzionato il problema del touchscreen di Samsung e come risolverlo. 
Il metodo era relativamente semplice:

"Prima vai nelle impostazioni nascoste scrivendo *#2663# nell'app del telefono e poi clicca su aggiorna FW".

Trovare come comunicare con il firmware

Come accennato in precedenza, utilizzare le conoscenze del produttore sarebbe molto più semplice che capire tutto da soli. 

Eseguendo strace sull'applicazione Android, che è responsabile dell'aggiornamento del firmware, puoi facilmente vedere che dopo aver fatto clic sul pulsante di aggiornamento l'app scrive nel seguente percorso

"/sys/classe/sec/tsp/cmd"

Questo percorso fa parte del meccanismo sysfs del kernel. 

sysfs è uno pseudo file system fornito dal kernel Linux che esporta informazioni sui driver di dispositivo associati. 

Qui possiamo vedere come comunicare con il kernel dal file cmd:

Scrivendo il nome della funzione, ad esempio "fw_update" e quindi il parametro "1", si otterrà un aggiornamento del firmware del touch screen come utilizzato nell'app ufficiale delle impostazioni di fabbrica. 
Ma per comprendere appieno la funzionalità dei meccanismi di aggiornamento del firmware è necessario scaricare il kernel e guarda il codice del driver del dispositivo. 
Dopo aver esaminato il codice sorgente del kernel che gestisce il comando precedente, il seguente commento ha svelato funzionalità molto interessanti. 

Apparentemente, quando scrivi:

"echo -n "aggiornamento_firmware:0" > /sys/class/sec/tsp/cmd"

Il parametro 0 informa il kernel da quale posizione aggiornare il firmware.

Come mostra il commento del codice del kernel, il passaggio di 2 farà sì che il kernel aggiorni il firmware da UMS (sdcard). 
Un'ulteriore ricerca nel sorgente del kernel mostrerà il percorso richiesto:

Processo di sfruttamento 

Per verificare se possiamo eseguire il flashing del firmware non firmato/malformato, tutto ciò che dobbiamo fare è provare e vedere cosa succede.

(In generale è meglio modificare solo stringhe leggibili dall'uomo, come un messaggio di registro, per non interrompere il processo di esecuzione del programma, purtroppo ho scelto il modo più stupido)

Il comando

Il risultato stampato nel log del kernel (kmsg)

In questa parte della ricerca non ero sicuro al 100% che funzionasse, ma dopo aver provato a fare clic sul mio dispositivo personale e aver visto tonnellate di errori IO nel kmsg (invece di fare solo clic), ho capito che ho appena eseguito correttamente il flashing del firmware del touchscreen malformato , vaala! 

Nota interessante sul fuzzing 

Quando ho trovato l'API del file cmd, il mio primo pensiero è stato "confondiamolo e troviamo alcuni overflow!"

Ma il registro dice chiaramente che l'input è troppo lungo ed è stato eliminato per evitare overflow. 

Questa patch è dovuta a vulnerabilità trovato dallo stesso ricercatore dell'articolo del progetto zero che mi ha ispirato a fare la ricerca.