L’installazione di un termostato intelligente (noto anche come termostato WiFi) in una abitazione aiuta a mantenere costanti le temperature desiderate, tiene conto degli stili di vita, e va in auto-risparmio autonomamente se non ci sono persone in casa: condiziona cioè l’ambiente al momento giusto, senza accumulare i costi energetici che possono derivare da usi inutili durante la giornata, mentre tutti sono al lavoro o a scuola. Offre Inoltre la remotizzazione del controllo dell’ambiente direttamente dallo smartphone.
Ma ci sono anche altri vantaggi, oltre a una serie di serie criticità legate alla privacy e alla nostra sicurezza, che è importante conoscere: vediamo quali.
Riduzione al minimo dei costi energetici
Abbiamo già introdotto il motivo principe alla scelta del passaggio a un termostato WiFi quale il risparmio sui costi energetici. Con un termostato intelligente, è facile programmare un impianto in modo che funzioni meglio e meno a lungo, durante la giornata, quindi utilizzando meno energia per climatizzare la casa solo mentre si è all’interno. Sappiamo che il nemico del nostro risparmio in bolletta sono le impennate sul consumo, perché tutte le strutture devono essere portate “a temperatura” con lentezza e insistenza e non con potenza istantanea, che causa una dissipazione maggiore dell’energia.
E’ dimostrato infatti che le funzioni “superfreeze” che sono ormai rappresentate su tutti i telecomandi dei condizionatori d’aria, sono le più dispendiose in termini di rendimento: in sostanza una grande emissione di aria fredda, che stempera poco e male l’ambiente. L’impressione immediata che se ne ha sul nostro corpo è di benessere ma il consumo elettrico sale alle stelle e l’effetto di raffreddamento sulla stanza minimo. Si sa che i motori a combustione “esterna” come anche quello del nostro frigorifero, devono funzionare a lungo e a basso regime per raggiungere il risultato desiderato in modo efficiente e non sprecare energia elettrica. Niente di peggio dunque che rientrare in casa quando ancora il sole non è tramontato, in piena estate, ed accendere al massimo il condizionamento dell’aria. Sarebbe opportuno invece programmare il termostato digitale affinché entri in azione proprio prima che i membri della famiglia inizino a tornare a casa, in modo che la tua casa sia raffreddata a con i gradi desiderati perfetti dal momento in viene varcata la porta d’ingresso. Il termostato per questo motivo, collegandosi con l’app installata nello smartphone che lo geolocalizza, può utilizzare i virtual geo-fences (recinti virtuali) che possono ad esempio essere rappresentati da un raggio di 10 km dall’abitazione, all’interno del quale viene preventivamente attivato l’impianto dal nostro termostato smart.
La maggior parte dei termostati intelligenti dispongono di rilevatori di movimento, in modo che possano “sapere” quando i membri della casa sono a casa e attivi. Nel tempo, possono memorizzare automaticamente le abitudini di movimento della famiglia quando la casa deve essere raffreddata o riscaldata e possono persino utilizzare questi dati per regolare un programma di riscaldamento e raffreddamento per tenere conto dei cambiamenti stagionali nel modo viene usata la casa. Il termostato saprà che, d’inverno, con l’avvicinarsi delle festività, verrà usato più spesso il salone e, alla sera, di meno lo studio e una parte della casa, e convoglierà l’aumento di temperatura comandando a distanza la chiusura delle valvole dei caloriferi nelle stanze disabitate, fino al nuovo rilevamento di movimento o cambiamento di abitudini.
Stima del reale risparmio
Ma quanto ci si può davvero aspettare di risparmiare? Diversi produttori propongono diversi livelli di risparmio, ma la produzione del termostato intelligente Nest afferma che si risparmia il 15% sui costi di raffreddamento e il 10-12% sui costi di riscaldamento. I produttori di alcuni tra i termostati intelligenti più noti stimano che i clienti risparmiano il 23% sui costi combinati di riscaldamento e raffreddamento. Questo vorrebbe dire che se si ipotizza una spesa di riscaldamento di 1600 euro/anno e di raffreddamento su 6 mesi di 900 euro avremmo il 23% di risparmi su 2500 euro/anno cioè 575 euro in un anno (che è circa il doppio del prezzo medio di un termostato smart che abbia le funzioni di cui stiamo parlando).
Tracciamento predittivo del consumo di energia
La maggior parte dei termostati digitali consente agli utenti di monitorare il consumo di energia ricreando un profilo energetico della casa per tenere conto dei suoi cambiamenti nel tempo, anche a fronte di modifiche integrative (verande solari, serre, coibentazioni, infissi a taglio termico) che dovrebbero ridurre i costi energetici. Questo restituisce la possibilità di prevedere i consumi futuri e di regolare le preferenze di climatizzazione per ridurre ulteriormente i costi energetici.
Controllo remoto
Un altro noto vantaggio dell’installazione di un termostato WiFi è il controllo remoto della temperatura di un ambiente. Regolando il programma di raffreddamento accedendo all’App sul proprio smartphone, si può disattivare la partenza della climatizzazione se si è deciso di rincasare tardi o di ritardare il rientro dal weekend, in nostra assenza la casa rimarrà a temperature più basse evitando di consumare energia d’inverno o temperature più alte d’estate, per non attingere inutilmente alla rete di distribuzione elettrica (ma anche all’impianto fotovoltaico o solare-termico).
Anche avendo da gestire una eventuale manutenzione della casa per le vacanze, il termostato potrà inviare allarmi di temperatura, in caso essa scenda sotto dei limiti impostati, in modo da evitare il congelamento dell’impianto sotto i 0° o per monitorare il corretto funzionamento anche da lontano.
Eliminare la seccatura dalla programmazione
I “vecchi” termostati imponevano, subito dopo l’installazione, una difficile o quanto meno farraginosa programmazione, tanto più difficoltosa e noiosa quanti meno tasti erano presenti sul cruscotto del termostato. Una volta fissato un programma, inoltre, l’accessibilità alla modifica rimaneva appannaggio del solo membro della famiglia che ne conosceva e ricordava gli algoritmi, e regolare il programma di riscaldamento e raffreddamento per tenere conto dei cambiamenti stagionali nell’uso domestico era sostanzialmente rimandato il più possibile. Paradossalmente, anche essendo la tecnologia più complessa, questa rende la programmazione del riscaldamento d’inverno e del raffreddamento d’estate molto più facile con un termostato intelligente ma non solo perché non si deve seguire la regolazione della temperatura quotidiana, ma perché l’accesso avviene spesso dall’app e secondo le icone e i gesti che già conosciamo dall’uso del telefono mobile.
Insieme con l’apprendimento delle abitudini rispetto al rilevamento di movimenti della sensoristica, che automatizzano notevolmente la pianificazione delle esigenze di climatizzazione, è possibile subordinare anche il tempo meteorologico collegato su rilevamenti da siti internet, per poter raffreddare in anticipo e mantenere fresca una abitazione a fronte dell’arrivo di un’ondata di calore o riscaldarla di più quando si verifica un repentino fronte freddo.
Facilità di installazione e sostituzione
Purché si disponga del cablaggio corretto sul precedente termostato, sono sufficienti poche operazioni. In generale, si interrompe l’alimentazione del vecchio termostato, si rimuove il vecchio termostato, si collegano correttamente i cavi al nuovo termostato, si rimette una piastra frontale del termostato, e si ripristina l’alimentazione. I cavi altro non sono che: una coppia di fili che chiude il circuito della caldaia, tre fili di alimentazione (fase, neutro e terra), eventualmente un’altra coppia che chiude il circuito del raffreddamento. L’installazione di un termostato intelligente secondo le istruzioni del produttore riguarda poi il collegamento con il Wi-Fi casalingo con inserimento di password, e lo scaricamento di una app sul proprio smartphone con creazione di un account personale o più account per permettere ad altri membri della famiglia di poter intervenire autonomamente a questo punto si scaricano programmazioni standard da modificare o se ne inseriscono di nuove come richiesto e come descritto dalle apposite istruzione del produttore.
Il termostato Smart: la spia che venne dal freddo
Le persone che acquistano dispositivi Internet of Things (IoT), come i termostati smart e le telecamere di sicurezza, probabilmente non si rendono conto dei potenziali problemi che possono sorgere se i servizi si interrompono, rendendo impossibile mantenere una abitazione calda d’inverno o fresca d’estate. Né sono consapevoli del fatto che degli hacker potrebbero assumere il controllo di tutti i dispositivi collegati in rete assieme ad un termostato. Anche solo perché non si sono inserite password robuste (123456?), per non doverle poi riutilizzare o non saper impostare l’autenticazione a due fattori (2FA).
Le lezioni che ci pervengono da queste sperimentazioni “spensierate” sono piuttosto severe: c’è la famiglia che ha subito l’intrusione in una propria videocamera smart, e l’hacker che ha emesso falsi allarmi per missili balistici intercontinentali nordcoreani diretti negli Stati Uniti, poi c’è la coppia texana che, a dicembre, ha ascoltato falsi “sospiri sessuali” provenienti dal baby monitor installato nella cameretta del figlio di 4 mesi. La mamma, Ellen Rigney, ha riferito: “Quando abbiamo acceso la luce nella nostra stanza, abbiamo sentito la telecamera dirci di spegnere la luce e ha detto che avrebbe rapito il bambino – che era nella stanza del bambino” e, ovviamente e per fortuna, in realtà non c’era alcun rapitore nella stanza del bambino. Un’altra famiglia dell’Illinois ha detto alla NBC di aver sentito una voce maschile proveniente da una videocamera di sicurezza nella camera del bambino di 7 mesi. L’hacker non solo aveva preso il controllo della videocamera, ma aveva alzato a distanza il termostato smart a 32 gradi! Una società che possedeva 4.000 euro di prodotti IoT, tra cui 16 telecamere smart, due termostati smart e un intero sistema di sicurezza, ha dichiarato di non aver usato l’autenticazione a 2 fattori perché ignorava che l’opzione fosse presente e reclama che sia Google sia il costruttore lo avrebbero dovuto avvisare dell’opzione 2FA come anche “avvertirlo quando qualcun altro aveva avuto accesso al suo account”: in sostanza tutto si è risolto in un gioco di “scaricabarile” di colpevolizzazioni reciproche.
Per quanto riguarda i dispositivi esposti su internet che avevano subito esfiltrazioni da altri siti Web, Google ha dichiarato in proposito a questi incidenti che “Nest aveva ripristinato tutti gli account in cui i clienti hanno riutilizzato password precedentemente esposte a causa di violazioni su altri siti e che erano quini divenute reperibili pubblicamente. Anche se il termostato smart specifico non era stato violato, questi clienti erano comunque divenuti vulnerabili perché le loro credenziali erano liberamente disponibili su Internet. Ogni cliente ha ricevuto istruzioni su come stabilire nuove credenziali. Per una maggiore sicurezza delle password, stiamo impedendo ai clienti di utilizzare password che compaiono in elenchi compromessi noti. Come in precedenza, incoraggiamo tutti i clienti a utilizzare la verifica a due fattori per una maggiore sicurezza dell’account, anche se la password è compromessa.”
Valutare la sicurezza di una tecnologia IoT
Ma Nest è solo una marca di dispositivi IoT, una semplice goccia in un oceano in espansione di dispositivi “intelligenti”, molti dei quali hanno una sicurezza di qualità “patetica” specialmente quando (e sempre più) il termostato si collega anche ad altri dispositivi: almeno una caldaia e un climatizzatore, e sempre più spesso a valvole intelligenti con altre tecnologie trasmissive (Wifi, ZigBee, etc.) proprio perché , mentre il collegamento alla caldaia avviene attraverso una coppia fisica di fili di attivazione, esistono in commercio caldaie attivabili a distanza anch’esse attraverso WiFi e dunque via radio da parte del termostato, così come climatizzatori collegabili al WiFi per l’attivazione, la regolazione etc.
Questa rete di dispositivi climatici collegati in LAN, accedono poi come dicevamo alle informazioni meteo attingendo a siti web, oppure si collegano vocalmente agli Home Assistant per essere attivati con un comando vocale e pilotati da frasi del linguaggio parlato.
Valutare la sicurezza di una tecnologia IoT vuol dire evitare che – anziché un comodo dispositivo monitorato in rete – ci ritroviamo in azienda o in casa o in fabbrica, una altrettanto comoda porta di ingresso per accedere ai forni di produzione, ai codici della nostra carta di credito o alle casse del supermercato, da parte di hacker.
Anche per la sicurezza di un dispositivo semplice come un termometro che regola una variabile di stato come la temperatura di un ambiente, poiché costituito diverse componenti, queste dovranno comunque e ciascuna essere securizzate nativamente, “by default” e “by design” dal produttore stesso o da chi ci ha fornito l’apparecchiatura e proprio già fin dalle prime fasi di una valutazione all’acquisto, è sempre consigliabile prendere in considerazione il compito del device per capire in quali use-case di quel dispositivo si potrebbe dar luogo a pericolose vulnerabilità a cui le possibili minacce cyber sono associate ed evitarne dunque quei particolari usi o configurazioni.
Ad esempio, in una mappa dei rischi (costituita da rischio = probabilità x danno) se il mio dispositivo in rete sarà un termostato, un apri-cancello, una telecamera, un frigo connesso, una lavastoviglie o una lavatrice intelligente wireless, avrò probabilità diverse che un certo malfunzionamento si verifichi causato da malintenzionati, e in quel caso, un danno conseguente.
Un termostato smart non è (più) un unico dispositivo
Considerando un semplice termostato smart, occorre innanzitutto fare mente locale su quante e quali siano le componenti hardware del nostro gadget IoT. Sembra affar semplice, ma scomponendo il nostro termostato in diverse componenti, potremmo scoprire di avere a bordo dello stesso “chassis” diversi oggetti all’interno:
Vediamo quali interazioni prevede un termostato:
- se si compone di uno o più sensori e se si ha una intelligenza interna che stabilisce le relazioni tra i sensori
- sistema di grafica Lcd e di interazione locale attraverso tasti e ghiere
- un sistema bluetooth o wifi di collegamento con uno smartphone
- un sistema Wi-Fi di collegamento con un dispositivo Ip e dunque un suo indirizzo hardware (MAC).
- se ha una propria memoria di salvataggio del proprio stato o anche di altre variabili
- se stabilisce connessioni protette (vpn?)
- se si collega ad un server esterno unico o ad un cloud distribuito: un server di comando e controllo residente su Internet
- opzionalmente un web server secondario leggibile da browser
- opzionalmente una soluzione in cloud di gestione.
- alimentazione autonoma / batteria tampone
- gateway – se è connessa direttamente alla rete attraverso WiFi, o fa uso di un gateway di comando e controllo: presenza di un gateway di prossimità che centralizza le informazioni provenienti anche da altri dispositivi (valvole termostatiche per termosifoni, o sistema di condizionamento dell’aria, etc.)
- se il termostato o il gateway contengono protocolli e servizi applicativi (telnet, ftp, sftp, etc) e se le porte su cui questi lavorano sono “consuete” o sono state redirezionate.
Valutando questi singoli punti, scopriremo di avere a che fare con il novanta percento di complessità che accomunano tutti questi oggetti smart, ma che, nel tentativo di semplificarne l’uso e la user-experience, vengono non solo facilitate, ma anche estremamente semplificate fino al punto da metterne a rischio l’accesso.
Prendiamo un modello semplice di termostato che svolge il suo compito di monitoring continuo: quando la temperatura dell’appartamento scende troppo, accende la caldaia e se la temperatura dell’appartamento sale troppo, spegne la caldaia. Al massimo se abbiamo disabilitato queste funzioni perché siamo partiti per le Maldive e a casa nostra la temperatura scende sotto i 4 gradi, alcuni termostati prendono l’iniziativa di accendere la caldaia per facilitare il funzionamento del circuito ed evitare che si ghiaccino i tubi esterni, determinando fratture nell’impianto idraulico.
Proseguendo nell’analisi delle componenti, anche per il monitoraggio della temperatura esistono in commercio termostati multi-sensore. Questo vuol dire che sono integrati all’interno di strumenti ormai di poche decine di euro che rilevano il movimento di persone, la qualità dell’aria, la luce ultravioletta, l’umidità e la temperatura. Va da sé che per gestire questi dati, il chip del termostato deve differenziare il rilevamento ed avere eventualmente altri allarmi per condizioni-limite di queste variabili (umidità estrema=pioggia, qualità dell’aria inaccettabile=allarme fumo/gas, luminosità infrarossa eccessiva = allarme incendio, temperatura estremamente bassa=allarme ghiaccio, e altre condizioni di allarme che possono esserne una combinazione). Insomma: maggiore è il numero di sensori dei nostri dispositivi, più il software deve essere complesso e deve essere protetto contro situazioni miste che, se non immaginate correttamente a priori, by design, potrebbero porre il nostro termostato in uno stato di indecidibilità durante il quale diventa paradossalmente semplice sferrare attacchi informatici.
Condizioni di lavoro imprevedibili
Ad esempio – come vedremo più avanti quando sferreremo il nostro “attacco” – la progettazione potrebbe aver tralasciato situazioni-limite oppure averle escluse a priori. Il caso più semplice potrebbe essere la coesistenza in casa di hotspot e ripetitori wifi con lo stesso nome identificativo (“CasaDiLuca1988”) in cui il termostato esegue continuamente switch ridirezionando il traffico sul hotspot più vicino. Oppure il caso in cui per manutenzione della linea elettrica, indipendente dalle nostre case/aziende, sia mal gestito (senza un gruppo di continuità) e sottoponga continuamente i circuiti di alimentazione e dunque il dispositivo ad attacco-stacco della linea, anche a distanza ravvicinata inferiore al secondo (glitch); o ancora un mesh di valori di variabili in cui il programma all’interno del dispositivo non si blocca ma entra in uno stato indefinito non sapendo come risolvere una situazione; infine i casi in cui le responsabilità di una catena di comando termostato-caldaia-condutture vengano demandate senza una regolamentazione chiara. Prendiamo ad esempio il caso in cui venga a mancare l’erogazione del carburante in caldaia: chi dovrà effettuare il blocco del bruciatore? Il software di controllo del livello del serbatoio, spegnendo la caldaia e tutto il sistema? A quel punto, se non ci fosse una comunicazione tra serbatoio e termostato, questo farebbe attivare ugualmente il relè se la temperatura si abbassa perché la risoluzione del problema della mancanza di carburante (gas, gasolio, pellet, legna, etc.) è gerarchicamente demandato alla caldaia. Occuparsi dell’alimentazione del bruciatore della caldaia è compito della pompa, non del termostato, quindi esso continua a svolgere la funzione di comando e controllo dell’attivazione/disattivazione della caldaia.
Ora supponiamo che venga a mancare l’alimentazione al termostato: il termostato è in grado di riallinearsi automaticamente al ritorno dell’alimentazione generale? Attraversa per caso una routine di ripristino automatica o si resetta? Ricordo un tipo di IoT (luci regolabili) che al mancare dell’alimentazione resettava completamente i valori ricominciando a lavorare dalla massima luminosità, preimpostata. Questo voleva dire che, se l’alimentazione dell’abitazione veniva a mancare, al ritorno dell’alimentazione tutti i sistemi IoT dell’abitazione (in quel momento tutte le luci “soffuse”) si riaccendevano ripartendo dallo stato massimo dell’illuminazione, il risultato era sempre che durante la notte un leggero sbalzo di tensione resettava completamente i sistemi di regolazione dell’illuminazione e la casa si illuminava a giorno svegliando di soprassalto le persone (questa possibilità è oggi risolta e protetta dai gateway, che vedremo più avanti).
Le aggressioni ai termostati intelligenti
Se guardiamo agli attuali prodotti IoT e a come vengono progettati, abbiamo modo di osservare come gli accorgimenti di sicurezza, quando presenti, sono pensati a livello di applicazione e di rete. Questo vuol dire che i progettisti spesso trattano l’IoT e i vari dispositivi come dispositivi di rete standard (router, server, bilanciatori, firewall, etc.) e provano ad applicare le protezioni di sicurezza sviluppate per i normali dispositivi informatici di uso quotidiano. Difficilmente si va oltre l’autenticazione o la crittografia del firmware. La maggior parte degli IoT e dei dispositivi indossabili raccolgono informazioni sull’utilizzo e altri dati e li inviano a un fornitore di servizi, causando problemi di privacy. La piena divulgazione di ciò che viene raccolto è rara e tutto ciò che è effettivamente pubblicato è spesso nascosto nel legale che è le politiche sulla privacy e i termini dei servizi dell’unità.
La complessità dell’infrastruttura del termostato fornisce un terreno fertile per le vulnerabilità di sicurezza simile a quelle riscontrate in altri sistemi informatici. Per mitigare questo problema, Nest, ad esempio, firma gli aggiornamenti del firmware inviati al dispositivo. Tony Fadell, fondatore di Nest, ha affermato in un’intervista: “Abbiamo una sicurezza a livello bancario, crittografiamo gli aggiornamenti e abbiamo un team di hacker interno che verifica la sicurezza … [il termostato Nest] non decollerà mai se le persone non si fidano.”
Tuttavia l’infrastruttura hardware di alcuni termostati mancherebbe di un’adeguata protezione, consentendo agli aggressori di installare software dannoso nell’unità. Tramite una connessione USB, è stato dimostrato come bypassare la verifica del firmware effettuata dallo stack del software di alcuni termostati, ponendo le basi per alterare completamente il comportamento dell’unità.
Il termostato compromesso a quel punto fungerà da testa di ponte per attaccare altri nodi all’interno della rete locale. Bisogna anche considerare che qualsiasi informazione memorizzata all’interno dell’unità compromessa diventa disponibile per l’attaccante, che non deve più avere accesso fisico al dispositivo.
Si può utilizzare una vulnerabilità della sicurezza di alcuni termostati smart, prendendo di mira l’infrastruttura hardware e il confine hardware-software. A quel punto, un aggressore che padroneggia l’elettronica dell’hardware e del firmware interno (è sufficiente acquistare un dispositivo e smontarlo per scoprirne le caratteristiche intrinseche) può cambiare il processo di avvio del dispositivo per caricare firmware dannoso, aggirando efficacemente la verifica dell’aggiornamento del firmware effettuata dal produttore via software.
Privacy dell’utente
Il termostato raccoglie statistiche sull’utilizzo del dispositivo e dei dati ambientali e quindi “apprende” il comportamento dell’utente. Questo, oltre ad essere archiviato all’interno dell’unità viene trasmesso anche in Cloud quando il termostato viene collega alla rete internet, con le statistiche sull’utilizzo, ma anche i registri di sistema e i registri del software del termostato, che contengono informazioni come (a titolo di esempio) il codice postale dell’utente, le impostazioni del dispositivo, le impostazioni della caldaia, del climatizzatore e la configurazione della rete WiFi.
Panoramica dell’architettura
Una approfondita analisi di termostati come quelli nominati precedentemente (Nest, etc.) rivela che lo stesso termostato dispone di un codice per richiedere all’utente informazioni sul luogo di residenza o in ufficio. I rapporti indicano che il contratto privacy che si accetta può prevedere (controllare all’atto dell’installazione!) previo consenso (che deve essere esplicito visto che sono dati assoggettati a regolamento EU-GDPR) di condividere queste informazioni private con i fornitori (lo scopo dichiarato sarebbe il buon fine di generare energia in modo più efficiente).
Lo chassis di un termostato è normalmente diviso in due componenti: una piastra posteriore che si interfaccia direttamente con l’unità di condizionamento dell’aria e un pannello frontale con uno schermo, con dei pulsanti o un quadrante touch o rotante con – oltre al sensore di temperatura esterna coibentato in modo da non rilevare calore proveniente dall’elettronica del termostato o del visore LCD – eventuali sensori di movimento e umidità. Il sistema operativo è installato sull’HW contenuto nella scheda madre installata nel guscio contenente il corpo del termostato.
Le tecnologie a microcontrollore sono di tipo ARM (un Cortex-M3 nel caso del NEST) a basso assorbimento con memoria ram+flash (128 KB flash + 16 KB RAM). La comunicazione tra elementi del termostato avviane normalmente usando una comune interfaccia UART.
Il pannello frontale può contenere anch’esso un sistema a microprocessore di altra tecnologia, Texas Instruments (TI) (nel caso del Nest), 64 MiB di SDRAM, 2 Gibit (256 MiB) di flash ECC NAND, un modulo ZigBee e un modulo WiFi che supporta 802.11 b / g / n. La scheda per questo dispositivo del Nest offre anche un modulo di gestione dell’alimentazione TPS65921B di Texas Instruments con funzionalità HS USB.
Per un attacco ci si deve concentrare sul modulo che contiene la maggior parte dell’hardware e gestisce tutti i dati e gli input dell’utente.
Figura 1: Piastra frontale e posteriore del termostato (credit: Nest)
Accensione
In normali condizioni di accensione, il processore inizia a eseguire il codice nella sua ROM interna che inizializza le periferiche più basilari, incluso il General Purpose Memory Controller (GPMC), cerca il bootloader del primo stadio, esegue l’x-loader e lo inserisce nella SRAM. Al termine di questa operazione, il codice ROM passa il controllo a x-loader, che procede all’inizializzazione di altre periferiche e SDRAM. Successivamente, copia il bootloader del secondo stadio, u-boot, in SDRAM e procede a eseguirlo; u-boot procede con l’inizializzazione dei sottosistemi rimanenti ed esegue uImage con l’ambiente configurato terminato l’avvio, man mano che vengono eseguiti gli script di inizializzazione, vengono avviati i servizi culminando con il caricamento dello stack del software proprietario (nel caso analizzato quello della Nest Thermostat). La Figura 2 mostra il normale processo di avvio del dispositivo.
Figura 2: Processo di avvio (boot) standard di un termostato tipo Nest
Premessa all’attacco
Vedremo come abbiamo potuto analizzare dettagliatamente una struttura hardware di un Termostato Smart, grazie a questa analisi abbiamo identificato una backdoor: essa è associata al processo di avvio, che abbiamo scoperto essere molto debole, in quanto può essere sfruttata dagli aggressori per installare firmware dannoso. Poiché questo attacco è stato possibile prima che venisse caricata a bordo l’area utente, la verifica del firmware utilizzata non è stata in grado di rilevare e bloccare l’intrusione.
Il conseguente payload malevolo può consentire – una volta trasferito all’interno del dispositivo- di modellare il traffico di rete locale da parte degli aggressori da una postazione remota, compromettendo ulteriormente altri nodi della rete Lan in cui il termostato opera.
Reset all’accensione
Un esame più attento di questo processo comporta che, in alcune circostanze, è possibile avviare il processore da un dispositivo periferico, come Uart o Usb. Questo è il metodo più usato per inserire codice estraneo in tali dispositivi durante un reset dall’accensione (nota: alcuni modelli di termostati Smart, se il dispositivo si avvia da un reset all’accensione, la configurazione di avvio viene letta direttamente dai pin di avvio del sistema e agganciata al registro status control; altrimenti, la ROM cercherà nell’area di appoggio della SRAM una configurazione di avvio valida, e se ne trova una la utilizzerà, altrimenti ne costruirà una da dispositivi permanenti come configurato nei pin di avvio del sistema) e questo può essere fatto a monte, di tutto il processo, molto prima che la verifica del firmware possa essere attivata.
Il reset all’accensione – vale a dire un ripristino globale del dispositivo – può essere attivato premendo il pulsante come indicato nelle istruzioni per circa 10 secondi. Questo serve a mettere in “on” il pin di boot di sistema, innescando l’avvio periferico (e cioè come dicevamo Uart o Usb). È sufficiente cercare il pin di boot di sistema e, se è esposto direttamente in un punto della scheda del circuito principale, allora potrà essere utilizzata per attivare direttamente il comportamento di avvio Usb. Inotre se la ROM non esegue controlli crittografici del codice che viene caricato eseguirà liberamente il codice e consentirà il controllo totale del dispositivo. Ovviamente questo processo non funziona se non si rispettano dei vincoli: come una finestra temporale durante la quale la ROM ascolterà i dati del programma in entrata, inoltre il payload iniziale deve essere x-loader, che viene copiato in SRAM e deve inizializzare tutti i sottosistemi rimanenti. I payload successivi devono poter essere adattati ed eseguiti in SDRAM.
Il nostro attacco iniziale consisteva nell’invio di x-loader al dispositivo tramite l’avvio USB insieme a un’immagine di avvio personalizzata e un ramdisk con il nostro payload finale. Il nostro u-boot è stato configurato per l’avvio del kernel di bordo, utilizzando il ramdisk come filesystem di root iniziale che ci consente di installare automaticamente l’installazione di una backdoor del filesystem nel root del termostato.
Esiste in proposito un vecchio video dimostrativo un po’ datato ma esplicativo, di questa operazione.
Se riusciamo a fare in modo di vedere il Termostato Smart come un dispositivo di archiviazione di massa USB una volta avviato e collegato completamente a un PC, e a trattarlo come tale, potremo allora installare un server SSH sul dispositivo, e aggiunto un account utente arbitrario all’unità eseguendo le modifiche richieste in nella directory, e avere un ssh cioè un server shell sicuro in esecuzione all’interno del dispositivo fornisce facile accesso ad esso all’interno della rete locale su cui è installato il dispositivo, se poi la rete LAN (WiFi) è dietro un firewall NAT, che non consente l’accesso remoto senza l’intervento dell’utente, si può realizzare un software che rimane in esecuzione all’interno del termostato, attraverso la stessa backdoor, che tenta di connettersi a un server remoto nel web, e inoltrare un messaggio, dimostrando la possibilità fari diventare lo stesso termostato un dispositivo botnet.
A distanza e in locale
Ma come realizzare remotamente tutto ciò senza dover smontare il termostato del nostro amico, portare il device nel laboratorio e rimontarlo il giorno dopo?
- Sostituendolo con un modello uguale fisicamente e rimettendolo a posto il giorno dopo una volta iniettato il “nuovo” firmware che contiene un kernel personalizzato
- Installando il tutto a distanza, senza un kernel personalizzato (che però durerà lo spazio di un periodo, fino al prossimo aggiornamento)
Nel secondo caso, le case costruttrici (tutte) forniscono aggiornamenti periodici al firmware di ciascun modello di Termostato Smart, identificato da un preciso versioning. Poiché il programma di aggiornamento funziona come root, ha accesso completo al filesystem del dispositivo, il che significa che può tentare di eliminare il client backdoor che abbiamo presentato fin qui. Nel primo caso, di attacco fisico, iniettando un kernel personalizzato, possiamo inserire le nostre modifiche che proteggono il nostro software da eventuali aggiornamenti come root. L’installazione persistente di rootkit, resa possibile usando una allocazione “ramdisk” del nostro codice e un kernel Linux personalizzato scritto nell’unità, fa appunto in modo che il kernel Linux personalizzato verrebbe utilizzato per nascondere il software botnet, che può controllare a distanza il termostato, trasformandolo in testa di ponte per l’attaccante remoto. Consideriamo che controllare lo spazio del kernel significa che possiamo controllare tutti gli utenti: insomma che siamo in grado di distribuire un rootkit nel dispositivo quando e come lo desideriamo.
Quando e come attaccare
Durante il trasporto del termostato, in modo estremamente “facile”, durante l’implementazione in fabbrica, durante il montaggio da un attaccante che si finge un operatore termoidraulico “specializzato”, o da “chiunque” abbia accesso ad esso una volta montato e attivato, durante momenti insospettabili o in un luogo non sicuro. Questo tipo di compromissione non è cosa rara, se consideriamo non solo quello che può avvenire nelle nostre abitazioni, ma anche sui luoghi di lavoro, dove i termostati possono essere esposti “pubblicamente” per una regolazione individuale, o una camera di albergo o B&B il cui proprietario ha voluto aggiungere un tocco di automazione al comfort.
Che danni si possono fare?
Come mostrato sopra, il termostato diventa se compromesso, un “client di una botnet”, e il fatto stesso che si trovi in rete può essere utilizzato per introdurre servizi non autorizzati. Se una rete utilizza internamente il protocollo DHCP, il termostato può essere addirittura utilizzato come server DHCP. Quando un client in rete LAN tenta di risolvere un indirizzo IP utilizzando un server DNS per questo protocollo, si può fare in modo che il server risolva dapprima l’indirizzo attraverso la traduzione che ne fa il Termostato in quanto server DNS, avendo quindi il controllo su quali indirizzi vengono risolti e su quale IP. Si possono a quel punto falsificare i pacchetti di risoluzione di indirizzo (ARP) da mascherare come router, consentendo l’acquisizione del traffico da un computer target collegato in rete.
Inoltre attraverso la backdoor del termostato possono essere lette le credenziali della rete locale che stavolta, anche se possono essere cambiate dall’utente insospettito da una attività “irregolare”, poiché tali credenziali vengono comunque archiviate nel dispositivo, saranno sempre accessibili al nostro software client. L’estrazione di queste credenziali dal dispositivo implica che potremmo implementare altri dispositivi non autorizzati nella rete locale, modellando ulteriormente il traffico locale e scansionando le vulnerabilità sfruttabili che potrebbero avere altri dispositivi nella rete. Gli aggressori potranno sempre passare agevolmente dal Termostato Smart ad altri dispositivi sulla rete. Senza contare le abitudini human, poiché quello che una volta era un termostato con sensori movimento, è stato trasformato in una spia che non solo può riferire sulle attività informatiche in LAN e fornire una backdoor alla propria rete locale, ma che potrebbe passare informazioni sulle abitudini più o meno routinarie degli abitanti di una certa casa o ufficio, segnalando quando è vuoto, quando è in piena attività, quando si naviga di più su internet o a che ora viene generalmente scaricata la posta elettronica, se qualcuno accede ai social con quali credenziali memorizzate nel browser, etc.
To Hack or not to Hack? This is the privacy
Finora abbiamo visto interventi malevoli di intercettazione di informazioni, ma volendo vedere da un punto di vista white-hacking il lavoro di hackeraggio del Termostato, potremmo addirittura voler “richiedere” una modifica di un termostato smart. Quando? Ad esempio se volessimo montare un dispositivo termostatico intelligente, all’interno di una sala operativa, di un bunker, di un centro di ricerca, di un istituto di produzione brevetti proprietari, chiedendo al white-hacker di fare in modo che la summenzionata backdoor del Termostato, modificata, fornisca poi agli utenti legittimi un approccio che impedisce alla casa produttrice di raccogliere i propri dati personali senza il consenso e di estendere la funzionalità del dispositivo stesso.
Le soluzioni praticabili
Trust-Chain
Si chiama Trust-Chain o attendibilità concatenate o “catena di attendibilità” che poi è il concetto alla base della motivazione all’uso della blockchain. Al fine di stabilire una corretta catena di attendibilità, il dispositivo deve autenticare il codice che viene eseguito al suo interno dall’inizio. Ciò significa che il microprocessore deve autenticare il bootloader del primo stadio, in questo caso x-loader, che poi deve autenticare il codice che tenta di eseguire. Inoltre, qualsiasi codice eseguito nell’unità deve essere autenticato dal suo programma di avvio. L’avvio protetto autentica il bootloader del primo stadio con una chiave incorporata nell’unità di elaborazione principale. L’incorporazione delle chiavi all’interno di un dispositivo non è strana, è adottata da molti dispositivi consumer, come console di gioco e moderni personal computer con avvio sicuro basati su interfaccia firmware predefinita UEFI (appunto “Unified Extensible Firmware Interface”), che ha sostituito l’ambiente BIOS ma che è tuttavia retrocompatibile.
È imperativo, tuttavia, che queste chiavi rimangano in un luogo sicuro, al di fuori della portata dello stack software esterno del dispositivo se vengono utilizzati algoritmi simmetrici. Se si utilizzano algoritmi di verifica asimmetrici, quest’ultimo requisito perde di importanza importante.
La protezione delle aree utente
Ci sono due approcci principali a questo argomento.
Uno è caricare ed eseguire solo i binari firmati. Questo richiede che il kernel abbia un loader personalizzato che verifica questi binari prima che vengano eseguiti. Un altro approccio è crittografare il filesystem, in questo modo un utente malintenzionato non sarà in grado di modificarlo esternamente senza prima decodificarlo. Se si dovesse adottare quest’ultimo approccio, la decrittografia del filesystem deve essere eseguita runtime, all’interno del microprocessore. Poiché il processore deve essere personalizzato per supportare l’avvio sicuro, è possibile utilizzare un motore per eseguire la crittografia e la decrittazione runtime del file system per accelerare il processo. Inoltre, diventa necessario proteggere il canale tra microprocessore e SDRAM, poiché può anche essere attaccato quindi sarà necessario contrassegnare le pagine come eseguibili (nx flags) ed eseguire la crittografia runtime on the fly per le pagine. Ancora una volta, questa crittografia deve essere eseguita all’interno del microprocessore e deve essere trasparente per il software in modo non possa essere intercettato attraverso un vettore d’attacco quello illustrato all’inizio.
Chiedere al fornitore
Si può chiedere tuttavia al fornitore, presso i suoi canali di assistenza tecnica, la fornitura di core personalizzati con avvio sicuro come opzione, ma purtroppo non sono una soluzione standardizzata come protocollo, e non vale per tutte le marche.
Il fornitore ci chiederà di soddisfare per queste opzioni delle quantità minime di ordinativo di pezzi, aggiungendo sicuramente commissioni di installazione, che potrebbero indesiderabili per progetti di adozione di termostati smart per chi ha capitale limitato da investire nell’Internet-of-Things e un time to market da dover rispettare. Il produttore, è tenuto a collaborare, ai fini del successo della distribuzione sul mercato dei dispositivi, con il cliente prima dell’adozione di un qualunque sistema IoT sin dalla fase di montaggio, fin quando ormai il funzionamento è a regime, fornendo consigli e suggerimenti sull’installazione, che contrattualmente saranno da includere nell’accordo di fornitura.
Se come privati cittadini si possono acquistare tecnologie “off-the-shelf” attraverso le catene della grande distribuzione, da parte di una impresa è invece sempre auspicabile, ben prima di adottare una tecnologia, analizzare il dispositivo e, in caso di irreperibilità interna di competenze, far analizzare prima rapidamente il dispositivo e la soluzione che esso implica in un laboratorio terzo, di fiducia, per compiere tutte le operazioni di analisi del:
• firmware, con differenti architetture come RISC e MIPS associati al device,
• app mobile, eventualmente associate al device,
• protocolli di comunicazione, utilizzati dal device,
• test della dashboard web di controllo se presente,
• test dei protocolli applicativi classici basati su TCP/IP e delle porte utilizzate che tecnicamente possono avere luogo utilizzando tools e tecniche differenti in base al contesto.
In tale laboratorio, particolare attenzione sarà dedicata al reverse engineering del firmware, possibile solo se questo viene reso disponibile dal produttore su richiesta, perché farne un “dump” direttamente dall’hardware senza autorizzazione formale è illegale (a meno di una manleva nei casi industriali importanti, allorquando questa venga comunque concesso formalmente dal produttore già in fase di gara di fornitura, in quanto vincolo per l’adozione). Il divieto di disassemblare o fare reverse engineering del software, è indipendente dagli scopi indifferentemente che sia malevoli o nobili (quali quelli del white hacking).
Ad onor del vero, oltre ai termostati analizzati, crediamo che la maggior parte degli attuali dispositivi IoT (ma anche smartwatch o altri generi di wearable) soffra di problemi simili, mancando di un’adeguata protezione hardware per evitare attacchi di pari tipologia. Questo vale anche per eventuali moduli esterni al dispositivo, collegati mediante WiFi, ZigBee o altri standard che potrebbero includere backdoor in questi canali di comunicazione, esponendo anch’essi una superficie di attacco, almeno sotto certe condizioni.
Un modello dei rischi
Da questo punto di vista, quello che ci sembrava uno strumento di misurazione della temperatura che azionava una caldaia, è invece ora ridefinito giustamente come un sistema dalle molte componenti che può offrire diversi spunti di indagine su quanto le singole componenti siano “protette”. Le trasmissioni dei dati sulla App sul nostro smartphone intermediate da un server web, ad esempio, avvengono attraverso mediante una Virtual private network? Il server web espone le credenziali di accesso? E’ in https? E la nostra App sullo smartphone è stata scaricata da uno store che ne sancisce la qualità attraverso vincoli standard per la distribuzione ( Google Playstore o Apple AppStore)? Oppure abbiamo trovato nelle istruzioni di installazione un link a ad un DBServer generico raggiungibile attraverso QRCode che attiva il download in un package (Apk o IOs) non verificabile? Il nostro dispositivo mobile ha a bordo un antivirus/mobile protection che ne impedisce un data-breach?
Se il nostro dispositivo offre lo scenario di un danno sensibile in caso di manomissione, allora dovremo prevedere un vero e proprio modello di rischio prima di adottarlo, occorrerà cioè valutare tutte le caratteristiche precedentemente descritte immaginandole come possibili superfici di esposizione ad un ipotetico attacco su un ambiente industriale o aziendale.
Dovremo adottare una vera e propria metodologia mutuata dalla valutazione del rischio costituita dalle tre fasi di:
- Enumerazione degli entry point: vengono mappati tutti i possibili punti di ingresso della soluzione IoT. In questo modo si cerca di coprire quanto più possibile l’analisi delle varie componenti e di conseguenza i test da eseguire;
- Mappatura di un diagramma architetturale redatto dal punto di vista di un hacker, in base alle informazioni disponibili. Ciò consente di migliorare la comprensione della situazione di esposizione, delle relazioni di trust tra le varie componenti, dei processi di funzionamento e dei dati trattati;
- Test Checklist. Determinazione dei test da effettuare e ordinamento degli stessi in funzione di una priorità stabilita in base alle probabilità di exploitation per l’impatto generato (quindi il potenziale rischio associato) dividendo i test e raggruppando i risultati in “dispositivo in modalità Stand-alone”, e “Connected”, comprendendo anche la scheda di interfaccia wifi e il protocollo di comunicazione eventuale in LAN con il gateway.
Checklist di scelta e installazione
Nel caso della vendita di un medicinale, vorrei citare il foglietto illustrativo, la cui inclusione nella confezione implica oltre che posologia e indicazioni, anche l’elenco obbligatorio degli effetti indesiderati (anche gravi), con statistiche di precedenti, incluse per obbligo.
Lo stesso – lo sappiamo – non è necessario e non accade nell’adozione e spesso auto-somministrazione di tecnologie IoT e normalmente non abbiamo l’equivalente cautelativo. Quando però adottiamo un termostato, mutuando le stesse raccomandazioni precedenti, che – lo ricordiamo – valgono per ciascun oggetto IoT, si dovrebbe compilare un semplice Report dettagliato (più o meno quanto e come nel dettaglio di un foglietto illustrativo di un farmaco) che rechi che genere:
- che tipo di dispositivo è quello che stiamo installando, e cosa si limita a presidiare (la temperatura, una chiusura o apertura automatica, la sicurezza fisica, o altre variabili di stato) e cosa “non” fa: cioè quali task non dobbiamo aspettarci che vengano svolti e perché demandati ad altri dispositivi (ad esempio se il sistema non reca a bordo il protocollo vpn, se trasmette i dati in chiaro e che dunque demanda la encryption e mascheramento dell’ip ad altri sistemi che devono/possono essere presenti in LAN, l’assenza dei quali fa decadere alcuni parametri di sicurezza).
- che genere di effetti indesiderati può avere: (occupazione eccessiva di banda LAN, sovrapposizione di canali di trasmissione saturi, esposizione di entry-point wireless. etc.)
- restringerne l’impiego in un ambito specifico (“frigorifero 1 e 2” o “primo piano stanze da letto”) per un impiego specifico
- accertarsi di un recapito (email, telefono etc.) di rapida consultazione in caso di malfunzionamenti o sospetti di manomissione o comportamenti indesiderati.
- Dal momento in cui si adotta la caratteristica e il sistema termostatico, aggiornarsi sulle vulnerabilità note iscrivendo ad appositi canali tematici per una eventuale newsletter e pubblicazione di nuovo firmware che – è bene ricordarlo – deve essere facilmente aggiornabile.
- Procurarsi link multimediali a video (youtube) di dimostrazione e proof-of-concept per la corretta installazione
- Seguire thread o blog sul modello del termostato, elencando una serie di oggetti incompatibili che ne potrebbero causare il malfunzionamento (ad esempio in caso di punto Power Lan la presenza di trasmissione ad onde convogliate sulla linea elettrica, che si sovrapporrebbe ad altre preesistenti)
- Inoltre una data di scadenza della cybersecurity: ogni dispositivo dovrebbe avere obbligatoriamente una data di scadenza oltre la quale verrà segnalata la necessità di installazione di nuovo firmware oppure un aggiornamento automatico, non è sbagliato considerare che tecnologie installate in casa debbano essere rivalutate ed aggiornate dopo dieci anni (pensiamo l’introduzione di tecnologie degli ultimi 10 anni, come la fibra o il 5G, che hanno rivoluzionato i parametri di funzionamento dell’IoT, l’una con la larghezza di banda, l’altra che questa e il “network slicing”).
DVIoT (Damn Vulnerable IoT)
Una attenzione particolare va riservata al fai-da-te. Alcuni termostati connessi si possono autocostruire: esistono package preformattati, scaricabili da internet, che si installano su processori ARM comunemente disponibili su “Raspberry” o “Arduino”. Mentre per la seconda piattaforma occorre porre attenzione all’eventuale firmware degli shield a corredo (le schede aggiuntive che si “montano” sui pin terminali e funzionano non appena alimentati), per la prima l’usanza diffusa tra i “makers” di scaricare interi packages condivisi su internet e precompilati, da siti non ufficiali, è molto pericolosa e può fare la differenza nella sicurezza di questi dispositivi. Ciò è vivamente sconsigliato in caso di Do-It-Yourself: occorre invece prelevare il software sorgente dal sito ufficiale e compilarlo a bordo della piattaforma di adozione. Non bisogna scaricare nulla di “precompilato” da sedicenti “esperti”: potrebbe portare a bordo un trojan. Anche il maker più esperto deve avere una conoscenza intrinseca dell’hardware e del software che sta utilizzando o che intende usare: o lo si sa fare, o no, tertium non datur. Recentemente ho potuto verificare un software termostatico che, oltre a rilevare la temperatura, eseguiva inspiegabili trasmissioni periodiche verso un server sconosciuto.
Termostati Smart industriali
Innanzitutto sulla compatibilità con le leggi sulla salute, o sul consumo di CO2 che regolano gli ambienti monitorati. Un termostato industriale viene innanzitutto installato su celle frigorifere o altri sistemi per mantenere per i cibi o per i medicinali la catena del freddo. Essendo ambedue queste categorie direttamente relazionate alla salute delle persone, spesso le macchine frigorifere o gli ambienti ai quali vengono collegati questi dispositivi declinano responsabilità penali alimentari o sanitarie in caso di collegamento a termostati IoT, che vengono sempre interpretati come una manomissione facendo cessare automaticamente gli accordi sulla garanzia, rispetto a clausole accettate al momento dell’acquisto/installazione. Inoltre mentre per lo “storico” delle temperature casalinghe, non esiste una vera e propria necessità a parte la curiosità legata agli algoritmi migliori che garantiscano un più elevato risparmio energetico, la storia invece delle oscillazioni di temperatura può invalidare la commestibilità di un prodotto alimentare o determinarne la tossicità o nel caso di prodotti trasfusionali rendere impossibile salvare una vita. Per tali e tanti motivi, il termostato smart qui utilizzato dovrà non solo dare informazioni generiche sullo stato della temperatura o del differenziale di essa rispetto all’ambiente, ma sui tempi di mantenimento in caso di avaria energetica, allarmistica, ed eventuale segnalazione automatica di travalico degli standard di qualità imposti dal Ministero della Salute (quindi relativi a celle frigorifere per il plasma e medicinali, sale operatorie, incubatrici, ambienti controllati altamente critici).
Cyberwar Games
In questo articolo abbiamo trattato una tematica seria dell’IoT riguardante i termostati, che ha procurato precedentemente diverse effrazioni e databreach grazie all’intromissione dall’esterno di hacker. Il tema è serio e va molto oltre i toni allarmistici sensazionalistici di articoli pruriginosi sull’hacking, o sugli anatemi portati dall’innovazione tecnologica. In questi ed in altri articoli sull’IoT difficilmente troveremo approcci e veri e propri disclosure sui problemi portati da queste tecnologie.
Basta fare una ricerca sul sito shodan.io per rendersi conto delle potenzialità di un attacco hacker di questo tipo (provate a scrivere “Nest”, “Netatmo” o la stessa “Heatmiser” nella barra di ricerca), che allo stato attuale permetterebbe a un malintenzionato di entrare in centinaia di case, uffici, ospedali, scuole o industrie sparsi per il mondo.
Noterete che nella maggior parte di queste installazioni il problema non è nella tecnologia, ma nella pigra adozione di strumentazioni molto potenti che, per funzionare asservite ai nostri scopi, necessitano di un salto di qualità delle nostre competenze IT o, dovremmo dire in questo caso, sempre più IoT.
