I ricercatori dei Forescout Research Labs hanno scoperto 33 vulnerabilità che interessano quattro dei principali TCP/IP stack open source utilizzati in milioni di dispositivi connessi in tutto il mondo.
Questo gruppo di vulnerabilità denominato “Amnesia: 33”, perchè colpisce prevalentemente lo stato di memoria dei dispositivi, può consentire agli aggressori di:
Lo stack TCP/IP embedded fornisce le funzionalità di comunicazione in rete, essenziali per i dispositivi IoT, a molti dei sistemi operativi utilizzati nei dispositivi integrati che desiderano sfruttare i protocolli basati sul TCP/IP. Questi software sono sfruttati anche nelle più recenti tecnologie come l’Edge Computing.
I ricercatori hanno individuato le 33 vulnerabilità nelle seguenti implementazioni:
Le vulnerabilità interessano sette diversi componenti dello stack: DNS, IPv6, IPv4, TCP, ICMP, LLMNR e mDNS e possono essere trovate in prodotti che vanno dai componenti embedded (come i Systems on a Chip – SoC, i moduli di connettività e le schede OEM) all’IoT consumer (come le prese e i termostati intelligenti), dal networking alle apparecchiature d’ufficio (come stampanti, switch e software dei server) per finire con i dispositivi OT (come i dispositivi utilizzati per il controllo dell’accesso, le telecamere IP, i Remote Terminal Unit (RTU) e i sistemi di condizionamento (HVAC)).
Le vulnerabilità e le loro possibili conseguenze sono state dettagliate nel Report dei Forescout Research Labs (1). Tuttavia, va sottolineato, l’impatto finale dipende dallo specifico dispositivo che utilizza lo stack vulnerabile e dal contesto in cui è inserito. Per esempio, una vulnerabilità della classe DoS non è generalmente considerata critica, ma potrebbe esserlo se il target è un dispositivo OT in ambiente critico dove la disponibilità rappresenta indubbiamente un requisito indispensabile.
È possibile, inoltre, sfruttare la vulnerabilità offerta dal Remote Code Execution dei dispositivi attaccabili per commettere frodi ad un contatore smart, violare le reti aziendali tramite la building automation e i router, le VPN, i firewall o gateway o tentare di causare danni fisici ad un safety controller.
Poiché i bugs interessano diverse implementazioni dello stack TCP/IP open source, è difficile individuare in maniera puntuale tutti i dispositivi interessati. Inoltre, a causa delle molteplici fork, branch e versioni dello stack non supportate (ancora disponibili), sarà difficile applicare le patch e spesso questo non avverrà mai.
Un ulteriore difficoltà è rappresentata dalla circostanza che questi componenti software possono essere integrati nei S.O. dei dispositivi IoT in diverse modalità: possono essere compilati direttamente nel codice sorgente, modificati, integrati e collegati come librerie dinamiche o statiche e, conseguentemente, fornire un’ampia varietà di implementazioni. La molteplicità di opzioni e la mancata visibilità della catena di approvvigionamento rende molto difficile e complessa la valutazione precisa del loro impatto e, soprattutto, la potenziale sfruttabilità di queste vulnerabilità.
In generale, la maggior parte di questi bugs causa errori nella gestione della memoria. L’impatto può variare significativamente da un dispositivo ad un altro simile a causa delle molteplici combinazioni di build e runtime personalizzate incluse nei dispositivi IoT.
In sintesi, un utente malintenzionato, remoto e non autenticato, potrebbe essere in grado di utilizzare dei pacchetti di rete appositamente predisposti per far sì che il dispositivo vulnerabile si comporti in maniera imprevista, oppure generare un errore, con la conseguenza che ciò possa causare il diniego ad un determinato servizio e, perfino, divulgare informazioni private o eseguire del codice arbitrario.
Questa fattispecie di problematiche connesse all’implementazione dei software può essere affrontata con due approcci distinti.
Il primo approccio, che ha un obiettivo a breve termine, si concentra sui dispositivi in produzione e si concretizza in una serie di azioni a carico del settore IT o dell’utente finale per tentare di applicare tutti gli aggiornamenti di sicurezza rilasciati e rimuovere le vulnerabilità note.
Se questi componenti software sono stati forniti da un provider, occorrerebbe contattarlo per ottenere gli aggiornamenti appropriati che dovranno essere integrati nel software in uso. Mentre gli utenti finali di dispositivi IoT embedded, che implementano questi software vulnerabili, devono contattare il proprio fornitore o il rivenditore per ottenere gli aggiornamenti opportuni.
Il secondo approccio ha una visione a medio e lungo termine e si attua attraverso una serie di best practices che è opportuno seguire prima di connettere un nuovo dispositivo IoT alla propria rete:
Non è la prima volta che gli stack TCP/IP risultano vulnerabili agli attacchi. Alla fine del 2019, i ricercatori di Armis hanno rivelato 11 vulnerabilità in IPnet, uno stack TCP/IP utilizzato in Wind River VxWorks, un sistema operativo utilizzato da oltre due miliardi di dispositivi in ambienti industriali, medici e aziendali (3).
Quindi, nel giugno 2020, i ricercatori di JSOF hanno individuato 20 vulnerabilità nella libreria Treck TCP/IP, utilizzata in centinaia di milioni di dispositivi IoT e OT (4).
Queste criticità rappresentano indubbiamente una grande sfida per la mitigazione del rischio cyber a carico delle organizzazioni che sfruttano le tecnologie basate sull’IoT nei loro cicli produttivi.
L’analisi ha consentito di evidenziare un’altra importante debolezza: molto spesso questi dispositivi non sono accompagnati da schede tecniche dettagliate che aiutano a comprendere i componenti, hardware e software, utilizzati per produrli e, di conseguenza, diventa particolarmente complesso, se non impossibile, ottenere queste informazioni utili agli addetti alla sicurezza per l’applicazione del patching adeguato.
L’ecosistema IoT è altamente competitivo e, di conseguenza, è divenuto un settore dell’ICT fortemente esposto all’utilizzo di software difettoso a causa di catene di approvvigionamento complesse che propagano facilmente le vulnerabilità.
A riguardo si sottolinea l’importanza della sicurezza nella supply chain del software e dei dispositivi IoT.
A tal proposito è utile ricordare le recenti “Guidelines for Securing the Internet of Things” (5) emanate il 9 novembre 2002 dall’ European Union Agency for Cybersecurity (ENISA) e incentrate sulla sicurezza della supply chain per l’IoT. L’Italia ha già avviato da anni un percorso virtuoso di validazione con l’istituzione dell’OCSI (Organismo di Certificazione della Sicurezza Informatica) a cui è stata delegata la gestione dello Schema nazionale per la valutazione e la certificazione della sicurezza di sistemi e prodotti nel settore della tecnologia dell’informazione ai sensi del DPCM del 30 ottobre 2003 (G.U. n.98 del 27 aprile 2004). Pertanto, al momento di scegliere un prodotto IoT o OT è fortemente consigliato verificare il percorso di certificazione effettuato.
Articolo a cura di Vincenzo Calabrò
Arrestato a Parigi il CEO di Telegram: cosa significa in termini di responsabilità delle piattaforme…
Introduzione In un contesto in cui la digitalizzazione sta crescendo costantemente, è importante sapere come…
Casi come Cellebrite Ufed v. Signal pongono in luce come la cybersecurity sia un fattore…
I Big Data stanno cambiando le regole del commercio online. Finalmente le aziende possono comprendere…
Dal punto di vista tecnico-operativo, le indagini di digital forensics vengono svolte utilizzando specifici strumenti…
Nell’ambito dell’email security esistono diversi protocolli volti a garantire l'autenticità, l'integrità e la riservatezza delle…