Nelle ultime settimane è stata resa pubblica una vulnerabilità particolarmente importante riguardante “Slack” – applicazione di messaggistica e collaborazione con 10 milioni di utenti attivi giornalieri.
La notizia è passata abbastanza inosservata in Italia. Forse per non diffondere panico in un periodo già pesante per tutti, o anche perché la vulnerabilità è stata risolta e gli aggiornamenti rilasciati.
Ma sarebbe davvero il caso alzare un pochino il livello di consapevolezza pubblica sullo stato delle cose a favore di un sistema Paese più pronto nella gestione dei rischi digitali dato che tutti sono vulnerabili e nessuno è immune.
Il rischio
Il 27 Gennaio 2020, 7 mesi fa (esatto, sette mesi!), il ricercatore che ha identificato un problema critico di sicurezza ha inviato il suo report alla società Slack attraverso la piattaforma HackerOne. Tale Report è stato reso pubblico solo il 28 Agosto scorso ed è disponibile online.
In pratica, un malintenzionato a conoscenza di tale falla avrebbe potuto aver accesso a conversazioni, files e documenti condivisi dalla vittima senza che quest’ultima avesse notato nulla di strano. Gli Antivirus in queste situazioni non servono a molto.
Considerando che attraverso la messaggistica Slack, team in tutto il globo si scambiano idee tecniche, documenti interni, spesso informazioni riservate, ma anche chiavi a reti private o credenziali per accesso a databases (si spera solo di sistemi di testing) il problema è serio, anzi “era” serio. Lo è stato per almeno 7 mesi.
Inoltre, il ricercatore (oskarsv) ha fatto presente che le e-mail inviate al sistema di messaggistica venivano salvate in chiaro (cleartext) e che tale problemino avrebbe permesso di utilizzare i servers di Slack per il salvataggio di codice malevolo da riutilizzare o diffondere in un secondo momento.
Ciò che ha fatto scalpore in tale vicenda, sono stati diversi elementi. Oltre al fatto che la criticità fosse di alto livello, Slack ha gestito il report in modo molto lento (7 mesi sono un’eternità in questo settore), inoltre ha pagato il ricercatore solo $1.750, e cosa ancor più grave, ha pubblicato un articolo sul proprio blog – il 26 Agosto – descrivendo tale vulnerabilità come se l’avessero trovata e risolta internamente, senza citare il ricercatore originale. Questione poi rettificata, ma ha davvero fatto inorridire la comunità, che non ha risparmiato critiche su come sia stato gestito il processo da Gennaio ad oggi.
Esempi di utilizzo di falle di sicurezza di questo tipo sono facilmente collegabili allo spionaggio industriale.
Avere accesso a dati e sistemi interni fa gola a molti, e accedere alle postazioni degli sviluppatori che lavorano sulle prossime novità del mercato potrebbe garantire la sopravvivenza di alcuni e la fine di altri.
Il problema è molto serio, e le conseguenze a lungo termine potrebbero creare più danni di quel che si pensi.
Se i ricercatori informatici che dedicano competenze e ore del proprio tempo a cercare problemi (e soluzioni) al fine di renderle le applicazioni più sicure vengono maltrattati e sottopagati – per aver fatto la cosa giusta – non ci si meravigli quando exploit simili verranno pubblicati e venduti sui Marketplace nel dark-web. In quel caso i costi per tutti saranno ben superiori a 1.750 dollari.
Perché è così difficile rendere sicure le applicazioni?
Per diversi motivi, ma il più delle volte le cause non sono solo tecnologiche, bensì gestionali.
Uno su tutti è il “technical debt”, ovvero il costo di dover risistemare le cose a lavoro già completato avendo scelto come soluzione una scorciatoia invece che la strada “giusta” più adatta al contesto. Questo accade quando le richieste di rilascio di una nuova applicazione, o nuova funzionalità, sono poco realistiche o magari guidate solamente dalle pressioni commerciali invece che da un corretto programma di fattibilità tecnica.
Il problema è così noto e comune che esistono decine di libri su come evitare di accumularlo, e storie emblematiche di grandi società che hanno pagato il costo. Con l’avvento di iOS e Android, per esempio, la società Nokia è passata dal 50% di mercato mobile ad un mero 5% ed ha rischiato il fallimento. Principalmente per la poca agilità di sviluppo ed enorme technical debt (del sistema Symbian) che l’ha resa incapace di adeguarsi al nuovo mercato.
Oltre ai problemi commerciali e gestionali, sebbene in modo residuale, esiste un rischio latente dovuto a ricercatori e innovatori di cyber security che per competenze di alto livello identificano (oppure sviluppano su richiesta) vulnerabilità/attacchi di particolare complessità.
Tra i modi per affrontare queste minacce ci sarebbe il dare importanza alla sicurezza sin dalla fase di pianificazione (e non quando è troppo tardi), incentivare la formazione specialistica internazionale, mantenere attivi “Bug Bounty Programme”, pagare il giusto compenso ai ricercatori che riportano falle critiche, ed investire in formazione interna di qualità (non giusto per fare contento il dipartimento risorse umane).
Non è facile eliminare i rischi Cyber ma è plausibile mitigarli, magari concedere il giusto tempo agli sviluppatori di ripagare technical debt in applicazioni critiche ed istituire Penetration Tests regolari sarebbe un inizio.
