È stata rinominata Ripple20 la “collezione” di 19 vulnerabilità zero-day individuate in una piccola software library progettata negli Anni 90 da Treck, un’azienda americana di Cincinnati che aveva sviluppato questo stack TCP/IP ampiamente utilizzato e integrato in innumerevoli prodotti sia lato aziendale sia lato consumer negli ultimi 20 e più anni.
Questa scoperta mette ovviamente in dubbio la sicurezza di un numero di soluzioni hardware e software inimmaginabile.
Ma offre anche un interessante spunto di riflessione per tutti gli addetti ai lavori nel campo della sicurezza informatica. Quando pensiamo al mondo della cyber security spesso andiamo a guardare quello che gli inglesi definirebbero “the latest and greatest” in materia di vulnerabilità: quale nuovo e ingegnoso modo i criminal hacker hanno trovato per sottrarre dati, lanciare attacchi ransomware, corrompere dispositivi o quale criticità si nasconde nell’ultimo aggiornamento di un sistema operativo.
Ragionamento giusto, la cyber security deve essere predittiva e preventiva.
Ogni tanto, però, ci sono anche quelli che potremmo definire “i fantasmi del passato”, vulnerabilità figlie di un tempo in cui l’informatica era ancora in fase embrionale.
Nate in un periodo in cui non esisteva quasi neppure il concetto di security by design, queste rimangono “dormienti” anche per decenni. Ancora peggio, si nascondono in librerie e software che nel tempo diventano le fondamenta di tantissime altre soluzioni.
È proprio il caso delle zero-day contenute in Ripple20: sfruttandole, un aggressore potrebbe nascondere codice dannoso all’interno di dispositivi e mantenere la sua persistenza per anni, compromettere il funzionamento di un’intera linea di produzione… le possibilità di exploit sono veramente altissime.
Indice degli argomenti
Ripple20 e il rischio dell’effetto a catena
Il numero di device che hanno subìto un impatto è stimato in “centinaia di milioni” e comprende prodotti come:
- device per la domotica e la Smart Home;
- apparecchiature di controllo per le reti elettriche;
- sistemi IoT per l’Healthcare;
- attrezzature di controllo industriale;
- stampanti;
- router;
- apparecchiature per le comunicazioni mobile;
- dispositivi per data center;
- dispositivi per aerei di linea
e purtroppo l’elenco potrebbe essere ancora lungo.
Rischio ancor più amplificato se questi dispositivi vulnerabili venissero ricercati attivamente attraverso l’utilizzo dei Google Dorks, incrociando il nome dei brand a dei semplici comandi.
Il rischio, molto concreto adesso, è che oramai i prodotti in circolazione che utilizzano questa libreria siano talmente tanti e le Supply Chain a loro connessi così complesse che sarà praticamente impossibile pensare di patchare queste vulnerabilità in tempi rapidi.
I problemi nascono dal fatto che la libreria non è stata utilizzata solo dai fornitori, ma anche integrata in altre suite di software, il che significa che molte aziende non sono nemmeno consapevoli di usare questo particolare pezzo di codice.
Questo è uno degli impatti più interessanti di Ripple20: l’effetto a domino che potrebbe causare, appunto aumentato dalla cassa di risonanza della Supply Chain.
La libreria di software si è diffusa in lungo e in largo, al punto che rintracciarla è stata una grande sfida. Seguendo il percorso di distribuzione della libreria TCP/IP di Treck, JSOF la società che fatto la scoperta, ha portato alla luce come negli ultimi due decenni questo software di base per il networking si è diffuso in tutto il mondo, sia attraverso l’uso diretto sia indiretto.
È solo l’inizio
Ma la JSOF ha detto che il lavoro sull’identificazione di tutti i dispositivi vulnerabili non è ancora finito. I ricercatori hanno dichiarato di aver chiamato le 19 vulnerabilità Ripple20 non perché all’inizio erano 20, ma per l’effetto che causeranno nel panorama dell’IoT a partire dal 2020 e negli anni a venire.
I ricercatori dicono di aver solo scalfito la superficie per quanto si tratta di scoprire tutti i dispositivi che hanno implementato al loro interno la libreria TCP/IP di Treck e che molti fornitori di apparecchiature avranno bisogno di verificare il proprio codice in futuro.
Ripple20: cosa si rischia
Sebbene non tutte le vulnerabilità di Ripple20 siano gravi, ce ne sono alcune estremamente pericolose, che permettono agli aggressori di prendere il controllo dei sistemi vulnerabili da remoto.
Al momento, delle 19 CWE, quattro sono particolarmente degne di attenzione con uno score CVSSv3 superiore a 9.0.
Si tratta di:
- CVE-2020-11896 – CVSSv3 score: 10. Questa vulnerabilità può portare all’esecuzione remota del codice.
- CVE-2020-11897 – CVSSv3 score: 10. Questa vulnerabilità può comportare una possibile scrittura fuori campo.
- CVE-2020-11898 – CVSSv3 score: 9.8. Questa vulnerabilità può comportare l’esposizione di informazioni sensibili.
- CVE-2020-11899 – CVSSv3 score: 9.8. Questa vulnerabilità può consentire l’esposizione di informazioni sensibili.
L’exploit di queste vulnerabilità potrebbe portare a diversi scenari per chi si trova nel mirino dei criminal hacker.
Per esempio, un aggressore esterno alla rete potrebbe prendere il controllo di un dispositivo all’interno della rete bersaglio, se si trova esposto a internet o potrebbe infiltrarsi in una rete per colpire determinati dispositivi all’interno di essa.
Ma non solo, grazie a Ripple20 gruppi di APT potrebbero fare leva sulle vulnerabilità e ottenere permanenza all’interno dei sistemi delle aziende o enti governativi loro bersaglio.
Insomma, in tutti gli scenari, un aggressore può ottenere il controllo completo del dispositivo mirato a distanza, senza che sia necessaria alcuna interazione da parte dell’utente.
Ripple20: come difendersi
La prima e migliore attenuazione è l’aggiornamento alle versioni patchate di tutti i dispositivi.
Ovviamente, come accennato in apertura, se i dispositivi non possono essere aggiornati ancora, si raccomanda di procedere come segue:
- ridurre al minimo l’esposizione in rete per i dispositivi critici, mantenendola al minimo necessario e assicurando che questi non siano accessibili da Internet a meno che non siano assolutamente indispensabili;
- separare le reti OT e i dispositivi dietro i firewall e isolarli dalla rete aziendale;
- abilitare solo metodi di accesso remoto sicuro;
- bloccare il traffico IP anomalo;
- bloccare gli attacchi di rete tramite Ispezione approfondita dei pacchetti (nota anche come DPI o Deep Packet Inspection – la tecnica di elaborazione dati che controlla in dettaglio le informazioni che vengono trasmesse su una rete) per ridurre il rischio per i dispositivi Treck embedded TCP/IP abilitati.
Ovviamente, oltre a questi passaggi tecnici è fortemente consigliato portare avanti un’approfondita attività di risk assessment: compresi vulnerability assessment, penetration test e network scan.
