Ricerca ed analisi di vulnerabilit` a

Successivamente la documentazione consiglia di inserire un metodo di autenticazione basato su username e password per gestire i vari privilegi degli amministratori, degli utenti e di chi non ha accesso al sistema. Devono essere create delle credenziali associate ad una classe di privilegi che vengono poi salvate nel file settings.js. Dato che l’interfaccia della dashboard personale di SeismoCloud `e in fase di aggiornamento, la pagina che gestisce l’accesso alla parte privata di Node-RED `e lasciata ad un lavoro futuro (Sottocapitolo 5.3). Quindi, da qui in poi si assume che la parte di autenticazione `e sicura e dentro al sistema sono presenti solamente utenti Seismo-Cloud e non utenti non riconoscibili rispettando la buona pratica del Principio del privilegio minimo. Ovviamente `e una forte assunzione, ma il sistema Node-RED in questo caso viene uti-lizzato in un modo non previsto, perci`o nasconde molti errori di sicurezza che verranno esaminati meglio ed in dettaglio nei prossimi sottocapitoli.

4.2 Ricerca ed analisi di vulnerabilit` a

L’immagine Docker di Node-RED di default ha sei insiemi di nodi inseriti nella palette: common, function, network, sequence, parser, storage. A queste si sono aggiunte due categorie particolari per SeismoCloud: apiSeismoCloud e SeismometerData. Alcuni nodi gi`a installati all’interno dell’intefaccia sono stati considerati pericolosi. Come gi`a anticipato, gli utenti devono superare una fase di autenticazione, ma questi nodi vengono comunque considerati pericolosi per l’uso che ne potrebbe anche un utente di SeismoCloud. L’autenticazione certifica che l’utente appartiene effettivamente ad un gruppo, ma questo non esclude cattive intenzioni dello stesso. Ad esempio un nodo che `e stato considerato pericoloso `e il nodo exec. Questo nodo ha un parametro in input e restituisce tre output (Standard output, standard error e return code). Come si evince dal nome esegue comandi di sistema. In figura `e riportato un esempio di uso cattivo del nodo exec. In realt`a per`o, ci sono molti scenari pi`u pericolosi, come ad esempio l’utilizzo della macchina su

cui viene hostato il server come mittente dell’attacco e non come destinatario. Questo nodo fa parte della categoria function, l’unico considerato pericoloso di questa categoria. Gli altri sono:

udp, tcpin, websocket, httprequest, httpin, mqtt, httpproxy, tls, tail, file, watch. Si nota bene che molti sono protocolli di rete e sono stati rimossi per lo stesso motivo sopra. Possono essere utilizzati in modo maligno per fare richieste non consentite o effettuare qualche azione malevola con la rete attraverso il server. Gli altri (tail, file e watch) sono nodi della categoria storage e si occupano di leggere, modificare e salvare file. Anche questi nodi possono essere utilizzati da malintenzionati per leggere file sul server o creare codice da utilizzare in seguito.

Abbiamo visto che ci sono dei nodi che possono essere pericolosi se lasciati a completa disposizione dell’utente; togliendo questi nodi dalla palette, `e sicura l’interfaccia? No.

Infatti, Node-RED mette a disposizione nella sezione di impostazioni una funzionalit`a molto utile (ma pericolosa per il nostro scopo) che consente all’utente di installare nodi esterni che sono disponibili nel contenitore di repository pubblico (flows.nodered.org). In questo modo si pu`o ad esempio installare nodi come quello mostrato in figura che consente di eseguire codice Javascript.

Un altro problema potrebbe essere il typo-squatting. L’utente potrebbe voler scaricare ed installare un nodo utile, ad esempio node-red-contrib-alexa, ma sbaglia a digitare premendo una c al posto di una x, quindi il sistema gli suggerisce il nodo node-red-contrib-aleca, che invece potrebbe essere un nodo malevolo (chiunque pu`o caricare nodi sullo store ufficiale).

Figura 4.1: Installazione di un nodo esterno

Per quanto riguarda il nodo function, che appunto consente lo stesso di eseguire codice

Java-il modulo vm (di NodeJS) per creare una sandbox ed eseguire Java-il codice in maniera sicura [21].

Questa funzionalit`a nasconde comunque ancora altre criticit`a che verranno mostrate in maniera dettagliata in seguito.

Come abbiamo visto nel sottocapitolo 3.3, la procedura per comunicare con i sismometri ed il sistema SeismoCloud `e cambiata radicalmente favorendo l’usabilit`a e l’accessibilit`a a persone non tecnicamente competenti. I nodi che sono stati creati per comunicare attraverso il protocollo MQTT con SeismoCloud richiedono solamente il nome del nodo ed il nome del sismometro.

Durante la ricerca degli errori si `e scoperto un errore banale ma “fastidioso”. Era possibile infatti inserire un nome di un sismometro che non esisteva nel gruppo, cos`ı facendo veniva comunque creato un client MQTT e veniva messo in ascolto su un topic non esistente. Ovviamente la soluzione `e di seguire sempre il mantra mai fidarsi dell’input dell’utente. La risoluzione viene dettagliata nel prossimo sottocapitolo.

Per una veloce configurazione e deploy dei servizi si era scelto di utilizzare le variabili d’am-biente dei container Docker. In questo modo con poche parole chiave era possibile settare i container con i giusti parametri per i differenti gruppi. Per`o alcune delle variabili settate sono dati sensibili, ad esempio hostname, username e password del server MQTT. Queste infor-mazioni possono essere lette dall’interfaccia utente attraverso l’utilizzo del nodo Inject, oppure inserendo qualche riga di codice Javascript nel nodo Function.

1 msg . p a y l o a d = " ";

2 msg . p a y l o a d = msg . p a y l o a d + " API S E R V E R URL : " + env . get (" A P I _ S E R V E R _ U R L ") + "

\ n ";

3 msg . p a y l o a d = msg . p a y l o a d + " M Q T T S E R V E R : " + env . get (" M Q T T _ S E R V E R ") + " \ n "; 4 msg . p a y l o a d = msg . p a y l o a d + " M Q T T U S E R : " + env . get (" M Q T T _ U S E R ") + " \ n ";

5 msg . p a y l o a d = msg . p a y l o a d + " M Q T T P A S S : " + env . get (" M Q T T _ P A S S ") + " \ n ";

6 msg . p a y l o a d = msg . p a y l o a d + " M Q T T P I N N I N G C E R T : " + env . get (" M Q T T _ P I N N I N G _ C E R T

") ;

7 r e t u r n msg

Figura 4.2: Il nodo Inject pu`o restituire in output i valori delle variabili d’ambiente Come `e stato accennato nel capitolo 3, sono disponibili alcuni modi per inviare messaggi tra i vari nodi, uno di questi `e la condivisione di variabili con scope differente. Ci sono diversi scope:

node (visibili solo al nodo), flow (visibili solo ai nodi nello stesso flusso) e global (disponibili a tutto il sistema). Come si legge dallo studio Securing IoT apps in Node-RED di Olsson

[20], la quasi totalit`a dei nodi non utilizza variabili con scope globale o di flusso. Questo `e un bene perch´e l’utente si aspetta che i dati fluiscano in correlazione ai flussi visuali creati e non vengano scambiati tra i nodi in modo arbitario dalle azioni create. Comunque, l’interfaccia da la possibilit`a di leggere tutte le variabili d’ambiente disponibili (incluse quelle inserite per l’uso di SeismoCloud). Tra queste variabili sono presenti alcune che forniscono molte informazioni sul sistema in uso (ad esempio le varie versioni di Docker, Node-RED, npm, NodeJS...), sulla distribuzione dei file tra le varie cartelle e alcuni valori critici per la sicurezza (come ad esempio utente, password e hostname del server MQTT).

45 n p m _ c o n f i g _ n o d e _ v e r s i o n : " 12. XX . X "

Un ulteriore problema di sicurezza sono i canali di comunicazione. Abbiamo visto che Node-RED consiglia di utilizzare un certificato e una chiave per utilizzare HTTPS. Per`o anche se la connessione `e cifrata, questo non vuol dire che nessun malintenzionato pu`o comunicare con il server attraverso le API. Quindi si necessita di un metodo di autenticazione anche per le richieste verso il server API.

Inoltre, `e stato argomentato come utilizzare HTTPS per cifrare i dati senza usare il meno sicuro HTTP, ma il sistema utilizza MQTT che invia dati in chiaro sui canali di comunicazio-ne. Per una connessione pi`u sicura `e necessario un metodo di cifratura dei messaggi anche sul protocollo MQTT.