Penetration test IoT: cosa attacchiamo e cosa troviamo
Cosa copre un pentest IoT, da porte di debug e firmware a radio, app e cloud, quali vulnerabilità emergono più spesso e come preparare il dispositivo al test.
Zyberum Security Team · Pubblicato il · 7 min di lettura
Un prodotto IoT non è mai soltanto un dispositivo. È hardware, firmware, un collegamento radio, un’app e un servizio cloud, e a un attaccante basta che uno solo di questi sia debole. Un penetration test IoT li esamina tutti insieme, perché gli attacchi interessanti di solito attraversano i confini tra l’uno e l’altro.
Ecco che cosa facciamo davvero in un test di questo tipo e che cosa continuiamo a trovare.
I cinque livelli che attacchiamo
1. Hardware
Per prima cosa apriamo il dispositivo. Sulla scheda cerchiamo interfacce di debug (UART, JTAG, SWD), test point e il chip flash. Una console seriale che porta direttamente a una shell di root resta uno dei risultati più frequenti sul campo.
Se la porta di debug è bloccata, proviamo a ottenere il firmware per un’altra via: leggendo direttamente il chip flash oppure inducendo con il glitching il processore a saltare un controllo.
2. Firmware
Una volta estratto il firmware, lo spacchettiamo e lo leggiamo. Le domande tipiche:
- Ci sono password, chiavi API o chiavi private hard-coded?
- Quali componenti open source contiene, e quanto sono vecchi?
- Esiste una catena di secure boot, e ogni stadio verifica davvero il successivo?
- Come vengono verificati gli aggiornamenti? Firmati, o soltanto confrontati con un checksum?
3. Radio e interfacce locali
Bluetooth LE, Wi-Fi, Zigbee, Thread, LoRaWAN o un collegamento proprietario sub-GHz: catturiamo il traffico, lo ritrasmettiamo e lo modifichiamo. Il pairing è un bersaglio privilegiato, perché molti dispositivi accettano chiunque lo chieda al momento giusto.
4. App
L’app associata spesso sa più di quanto dovrebbe. La decompiliamo, cerchiamo segreti e osserviamo come comunica con il dispositivo e con il cloud.
5. Cloud e API
Qui verifichiamo se un cliente può raggiungere i dispositivi di un altro cliente. Il controllo degli accessi difettoso sugli ID dei dispositivi è il grande classico: cambiate un numero in una richiesta e controllate il prodotto di qualcun altro.
Che cosa troviamo più spesso
| Risultato | Perché è importante |
|---|---|
| Console di debug aperta (UART/JTAG) | Controllo completo con accesso fisico e una via rapida al firmware |
| Credenziali o chiavi hard-coded nel firmware | Un solo dispositivo estratto compromette l’intera flotta |
| Aggiornamenti non firmati o verificati in modo debole | Un attaccante può installare il proprio firmware |
| Componenti obsoleti con vulnerabilità note | Gli exploit pubblici funzionano senza modifiche |
| Pairing senza vera autenticazione | Chiunque si trovi nelle vicinanze può prendere il controllo del dispositivo |
| L’API cloud si fida dell’ID del dispositivo | Accesso ai dispositivi e ai dati di altri clienti |
| Stessa password predefinita su ogni dispositivo | Compromissione di massa da internet |
Nessuno di questi richiede tecniche esotiche. Richiede qualcuno che guardi.
Come si svolge un test
- Call di scoping. Quindici minuti per concordare il dispositivo, le sue interfacce e la profondità del test.
- Teardown e firmware. Entriamo nel dispositivo ed estraiamo ciò che vi gira.
- Attacco. Hardware, radio, app e cloud, e poi le combinazioni tra di essi.
- Report e debrief. Ogni vulnerabilità con proof-of-concept, severità e correzione, spiegata ai vostri ingegneri.
- Retest. Verifichiamo che le correzioni reggano.
Come prepararsi
- Inviate almeno due dispositivi. Uno potrebbe non sopravvivere.
- Mettete a disposizione un ambiente di test nel cloud, separato dalla produzione.
- Forniteci immagini firmware e documentazione, se le avete. Fa risparmiare giorni.
- Indicate un ingegnere che possa rispondere rapidamente alle domande.
Perché adesso
Dal 1° agosto 2025 i requisiti di cybersecurity della Radio Equipment Directive si applicano ai dispositivi wireless, e da dicembre 2027 il Cyber Resilience Act si applicherà a quasi tutto ciò che ha elementi digitali. Entrambi si aspettano che i prodotti vengano testati prima di essere immessi sul mercato.
Volete sapere come regge il vostro dispositivo? Scoprite i nostri test di sicurezza IoT oppure richiedete un’offerta per un pentest.
FAQ
Domande frequenti
Di che cosa avete bisogno da noi per un pentest IoT?
Due o tre dispositivi, idealmente uno con accesso di debug abilitato, l’app associata, un account di test per il cloud e tutta la documentazione esistente. Più materiale riceviamo, più in profondità possiamo andare nello stesso tempo.
Il test danneggerà il dispositivo?
Gli attacchi hardware possono farlo. Apriamo i dispositivi, saldiamo sui test point e a volte rimuoviamo i chip flash, per questo chiediamo più di un campione.
Un pentest IoT è sufficiente per il Cyber Resilience Act?
È un tassello importante: il CRA richiede che i prodotti vengano immessi sul mercato senza vulnerabilità sfruttabili note e che vengano testati. Servono inoltre processi di sviluppo sicuro, gestione delle vulnerabilità e documentazione.