Come vengono attaccati i dispositivi IoT e come si difendono?

Un dispositivo IoT è un piccolo computer economico, prodotto in grandi quantità, esposto fisicamente, raramente sorvegliato e collegato a una rete. Ognuna di queste caratteristiche è già di per sé un problema di sicurezza. Messe insieme, spiegano perché i dispositivi connessi sono stati la materia prima di alcuni dei più grandi attacchi su internet, e perché la sicurezza IoT è ormai materia di legge in diverse giurisdizioni.

La buona notizia è che le minacce sono ben comprese e le difese sono in gran parte note. La parte difficile è applicarle con costanza lungo tutta la vita del prodotto, dalla linea di produzione al giorno della dismissione.

Questa guida passa in rassegna la superficie di attacco di un dispositivo tipico, gli attacchi che avvengono davvero e le difese a più livelli che li riducono.

Qual è la superficie di attacco di un dispositivo connesso?

Immagina il dispositivo come un insieme di porte. Il firmware è una di queste: se contiene un bug, un attaccante con accesso alla rete può sfruttarlo. I servizi di rete esposti sono un’altra: un’interfaccia web, una porta Telnet, un client MQTT. L’account cloud con cui il dispositivo dialoga è una terza, perché una credenziale rubata lì può raggiungere ogni dispositivo. Le porte fisiche sulla scheda sono una quarta: le interfacce di debug come JTAG o una console UART spesso danno il pieno controllo a chiunque abbia il dispositivo in mano. Il meccanismo di aggiornamento è una quinta, e l’app mobile con la sua API una sesta.

A tutto questo si aggiunge la catena di fornitura (supply chain). Un dispositivo nasce da chip di terze parti, dall’SDK di un fornitore, da librerie open source e dalla linea di produzione di un terzista. Ciascuno di questi elementi può introdurre una debolezza che il team di prodotto non vedrà mai.

Quali attacchi avvengono davvero?

Credenziali predefinite e deboli

La botnet Mirai del 2016 non usava nessun exploit ingegnoso. Scandagliava internet alla ricerca di dispositivi che accettassero login Telnet e provava un breve elenco di nomi utente e password di fabbrica. Trovò centinaia di migliaia di telecamere, router e videoregistratori e li usò per attacchi DDoS che misero fuori uso grandi servizi. Le credenziali predefinite restano il modo più comune in assoluto per compromettere un dispositivo, ed è per questo che il regime PSTI britannico vieta del tutto le password predefinite universali e il Cyber Resilience Act europeo impone che i prodotti vengano distribuiti con una configurazione sicura per impostazione predefinita.

Vulnerabilità senza patch

I dispositivi arrivano sul mercato con bug noti negli stack di rete, nei server web e nelle librerie, e molti non ricevono mai un aggiornamento. Una CVE pubblicata per una libreria TCP/IP diffusa può riguardare milioni di unità di centinaia di marchi che nemmeno sanno di condividere quel codice. Senza una distinta base del software (SBOM), il fornitore non è neppure in grado di dire se è coinvolto.

Aggiornamenti insicuri

Un meccanismo di aggiornamento che scarica il firmware in HTTP non cifrato e installa qualsiasi cosa arrivi è un regalo per l’attaccante: basta intercettare il download e il dispositivo esegue il suo codice con tutti i privilegi. Gli aggiornamenti senza verifica della firma, o con la chiave di firma conservata nel firmware stesso, sono varianti dello stesso problema.

Servizi esposti e configurazioni cloud sbagliate

Un dispositivo che apre una porta verso internet per semplificare l’accesso remoto la apre anche a chiunque altro. Sull’altro fronte, un back end cloud con un’API priva di autenticazione, permessi troppo ampi per i dispositivi o un segreto condiviso da tutta la flotta fa sì che un solo dispositivo compromesso possa leggere o controllare tutti gli altri.

Attacchi fisici

Con il dispositivo in mano, un attaccante può estrarre il contenuto della memoria flash, leggere le chiavi, modificare il firmware o sondare la scheda. Per i prodotti consumer è una preoccupazione limitata; per i dispositivi installati in spazi pubblici, come contatori intelligenti (smart meter), sensori di parcheggio o colonnine di ricarica, è la preoccupazione principale. Gli attacchi side-channel, che ricavano le chiavi dai consumi elettrici o dai tempi di esecuzione, sono un tema da specialisti riservato ai bersagli di alto valore.

Come si difende il dispositivo?

Nessun controllo da solo risolve il problema. La stratificazione abituale parte dall’hardware.

Un root of trust, idealmente in un secure element o nell’area protetta del SoC, custodisce chiavi che il firmware non può estrarre. Il secure boot lo usa per verificare ogni fase della catena di avvio, così un firmware modificato semplicemente non parte. La stessa disciplina di firma vale per ogni aggiornamento OTA: le immagini vengono firmate con una chiave custodita offline, verificate sul dispositivo e installate con una partizione di riserva, in modo che un aggiornamento difettoso non renda inutilizzabile l’unità.

Ogni dispositivo riceve la propria identità, in genere un certificato X.509 con una chiave privata generata sul dispositivo e mai esportata. I segreti condivisi da tutta la flotta vanno evitati. Le porte di debug vengono disabilitate o bloccate in produzione. I servizi di rete inutilizzati vengono rimossi, non solo spenti, e quelli che restano girano con il minimo dei privilegi che il sistema operativo consente.

Infine, il firmware va costruito come software, non come un pezzo unico: le dipendenze sono tracciate in una SBOM, analizzate alla ricerca di CVE e aggiornate. Un watchdog timer e la segnalazione dei crash danno al fornitore la possibilità di accorgersi quando qualcosa va storto sul campo.

Come si difendono la rete e il cloud?

Ogni connessione usa TLS o DTLS con autenticazione reciproca: il dispositivo dimostra chi è con il proprio certificato, e il server dimostra chi è con un certificato di cui il dispositivo si fida. L’autorizzazione è circoscritta, così un dispositivo può pubblicare sui propri topic e su nient’altro; una policy del broker MQTT che permette a qualsiasi client di sottoscrivere tutto è una violazione annunciata.

Sulle reti locali, la segmentazione della rete tiene i dispositivi lontani da laptop e server, così una telecamera compromessa non può raggiungere il database della contabilità. In ambito industriale questo principio è formalizzato nelle zone e conduit di IEC 62443. L’accesso remoto passa da una VPN o da un relay cloud, non da porte aperte in ingresso. Il monitoraggio controlla i dispositivi che iniziano a dialogare con indirizzi inattesi o con volumi anomali, che è spesso il primo segnale del reclutamento in una botnet. Vale il principio dello zero trust: la posizione in una rete non concede nulla, identità e policy concedono tutto.

Cosa deve fare l’organizzazione?

La tecnologia da sola fallisce senza processi. Una policy pubblica di divulgazione delle vulnerabilità permette ai ricercatori di segnalare i problemi invece di venderli. Un periodo di supporto dichiarato dice agli acquirenti per quanto tempo arriveranno gli aggiornamenti. Un penetration test prima del lancio trova le falle più evidenti. Un piano per il fine vita evita che i dispositivi restino online, senza patch, per sempre.

Sono esattamente gli obblighi che il Cyber Resilience Act, il PSTI Act e la ETSI EN 303 645 oggi impongono, quindi integrarli fin dall’inizio è al tempo stesso buona ingegneria e preparazione alla conformità normativa.

Da dove dovrebbe partire un team?

Per un team che mette sul mercato il suo primo dispositivo, le priorità in ordine sono: credenziali uniche per ogni unità e nessuna password predefinita; aggiornamenti del firmware firmati e verificati; TLS con certificati per dispositivo; nessuna porta esposta in ingresso; un elenco tracciato delle dipendenze; una policy di divulgazione con un indirizzo di contatto. Secure boot e root of trust hardware vengono subito dopo, e sono molto più facili da aggiungere prima che l’hardware sia definitivo che dopo.

Per continuare

• Identità dei dispositivi, certificati e PKI per l’IoT approfondisce il sistema di credenziali su cui poggia la maggior parte di queste difese.
• La normativa sulla sicurezza IoT spiega cosa richiedono CRA, PSTI, Cyber Trust Mark e ETSI EN 303 645.
• Gestione dei dispositivi e aggiornamenti over the air spiega come distribuire le correzioni a una flotta in sicurezza.

Argomenti: sicurezza IoT, minacce, superficie di attacco, botnet, secure boot