Hacker's Cookbook: Sfruttare gli elettrodomestici IoT con WHIDBOARD

AFFAMATO DI HACKERAGGIO HARDWARE

Recentemente ho completato la ricerca e lo sviluppo di un nuovo dispositivo chiamato WHIDBOARD e, per testarlo, ho deciso di esaminare un elettrodomestico IoT acquistato ricondizionato su Amazon. Il risultato è stato inaspettatamente esilarante!

L'obiettivo

Il DUT (Dispositivo Under Test) di questo post sul blog è un elettrodomestico da cucina intelligente chiamato Mambo Touch della società spagnola Cecotec.

Questo dispositivo di cottura all-in-one è un robot da cucina multifunzionale con 37 funzioni, dotato di un touch screen da 5 pollici e controllabile a distanza tramite la sua app mobile (come si può vedere dalle immagini qui sotto), che si collega tramite una rete WiFi.

Dato che quello ricondizionato era più economico... e che comunque non lo userò mai per cucinare... l'ho acquistato immediatamente!

Ricondizionato ≠ Ripristino delle impostazioni di fabbrica

Di solito Amazon consente ai clienti di restituire alcuni articoli che non gradiscono o che non soddisfano le loro aspettative...

Tuttavia, sorge una domanda legittima... dove finiscono questi articoli? Come vengono ricondizionati? E il ripristino delle impostazioni di fabbrica PRIMA della rivendita?

Dopo averlo acceso, mi sono connesso alla mia rete WiFi e ho provato ad accoppiarlo con l'app mobile... ma è accaduta una cosa curiosa. Il dispositivo in esame era già accoppiato con un altro proprietario (probabilmente il precedente)...

Mi chiedo cosa direbbe un DPO al riguardo...

Smontaggio del DUT

Da un'ispezione iniziale dell'esterno, è possibile notare un primo indizio... una porta micro USB nascosta.

Tuttavia, una volta collegato al computer, non accade nulla di particolarmente interessante... Il passo successivo è stato quello di aprire il dispositivo... e tra tutti gli altri componenti (touch screen, interruttori, sensori, motori, alimentatore, ecc...) sono stato accolto dalla scheda madre.

Qui possiamo facilmente individuare i componenti principali:

• SoC Amlogic A213Y
• KLM8G1GETF-B041 è una memoria flash eMMC da 8 GB con un ingombro FBGA-153
• RS256M16V0DB-107AT DDR SDRAM con impronta FBGA-96

Inoltre, sono presenti alcuni punti di accesso interessanti per le interfacce di debug...

Tuttavia, il punto di accesso più interessante era dall'altra parte... alcuni pad di test etichettati con la consueta piedinatura dell'interfaccia di debug UART... (ovvero GND, RX, TX).

Il passo successivo era semplice... saldare un paio di fili su quei pad, prendere la mia WHIDBOARD e verificare con Logic Analyzer e Pin Enumerator se si trattava davvero di un'interfaccia di debug UART...

Per prima cosa, ho collegato tutti i fili al blocco terminale del Logic Analyzer della WHIDBOARD per intercettare alcuni dati... ed ecco cosa ho ottenuto su Pulseview:

Ottenere il root tramite UART

Ottimo! Abbiamo facilmente confermato che i 3 pad di prova sul retro del PCB sono effettivamente una console UART funzionante. Possiamo vedere il DUT che emette la sequenza di avvio dal Logic Analyzer. Successivamente, proviamo a collegarci direttamente con WHIDBOARD e il Pin Enumerator.

La funzione Pin Enumerator di WHIDBOARD si basa sul JTAGulator (purtroppo fuori produzione) realizzato da Joe Grand. Consente di individuare i pin delle interfacce di debug come UART, JTAG e SWD. Tuttavia, nel mio caso ho utilizzato principalmente la sua funzione Passthrough per comunicare con il target collegato al suo blocco terminale (e ovviamente confermare la corretta combinazione di pin UART).

Una volta confermato con il Pin Enumerator che mi trovavo effettivamente di fronte a una porta di debug UART, ho utilizzato la funzione Passthrough e sono stato accolto da una console terminale con accesso root.

Qual è il prossimo passo?

A questo punto è evidente che il dispositivo può essere facilmente compromesso. Tuttavia, desideravo continuare a sperimentare e verificare il funzionamento della connessione remota...

Innanzitutto, ho abilitato la connessione remota ADB tramite WiFi con i seguenti comandi:

E ho verificato che tutto funzionasse correttamente:

Ora disponiamo già di una connessione remota (cioè sulla stessa LAN) persistente con il DUT. Poiché il demone del server ADB persisterà anche dopo l'avvio.

Successivamente, è stato necessario effettuare alcune ricognizioni e verificare la presenza di informazioni interessanti... Inizialmente, ho enumerato le app installate per verificare due aspetti: quale versione di Android è in esecuzione e quali sono le app principali del fornitore (ad esempio, Cecotec).

Le due app più interessanti sono:

• package:/data/app/com.zavier.androidrk3326functiontest-1.apk=com.zavier.androidrk3326functiontest
• package:/data/app/com.kitchenidea.cecotec.k2501-2.apk=com.kitchenidea.cecotec.k2501

Tuttavia, prima di continuare a controllare, ho rapidamente eseguito la consueta app Impostazioni Android (con questo comando am start -n com.android.settings/.Settings) per verificare ulteriori informazioni sulla versione del sistema operativo... e, come previsto, il DUT utilizzava una versione precedente di Android: 4.4.2.

Va bene... continuiamo ad approfondire... È il momento di ricognire la rete! Osservando l'output di netstat, posso notare alcune connessioni con indirizzi IP Internet:

Niente di particolarmente interessante, ma una ha attirato la mia attenzione... ovviamente, trattandosi di un backend che non mi appartiene... l'ho considerata fuori dal mio ambito di competenza e sono andato avanti...

Successivamente, ho iniziato a cercare i consueti strumenti degli hacker che possono essere utilizzati per esfiltrare o eseguire il reverse shell degli obiettivi IoT... uno per tutti... Sua Maestà BUSYBOX.

E in realtà questo aveva tutto ciò che serviva:

Solo con questo, potevo estrarre, caricare, manipolare dati e anche ottenere una reverse shell con netcat. Ma andiamo avanti! Dato che abbiamo già una shell ADB persistente... questa volta non c'è bisogno di BusyBox. :P

Nel complesso, con ADB Explorer ho estratto tutti i file interessanti che ho trovato in giro. Tuttavia, nulla di particolarmente interessante... Questo dispositivo non ha né microfono né fotocamera... non possiamo nemmeno spiare le persone da remoto... meh... :(

Analisi delle APK

A questo punto ho spostato la mia attenzione sugli APK del fornitore:

• package:/data/app/com.zavier.androidrk3326functiontest-1.apk=com.zavier.androidrk3326functiontest
• package:/data/app/com.kitchenidea.cecotec.k2501-2.apk=com.kitchenidea.cecotec.k2501

Il com.zavier.androidrk3326functiontest-1.apk sembra una suite di test funzionali per verificare che tutti i sensori e i driver del motore funzionino correttamente. Si consideri che questo elettrodomestico IoT per la cucina dispone di una bilancia integrata, un riscaldatore, un motore per mescolare il cibo e vari sensori. E apparentemente sono tutti controllati da queste due app (anche in remoto dall'utente con il proprio telefono cellulare...).

Per quanto riguarda com.kitchenidea.cecotec.k2501-2.apk , ho notato immediatamente che si tratta di una copia dell'altra update.apk presente in /sdcard/, quindi non è necessario controllare entrambi:

Esaminando il secondo APK non ho riscontrato particolari anomalie, tuttavia ho verificato che l'app ha pieno accesso a tutti i sensori, al riscaldamento, al motore, ecc... in teoria potremmo creare un malware in grado di interferire con la vittima da remoto inviando comandi arbitrari sulle porte seriali... :P

Ho anche ricontrollato se ci fossero altri URL/IP interessanti hardcoded in quelle due app... ma sembra che siano i soliti rifiuti medi:

Dato che ero in ritardo e infastidito, ho eseguito MobSF per ottenere una rapida panoramica del livello di rischio di queste due app...

TL;DR: Niente di grave. Un'app mediocre per un prodotto mediocre. 8)

Nel complesso, è evidente che esiste la possibilità di trasformare questo dispositivo in un'arma con un APK personalizzato che può essere controllato da remoto da un aggressore e manipolare le funzionalità interne al fine di causare danni fisici (ad esempio, bypassare le misure di sicurezza, surriscaldare la pentola, ecc...).

Scherzi e reverse shell

Come ultimo esercizio, prima di concludere e restituire questo dispositivo ad Amazon, desideravo verificare se una reverse shell meterpreter avrebbe funzionato e se attraverso di essa avrei potuto eseguire DOOM o alcuni scherzi a mia moglie. Beh...

Per prima cosa prepariamo un APK meterpreter da inviare con ADB:

Successivamente, inviamolo tramite ADB e installiamolo:

Ora procediamo con l'esecuzione:

Nel frattempo, sulla macchina virtuale WHIDOS era già stato configurato il listener MSF:

Ora, ogni volta che il dispositivo viene riavviato, eseguirà automaticamente la shell inversa e richiamerà il C2 dell'autore dell'attacco:

A questo punto, l'installazione e l'esecuzione di DOOM sono state una questione di secondi...

Conclusione

Il mercato dell'IoT è comunemente noto per essere pieno di dispositivi vulnerabili. Sfortunatamente per il consumatore medio, la maggior parte delle aziende non prende abbastanza sul serio la sicurezza dei prodotti. Nella maggior parte dei casi, un dispositivo IoT compromesso potrebbe non avere un grande impatto sulla vita dei consumatori, ma in alcuni casi potrebbe causare danni fisici. Come in questo caso, in cui il riscaldamento e il motore sono controllati dall'app in remoto e un potenziale aggressore potrebbe controllarli a sua volta.

Inoltre, è evidente che l'acquisto di dispositivi IoT ricondizionati... a volte... potrebbe NON essere una scelta saggia.

E se avessi lasciato qualche payload dannoso prima di restituire il dispositivo ad Amazon? (Disclaimer: no, non l'ho fatto).