Introduzione al Penetration testing su dispositivi IoT

Introduzione

Con il passare degli anni i dispositivi dell’Internet of Things sono entrati sempre più a far parte della vita di ognuno di noi, sia come strumento per il benessere personale, sia nelle industrie per cercare di migliorare e trasformare interi settori. Indubbiamente questo tipo di approccio tende ad apportare consistenti vantaggi, ma altrettanti nuovi ed incalcolabili rischi; basti pensare che quasi la totalità dei dispositivi IoT sono in grado di registrare suoni tramite il microfono integrato, scattare immagini e girare video grazie alla fotocamera e soprattutto avere sempre a disposizione le coordinate gps dell’utilizzatore. La maggior parte delle nostre informazioni personali, quindi, non sono adeguatamente protette e di conseguenza risultano facilmente raggiungibili da persone che hanno scopi poco leciti. A questo punto è doveroso chiedersi come fare in modo che questo non accada, ma soprattutto come testare la sicurezza dell’Internet of Things. Di seguito verranno introdotte ed analizzate le varie fasi di un Penetration Testing incentrato su dispositivi IoT. Iniziamo con una definizione di Penetration Testing data dal CREST (associazione no-profit inglese):

“Un Penetration Test è un metodo per la valutazione della sicurezza di un sistema informatico o di una rete simulando un attacco da parte di attaccanti esterni e/o di attaccanti interni”

Data la varietà dei sistemi in commercio, un penetration tester deve possedere un buon mix di conoscenze che richiamano molti aspetti dell’IT Security:

• È necessaria un’ottima conoscenza di network security per determinare quali protocolli sono utilizzati e di conseguenza quali informazioni possono essere a rischio;
• Deve possedere conoscenze di Web Application security per analizzare vulnerabilità ed errate configurazioni su tutti quei dispositivi che hanno un’interfaccia di configurazione basata sul web;
• Fondamentali, per ovvi motivi, sono le conoscenze sui sistemi embedded;
• Dopo aver estratto il firmware (e/o l’applicazione) del dispositivo è necessario decompilarlo ed analizzarlo per tentare di scovare falle nel codice, per questo sono necessarie buone conoscenze di reverse engineering.

Di seguito riportiamo la prima fase di un Penetration Testing incentrato sui dispositivi IoT.

Mapping the surface

A differenza di un ‘normale’ penetration testing, i dispositivi IoT coinvolgono svariate componenti (network, web, applicative custom, etc.) che devono essere testate per assicurare l’individuazione delle varie vulnerabilità. La prima e la più importante fase da affrontare è la mappatura della nostra superficie d’attacco. Questo step è fondamentale per capire l’architettura dei vari dispositivi e quali test sono più consoni da effettuare. Appena si viene a contatto con un nuovo dispositivo bisogna studiarne a fondo gli attributi, leggere la documentazione allegata, sfruttare risorse online o qualsiasi altra informazione disponibile, prendendo nota di tutte le caratteristiche che lo compongono (protocolli usati, applicazioni mobile, firmware, etc.) e tenendo sempre a mente che il comportamento del dispositivo potrebbe non essere del tutto conforme a ciò che ci si attendeva durante una prima e sommaria analisi. L’architettura di un dispositivo IoT potrebbe essere riassunta in 3 grandi categorie: firmware, software ed applicazioni; comunicazioni radio; sistemi embedded. Lo scopo finale deve essere quello di catalogare tutte le funzionalità e le possibili minacce derivanti dalle tre categorie di cui sopra.

Software – Applicazioni – Firmware

Come sappiamo, tutti i dispositivi IoT sono accompagnati dalle rispettive applicazioni mobile e desktop che consentono un’interazione con l’oggetto in questione; ciò vuol dire che attraverso esse comandiamo accendiamo/spegniamo luci, aggiungiamo/rimuoviamo dispositivi dalla nostra rete, aumentiamo/diminuiamo la temperatura, etc. Ma come è vista questa interazione in termini di Penetration Testing? Per un attaccante in cerca di vulnerabilità e punti di accesso, un’applicazione che consente di controllare in maniera diretta il dispositivo bersaglio non è solo una miniera di informazioni, ma anche il miglior “cavallo di Troia”: ad esempio, con la tecnica del fuzzing l’attaccante tenta di fare andare in crash l’applicazione (con l’invio di dati casuali) e successivamente la utilizza come “entry point” per la componente web individuando le chiamate API effettuate. Altri vettori d’attacco sono rappresentati da protocolli network mal configurati. Si pensi ad esempio ad una interfaccia web dove l’utente senza autorizzazioni possa vedere le varie informazioni sull’uso del dispositivo e quale utente possa o non possa controllarlo; viene spontaneo pensare che in caso ci fossero delle vulnerabilità un attaccante possa estrapolare, ad esempio, dati sensibili, oppure controllare il dispositivo anche se teoricamente non avrebbe i permessi per farlo (come successo l’anno scorso per alcuni modelli di baby monitor [2]). Spesso capita anche di vedere devices che hanno a bordo versioni datate e vulnerabili di protocolli come l’FTP (File Transfer Protocol) o l’SNMP (Simple Network Management Protocol) che consentono a chiunque voglia di controllare il dispositivo da qualsiasi parte del mondo. È quindi di fondamentale importanza non dimenticare che nella maggior parte dei casi i nostri dispositivi comunicano direttamente con l’intera internet, quindi sono esposti al mondo intero (si pensi alle IP Cam). Entrando leggermente più nello specifico, alcune vulnerabilità riscontrate sono:

• Informazioni sensibili che sono hardcoded nel firmware (password, URL, API, etc.)
• Componenti datate con vulnerabilità note
• Data leakage
• Comunicazioni network insicure
• Client side injection
• Cross Site Scripting [3]
• Cross Site Request Forgery [4]

Comunicazioni radio

Le comunicazioni radio forniscono ai vari dispositivi diversi modi per dialogare fra di loro. Alcuni dei protocolli più utilizzati sono Wi-Fi, BLE (Bluetooth Low Energy), Wave, LoRa, ZigBee. In base alla tipologia di protocollo, il pentester deve munirsi di apposite apparecchiature per svolgere tutti i controlli del caso. Purtroppo però le case produttrici dei dispositivi in commercio non prestano particolare attenzione alla sicurezza del meccanismo di comunicazione, quindi la possibilità di trovare falle aumenta. Le vulnerabilità più riscontrate sono attacchi di tipo MITM (Man in the Middle) [5], attacchi di replay [6], Denial of Service (DoS), mancanza di cifratura e la possibilità di estrarre informazioni sensibili dai pacchetti dei vari protocolli radio. Quando ci si trova ad esplorare la propria superficie d’attacco è doveroso farsi domande specifiche per capire meglio l’interazione tra i vari device, infatti dovremmo chiederci quali sono i ruoli di ogni singolo dispositivo, come avviene il meccanismo di autenticazione, quanti e quali device possono interagire tra di loro, su quale frequenza operano, se sono o meno utilizzati protocolli standard oppure creati ad-hoc.

Preparazione della superficie d’attacco

Dopo aver brevemente analizzato la maggior parte delle componenti di un dispositivo “intelligente”, si dovrebbe essere in grado di creare in maniera al quanto scrupolosa la famosa superficie d’attacco. Per questioni organizzative si consiglia di stilare la mappa seguendo questi consigli:

1. Creare un diagramma dell’intera infrastruttura; etichettare i vari devices e come interagiscono tra di loro;
2. Identificare i potenziali vettori d’attacco e i vari protocolli utilizzati nelle varie comunicazioni;
3. Categorizzare i vettori d’attacco in base alla loro criticità.

In questa fase si deve essere il più precisi possibile quindi è importante non tralasciare informazioni come le specifiche tecniche di ogni dispositivo.

Minori sono le informazioni a disposizione più è alto il rischio di non trovare tutte le vulnerabilità.

Esempio pratico

Dopo la teoria, passiamo alla pratica, con un esempio di come creare una superficie d’attacco per il kit Samsung Smart Things.

Come è possibile vedere dall’immagine il kit fornisce numerosi dispositivi da inserire all’interno della propria casa. Si hanno:

1. Un sensore di movimento
2. Un adattatore per una presa elettrica
3. Un sensore di presenza
4. Un Hub Smart

Come ipotizzato sopra, questo è uno dei dispositivi di cui viene fornita un’applicazione mobile sia per Android che per iOS. Cercando informazioni sia online che nella documentazione specifica si può chiaramente evincere che:

• i dispositivi comunicano via Bluetooth Low Energy (BLE);
• l’Hub smart comunica con vari protocolli quali ZigBee, zWave e 6LoWPAN;
• l’applicazione mobile può interagire con l’Hub tramite Wi-Fi;
• tale applicazione e l’Hub comunicano con il cloud ogni 5 minuti per condividere informazioni;
• l’applicazione mobile utilizza chiamate di tipo REST API.

Più nello specifico vediamo che l’Hub ha una porta ethernet ed uno slot esterno per schede SD che può essere usato solamente per fare l’upgrade del firmware; il processore utilizzato è un Broadcom; durante il primo setup, l’Hub si configura con le credenziali di default; l’applicazione continua a funzionare anche se viene trovato un certificato non-trusted. Queste sono informazioni di fondamentale importanza perché permettono di farsi un’idea su quali potrebbero essere i vettori d’attacco da sfruttare, ma soprattutto quale potrebbe essere l’impatto sull’ambiente in cui questo kit Smart opera.

Conclusioni

Come abbiamo visto, in questo articolo analizziamo come approcciarsi ad un penetration testing di dispositivi IoT, studiando in maniera approfondita tutta la superficie d’attacco che i device ci mettono a disposizione, partendo dal firmware, passando per le comunicazioni radio fino ad arrivare alle applicazioni mobile. Tutto questo però sarebbe inutile se non si seguono in dettaglio le 3 fasi sopra citate nel capitolo Preparazione della superficie d’attacco. Il perfetto pentester infatti sa che la prima regola d’oro in questo lavoro è collezionare dati, di qualunque tipo, anche il più irrilevante, perché in futuro, uno di loro sarà la chiave per il successo.

“Meno informazioni si hanno e più è alta la possibilità di fallire”

Bibliografia

1. http://www.crest-approved.org
2. https://www.healthline.com/health-news/baby-monitors-can-be-hacked
3. https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
4. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
5. https://it.wikipedia.org/wiki/Attacco_man_in_the_middle
6. https://en.wikipedia.org/wiki/Replay_attack

A cura di: Alessandro Di Carlo

Profilo Autore

Alessandro Di Carlo

Alessandro Di Carlo è laureato in Computer Science con una tesi sulla definizione di nuovi metodi per la rilevazione di APT (Advanced Persistent Threat). Alessandro è un cyber security consultant con più di 6 anni d’esperienza in cui ha collaborato con Forze dell’Ordine ed Infrastrutture Critiche fornendo servizi di Penetration Testing, Digital Forensics ed Incident Response. Alessandro è spesso invitato come relatore a conferenze nazionali ed internazionali. Ha conseguito numerose certificazioni tra cui l’eCPPT (eLearnSecurity Certified Professional Penetration Tester) ed l’eWAPT (eLearnSecurity Web Application Penetration Tester).