Analisi della scheda
Identifichiamo componenti, test point e connettori di debug e ricostruiamo cosa è collegato a cosa.
Pentest hardware ed embedded
Apriamo il dispositivo. Poi il firmware.
Test point, porte di debug, chip flash e bootloader: tutto ciò che un attaccante con un cacciavite e un weekend libero andrà a guardare. Noi lo facciamo in laboratorio, con gli stessi strumenti e più pazienza.
- JTAG, SWD, UART
- Estrazione e reverse engineering del firmware
- Analisi del secure boot
In breve
Un penetration test hardware attacca fisicamente un dispositivo embedded: interfacce di debug come UART, JTAG e SWD, chip di memoria, processo di boot e il firmware stesso. Gli obiettivi sono estrarre firmware e segreti, aggirare il secure boot, ottenere l’esecuzione di codice e trovare falle che riguardano ogni dispositivo dello stesso tipo. Zyberum esegue pentest hardware nel proprio laboratorio su prodotti IoT, ECU automotive e componenti industriali.
Cosa facciamo
Dalla scheda alla shell di root
Interfacce di debug
Console UART, JTAG e SWD: bloccate, sbloccate o solo ritenute bloccate.
Estrazione del firmware
Dalla porta di debug, dal file di aggiornamento o direttamente dal chip flash.
Secure boot e chiavi
Ogni stadio verifica il successivo? Dove sono le chiavi, e chi può leggerle?
Fault injection
Glitching di tensione e di clock per saltare i controlli che il solo software non riesce ad aggirare.
Reverse engineering
Analisi del firmware in Ghidra: segreti, logica di aggiornamento, comandi nascosti ed errori di memoria.
Perché conta
Un solo dispositivo aperto può esporre l’intera flotta
Gli attacchi hardware richiedono l’accesso fisico, e questo suona rassicurante. Non lo è: un attaccante compra un dispositivo, estrae il firmware, trova la chiave condivisa o il servizio nascosto e poi usa ciò che ha scoperto contro tutti i dispositivi sul campo, da remoto.
Per questo oggi lo chiedono le normative. Il Cyber Resilience Act, i requisiti di cybersecurity della RED (EN 18031) e la IEC 62443-4-2 si aspettano tutti interfacce di debug chiuse, segreti protetti e aggiornamenti sicuri.
Case study
Cosa abbiamo trovato su dispositivi reali
IoTMQTT
Caso di studio: l’irrigazione smart che chiunque poteva comandare
Tramite MQTT abbiamo potuto vedere e attivare i dispositivi di altri clienti e geolocalizzare il punto in cui sono installati.
Abbiamo testato un sistema di irrigazione smart: una configurazione MQTT difettosa ci ha permesso di vedere, comandare e localizzare i dispositivi di altri clienti.
Leggi il case studyIoTSicurezza API
Caso di studio: robot aspirapolvere, root e telecamere altrui
Accesso root completo al dispositivo e accesso alla telecamera WebRTC live di altri utenti tramite l’API cloud.
Abbiamo testato un robot aspirapolvere con telecamera: accesso root al dispositivo e falle nell’API cloud che aprivano la telecamera live di altri utenti.
Leggi il case studyFAQ
FAQ sul pentest hardware
Di quanti dispositivi avete bisogno?
Due o tre. Gli attacchi hardware possono distruggere un dispositivo, ad esempio quando rimuoviamo un chip flash.
Testate anche app e cloud?
Sì, con un test completo del prodotto IoT. Molte delle vulnerabilità peggiori nascono dalla combinazione di una falla hardware con un punto debole nel cloud.
Potete testare microcontrollori bloccati?
Spesso sì. La protezione in lettura si può a volte aggirare con la fault injection o sfruttando punti deboli noti del chip. Nella call di scoping vi diciamo cosa è realistico per il vostro dispositivo.
Per iniziare
Definite il vostro pentest hardware in 15 minuti
Parlateci del dispositivo, del suo processore e delle sue interfacce. Dopo la call ricevete un’offerta a prezzo fisso.
- Perimetro per interfacce e profondità di attacco
- Offerta a prezzo fisso dopo la call
- Ci bastano due o tre dispositivi campione
Parlerete conTom ZaubermannFondatore e CEO, Zyberum
Oppure scriveteci
Rispondiamo entro un giorno lavorativo.