Internet delle Cose e la questione sicurezza

Hobart Linuxconf.au

Un particolare della home page dedicata alla conferenza

Tra il 16 ed il 20 gennaio si è svolta ad Hobart (Australia) la conferenza linux.conf.au, evento nel quale si è parlato prevedibilmente di svariati argomenti riguardanti Linux ed il mondo del software open source e gratuito. Tra i tanti temi non poteva certamente mancare l’attacco DDoS da record (oltre 700Gbps, alcuni ipotizzano 1Tbps) lanciato contro DYN lo scorso 21 ottobre 2016.

Christopher Biggs, sviluppatore di sistemi integrati e consulente, ha introdotto la sessione di lavori e confronto dedicata proprio alla sempre attuale questione sicurezza. Prima di riportarne i passaggi più significativi è il caso di ricordare quanto accaduto a DYN. In base alle informazioni rivelate dalla stessa azienda, l’infrastruttura del provider sarebbe stata raggiunta da un flusso di dati fuori scala generato grazie all’aiuto “involontario” di migliaia di dispositivi IoT (Internet delle Cose), nello specifico telecamere di sorveglianza connesse alla rete sviluppate dall’azienda cinese Hangzhou Xiongmai Technology.

Per “reclutare” circa 500.000 dispositivi, gli hacker avrebbero utilizzato Mirai, un malware che mediante semplici tecniche brute force è riuscito a superare le difese dei device indovinandone le credenziali di accesso. L’inadeguatezza delle interfacce grafiche e dei sistemi di sicurezza utilizzati dalla quasi totalità dei dispositivi IoT sarà, come vedremo nel paragrafo successivo, uno dei punti maggiormente criticati dal relatore.

Standard di sicurezza e sviluppatori disattenti

E’ una delle amare conclusioni alle quali giunge Christopher Biggs supportato dal collega Tom Eastman. Nella presentazioni si parla anche di standard/pratiche di sicurezza, la cui attuale situazione è giudicata preoccupante –  e dovrebbe destare alcune preoccupazioni presso la comunità di addetti ai lavori e non. I toni utilizzati dai due presentatori sono forse troppo allarmistici ma colgono perfettamente il cuore del problema.

L’IoT, afferma Briggs, è una sorta di “pacchetto completo” di rischi: un malintenzionato potrebbe ad esempio assumere il controllo di una telecamera per spiare (stalking) la propria vittima o per registrare video e ricattare quest’ultima. Le opportunità per raccogliere ingenti quantità di dati sono elevate, prosegue.

“State invitando in casa vostra o in ufficio un dispositivo del quale non avete assolutamente alcun controllo. Non avete idea degli eventuali rischi ai quali potrebbe esporvi. E non avete la possibilità di aggiornarne il software”, ha affermato Eastman.

“I mostri sono nella stanza. Se i dispositivi IoT utilizzano servizi cloud, c’è il rischio che questi ultimi possano essere compromessi… molti dispositivi sul mercato sono difficili da installare, hanno interfacce utente di bassa qualità e non offrono possibilità di manutenzione”.

In questo contesto i firewall, aggiunge, si rivelano spesso inutili e per ovvie ragioni: si tratta infatti di soluzioni studiate per bloccare il traffico proveniente dall’esterno; e nel caso in cui l’UPnP non sia stato disattivato, i device saranno in grado di aprire senza problemi qualsiasi porta.

Anche chi si occupa di progettare dispositivi intelligenti (dal device stesso all’OS/interfaccia) ha la propria parte di responsabilità. Troppo spesso, osserva Briggs, ci si dimentica dell’utente finale: “nella maggior parte dei casi sul dispositivo non è indicato alcun produttore. Se c’è un bug, probabilmente non ne sarai a conoscenza. In caso contrario, non ci sarà probabilmente alcuna patch. E nel caso in cui tu ti voglia lamentare, probabilmente non ci sarà nessuno al quale importerà”.

Noi stessi sviluppatori, fanatici della tecnologia (geek), dobbiamo pensare a strumenti in grado di essere utilizzati senza problemi dall’utente finale, sottolinea Briggs.

Un mercato ancora immaturo

Ed a proposito di geek, i relatori bollano sostanzialmente come immaturo il mercato dell’IoT: allo stato attuale quest’ultimo è chiaramente geek friendly. L’utente finale deve ancora guadagnare il proprio spazio ed attenzione. Troppo spesso si installano nei dispositivi varianti avanzate di Linux in grado di aumentare esponenzialmente i fattori di rischio (threat surface):

“è facile installare una distribuzione Linux completa sul dispositivo senza occuparsi di ridurne i fattori di rischio. [In effetti, per quanto riguardo l’OS e le semplici applicazioni in ambito IoT, a volte sarebbe meglio rivolgersi ad altre soluzioni piuttosto che a Linux]”.

E purtroppo non si cerca di cambiare la situazione, semplicemente perchè non vi sono motivazioni/incentivi per fare meglio: “se all’acquirente finale non importa la questione, il vendor non la prenderà in considerazione “. 

Alcuni consigli per gli utenti finali e gli sviluppatori

Nel corso della presentazione si è parlato anche di buone norme da seguire. Briggs si è rivolto sia agli acquirenti di dispositivi intelligenti che agli addetti ai lavori. Ai primi ha consigliato:

  • di prestare attenzione a dispositivi sconosciuti e reti Wi-Fi sconosciute;
  • di effettuare una scansione delle porte dei device sconosciuti in modo da capire quali servizi possano essere eseguiti;
  • non utilizzare dispositivi che mettano a rischio il sistema, come ad esempio l’esecuzione di software non attendibile;
  • prediligere dispositivi che supportano protocolli standard o dispongono di una buona documentazione API;
  • creare una rete separata e dedicata ai soli device.

I dispositivi che si appoggiano ai più noti framework del mercato (sviluppati da Microsoft, Google etc.) espongono sempre i firewall ad alcuni rischi ma, aggiunge, sono sempre meglio della “spazzatura” che si trova in giro. Per quanto riguarda le indicazioni ai colleghi sviluppatori ed in generale a chi opera nel settore dell’Internet delle Cose:

  • è preferibile utilizzare framework popolari e ben supportati;
  • anche i framework open source andrebbero in ogni caso tenuti d’occhio, in particolare modo i progetti della Open Connectivity Foundation;
  • è sempre il caso di fornire anche delle API e non limitare la configurazione del device alle sole app mobile;
  • stabilire in anticipo il ciclo di vita del device e la relativa durata del supporto offerto;
  • dare sempre la possibilità all’utente di disattivare particolari funzioni di alto livello nel caso in cui si presenti un rischio per la sicurezza;
  • i dispositivi IoT sono diversi dai PC, è quindi opportuno limitare il software che si intende caricare al loro interno.

Fonte