Sicurezza dell'Internet delle Cose

Prima di arrivare ai problemi di sicurezza informatica, prendiamoci un momento per definire di cosa stiamo parlando, in modo da iniziare tutti dallo stesso punto di partenza.

L'espressione "Internet delle cose" o "IoT" può essere poco chiara e può assumere significati diversi. In questo articolo la utilizzo per riferirmi a dispositivi di calcolo a bassa potenza (sia per consumo energetico che per capacità di calcolo) integrati in oggetti che la maggior parte delle persone non riconoscerebbe come computer. Questi dispositivi sono distribuiti ma hanno una sorta di capacità di rete, quindi non sono isolati, anche se ciò non significa necessariamente che stiano utilizzando il Protocollo Internet (IP).

Inoltre, va notato che anche l'architettura dell'IoT si è evoluta con l'introduzione di nuove tecnologie:

l'IoT ha seguito il modello generale del mondo informatico, dove l'elaborazione avveniva inizialmente su mainframe massicci e costosi con terminali poco intelligenti. Man mano che l'elaborazione è diventata più economica, è stato possibile spostare il lavoro utile dal mainframe alle workstation collegate e infine ai desktop collegati in rete, utilizzando i server principalmente per l'archiviazione dei dati.

L'architettura IoT originale riguardava la connessione di dispositivi a bassa potenza al cloud, in cui era possibile elaborare i dati raccolti. Poiché oggi i microcontrollori sono più potenti, l'interazione diretta tra i nodi per formare mesh o griglie per il calcolo cooperativo sta diventando comune. Una quota maggiore di elaborazione pesante avviene molto più vicino al bordo: si parla di Fog computing, ovvero il cloud computing fatto molto "più vicino al suolo". È essenziale per qualsiasi tipo di controllo su applicazioni in tempo reale a bassa latenza, soprattutto in presenza di un numero molto elevato di dispositivi IoT che creano volumi enormi di dati.

Qualsiasi applicazione IoT può essere suddivisa in (più o meno) quattro livelli generali, come illustrato nella Figura 2. Suddividendo l'applicazione in questi livelli, possiamo individuare un po' più chiaramente le superfici di attacco che vengono presentate ai malintenzionati in ogni fase, ma anche riflettere su dove possono verificarsi veri malintesi o abusi non intenzionali.

Iniziamo considerando due incidenti separati che interessano le applicazioni IoT a livello di sensore, in questo caso nelle auto a guida autonoma. Nel 2018 SoraNews24 ha riferito che il logo della catena giapponese di negozi di ramen Tenkaippin faceva confondere il software SENSING AI di Honda, che pensava di vedere un cartello "Non entrare". Naturalmente si è trattato di un semplice fraintendimento, ma questo tipo di errore di input può causare conseguenze sul lungo termine.

Il secondo incidente, riportato su IFLScience, è stato forse più preoccupante: gli hacker sono stati in grado di far sterzare una Tesla con il pilota automatico dirigendola verso il traffico in arrivo, usando solo degli adesivi posti sulla strada. Fortunatamente, in questo caso gli autori erano dei ricercatori, e non dei malintenzionati, ma, proprio come per l'esempio precedente, gli ingegneri devono tenere in considerazione che quando l'IA entra nella vita di tutti noi si trova senza ombra di dubbio ad affrontare delle situazioni per le quali non è stata addestrata. Per qualsiasi applicazione IoT è fondamentale saper reagire correttamente a questo tipo di input di dati inaspettati, senza conseguenze fatali.

Nella Figura 3 viene fornito un elenco indicativo dei tipi di attacco a cui può essere sottoposta un'applicazione IoT a ogni livello. I più attenti tra voi avranno notato che sono passato a un 5° elemento (niente a che fare con Milla Jovovich, purtroppo) che ho chiamato il "Livello gateway". Questo livello non è direttamente correlato all'applicazione, ma riguarda l'aggiunta sicura di un elemento IoT in un sistema distribuito.

Come ho già detto, tratteremo solo uno o due attacchi per livello, ma facendo riferimento all'elenco potrete cercare ulteriori informazioni sugli altri, se interessati.

Livello sensore

A partire dal livello del sensore, i singoli nodi possono essere vulnerabili all'acquisizione o alla sostituzione. A volte è sufficiente aggiungere semplicemente un nodo extra, che appare come uno in più tra migliaia. Una volta che un nodo compromesso fa parte della rete, la porta è aperta a molti altri attacchi.

L'esempio dell'auto a guida autonoma ci ha già mostrato che è possibile inserire dati falsi anche quando i nodi non sono direttamente sotto il controllo di un utente malintenzionato. Ma una volta che un utente malintenzionato prende il controllo, l'eventualità migliore che può verificarsi è che un nodo venga utilizzato solo per una parodia relativamente innocua, come è accaduto con l'hack di Lime Scooters nel 2019.

Tuttavia, il motivo più comune per cui qualcuno potrebbe voler controllare il vostro nodo non ha nulla a che fare con la rete: l'obiettivo è costruire un esercito di "bot" (o "botnet") che può essere utilizzato in un attacco DDoS (Distributed Denial of Service) a livello di rete.

Livello di rete

In un attacco DDoS, i server di destinazione sono inondati da richieste di servizio fasulle provenienti da migliaia di nodi zombie orchestrati da un server di comando e controllo, che di solito è stato anche violato. I gruppi di hacker che controllano una botnet spesso eseguono attacchi a noleggio, quindi, ad esempio, un'azienda senza scrupoli può pagare un gruppo per abbattere il sito web di un concorrente il giorno in cui questo concorrente lancia un nuovo prodotto, impedendo agli utenti legittimi di accedere al sito e rovinando il lancio.

Sebbene gli attacchi DDoS non li riguardino specificamente, è capitato che i dispositivi IoT siano stati vulnerabili all'uso a causa della configurazione debole, come password hardwired (cioè non modificabili) o password predefinite pubblicate su dispositivi che non costringono gli utenti a modificarle al primo utilizzo.

Il più famoso di questi attacchi è probabilmente quello ai server DNS di Dyn, realizzato mediante Mirai botnet, che ha causato il blocco di Internet lungo tutta la costa orientale degli Stati Uniti. Nel febbraio di quest'anno, Amazon Web Services è riuscito a mitigare quello che, nel momento in cui sto scrivendo questo articolo, è il più grande attacco registrato a 2,3 terabit al secondo!

Gli attacchi di routing sono quelli in cui i nodi malevoli cercano di reindirizzare i dati che ricevono. Nell'attacco sinkhole il nodo corrotto offre un "percorso più breve" che porterà altri nodi a indirizzare il traffico verso di lui. Il sinkhole può essere combinato con un wormhole, in cui un utente malintenzionato utilizza una connessione fuori banda (cioè una connessione diretta che non fa parte del flusso di dati standard) per connettersi a un altro dispositivo, bypassando efficacemente la sicurezza della rete, consentendo il furto dei dati.

Livello middleware

L'attacco man-in-the-middle è un modo per sfruttare il modello di comunicazione publish-subscribe del protocollo MQTT. Il broker MQTT funge da proxy tra i client di pubblicazione e sottoscrizione, disaccoppiandoli e consentendo l'invio di messaggi senza bisogno di informazioni sulla destinazione. Quando un utente malintenzionato riesce a ottenere il controllo del broker, ha il controllo completo del flusso di dati, mentre i client sono ignari di cosa stia accadendo.

Livello di applicazione

Questo livello riguarda i servizi forniti all'utente. Ammettiamolo: gli utenti saranno sempre il più grande problema di sicurezza del progettista. La maggior parte degli utenti non capisce la tecnologia o non è interessata a conoscerla (per quanto la riguarda, potrebbe pure trattarsi di magia), ma si aspetta che funzioni e si infastidisce molto quando scopre che i propri dati privati sono sparsi per tutto il web.

A questo livello, l'applicazione IoT deve proteggere gli utenti dalla violazione della sicurezza, dal furto di dati (suggerimento: configurare correttamente i bucket di archiviazione AWS S3) e dalla perdita del controllo delle applicazioni.

Iniezioni di codice malevolo: gli hacker sono abili nel trovare i metodi più semplici per entrare in un sistema. Se un sistema è vulnerabile a script dannosi o reindirizzamenti, perché non controlla correttamente il codice, è qui che gli utenti malintenzionati colpiranno. Un esempio è (CVE)-2018-10933, che documenta un bug nella libreria che implementa il protocollo Secure Shell (libssh), in cui, a causa di una struttura condivisa nel codice lato client e lato server, un client dannoso potrebbe accedere alla connessione autenticata semplicemente dichiarando SSH2_MSG_USERAUTH_SUCCESS, cioè rivendicando l'autenticazione, indipendentemente dal risultato dell'autenticazione!

Il metodo più comune di iniezione di codice malevolo è l'XSS o cross-site scripting per ottenere uno script malevolo in quello che altrimenti sarebbe un sito web attendibile.

Livello gateway

Il livello gateway può servire a una serie di scopi. È qui che più nodi (forse eterogenei) sono collegati localmente da protocolli come Bluetooth Mesh, Zigbee, Z-wave o persino LoraWan, prima di connettere questi dati al cloud. Per questo, nel gateway i protocolli vengono tradotti per la comunicazione tra diversi livelli. Ciò può anche significare decrittografare e ri-crittografare i flussi di dati dentro e fuori da questo livello.

I gateway sono un componente fondamentale per l'onboarding sicuro di nuovi nodi. Fungono da intermediari tra i nuovi dispositivi e i servizi di gestione, quindi devono proteggere tutte le chiavi di crittografia che li attraversano. Possono essere oggetto di attacchi man-in-the-middle o di intercettazione per acquisire queste chiavi durante l'onboarding. Naturalmente, l'onboarding può facilitare questa procedura agli hacker semplicemente trasmettendo informazioni utili sulla configurazione.

Un altro ruolo importante del livello gateway riguarda gli aggiornamenti del firmware. È possibile utilizzare il gateway per scaricare e installare gli aggiornamenti, poiché i dispositivi IoT tendono a non disporre delle risorse per farlo. Quindi il gateway diventa responsabile della registrazione della versione attuale del firmware e del controllo della validità delle firme. È opportuno non brickare i propri dispositivi con un aggiornamento.

La sicurezza dei computer in rete tende a seguire la seguente filosofia: penetrare, poi installare patch con ricompense per la segnalazione di bug offerte nella speranza che i bravi ragazzi trovino prima le vulnerabilità. Forse una parte di ciò può essere portata avanti nell'IoT.

La mia sensazione è che forse vi sia una lacuna nel mercato delle società di sicurezza informatica, che dovrebbero eseguire test standard sulle apparecchiature IoT, per certificare per lo meno che non presentino difetti banali (come le password hardwired), affinché hackerarle non diventi un gioco da ragazzi.