Quando gli errori del software mettono a rischio la sicurezza dei nostri dati allora si parla di vulnerabilità informatica del software e bisogna fare molta attenzione (posto che non esiste il software perfetto, senza errori – bug e che non si blocca mai).
In particolare, si parla di “vulnerabilità di sicurezza” quando ci si trova di fronte ad un problema del software di cui è stato scoperto un metodo (exploit) per sfruttarlo a vantaggio dell’attaccante; in assenza di strumenti di attacco e di valore per l’hacker attaccante siamo in presenza di un “normale” bug.
Le vulnerabilità di sicurezza hanno un loro ciclo di vita che è giusto conoscere per capire quali possono essere le migliori strategie di difesa.
Il grafico ci aiuta a percorrere i livelli di criticità attraversati da una vulnerabilità (Fonte: OWASP)
Indice degli argomenti
Vulnerabilità informatica: una definizione
Il pericolo comincia nel momento in cui una vulnerabilità viene scoperta (A). Supponiamo che qualcuno si accorga che, ad esempio, cliccando una sequenza di icone sui siti web realizzati con il software “SitiWebMeravigliosi” (nome di fantasia, ovviamente) si possa avere accesso a dati riservati degli altri utenti.
Se il primo ad accorgersene è una brava persona, in buona fede, magari comincia a parlare della cosa in rete, per capire se è solo un suo problema o se invece capita anche ad altri. Succede così che la vulnerabilità viene resa pubblica (B) e magari dopo un po’ la impara anche la “MioCuginoInformatica” che ha scritto il software “SitiWebMeravigliosi” (C).
Potrebbe anche andare diversamente ma questo lo vedremo in seguito.
Software vulnerabile: l’importanza degli aggiornamenti
La “MioCuginoInformatica” mette subito in guardia gli utilizzatori del proprio software (D) e si mette alacremente all’opera per scrivere e testare la correzione che risolve il problema e mette una “pezza” (la cosiddetta patch) alla vulnerabilità informatica individuata. Il livello di pericolosità è ancora alto, come si vede dalla figura, perché il buco c’è e i cattivi (hacker e virus) se ne possono tranquillamente approfittare.
I produttori di sistemi di sicurezza potrebbero provare a limitare i danni cercando di filtrare la sequenza di tasti dannosa sui siti difettosi ma è una toppa che non rimedia al buco che rimane pericoloso (E). La “MioCuginoInformatica” trova la soluzione al problema e prepara la correzione del software (F) ma la vulnerabilità rimane critica perché prima bisogna che tutti gli utenti imparino che esiste questa soluzione (G).
Ovviamente non è sufficiente che la correzione sia disponibile sul sito del produttore, deve essere effettivamente installata da tutti (H) affinché il problema possa essere considerato risolto e la vulnerabilità informatica definitivamente risolta.
Purtroppo, l’esperienza ci insegna che gli utenti non sono sempre reattivi quando si tratta di installare le correzioni del software (“no, un altro aggiornamento, mi bloccherà il computer per chissà quanto tempo, ci penserò domani”).
Soltanto quando tutti gli utenti del mondo avranno installato la correzione potremo dire che il pericolo di questa vulnerabilità informatica sarà finito… e potremo cominciare a preoccuparci della successiva.
Full disclosure: la soluzione alle vulnerabilità informatiche
Ma se la “MioCuginoInformatica” fa finta di niente e non reagisce alla mia segnalazione? Purtroppo, succede e qui si apre il dibattito sul tema della “Full disclosure” come filosofia. Supponiamo che io sia un bravo ragazzo che ha trovato una vulnerabilità informatica in un software, lo comunico al produttore poi aspetto che lui reagisca, e passa il tempo, e più il tempo passa più aumenta il rischio che un ragazzo cattivo trovi lo stesso problema e decida di fare dei danni in giro per Internet. Allora meglio forzare la mano e rendere tutto pubblico subito in modo che il produttore sia costretto a reagire in tempi più brevi per non veder danneggiata la sua immagine (e le sue vendite), ma così anche i cattivi lo imparano tutti subito.
Non è un problema banale.
Molte aziende hanno programmi di “bug bounting” per premiare chi segnala in modo riservato i problemi di sicurezza dei loro prodotti impegnandosi a risolvere il bug il più rapidamente possibile. Normalmente in questi casi sono previsti incentivi economici: tanti più soldi quanto più il problema è serio e relativo ad un software di grande diffusione.
Altre aziende invece vedono la correzione dei bug come un costo esterno, senza nessun valore, e cercano di nascondere il problema fra le pieghe della rete (è il concetto dell’inquinamento, se non ho responsabilità sociale mettere i filtri al mio impianto è solo un costo accessorio che non aggiunge valore al mio prodotto, i buchi di sicurezza sono l’inquinamento del software).
Differenza tra vulnerabilità e minaccia
Spesso si confonde il concetto di vulnerabilità con quello di minaccia; se il primo caso è stato ben espresso in precedenza, la minaccia è colui che sfrutta la vulnerabilità per creare un danno al sistema. Di conseguenza è la minaccia che, sfruttando la vulnerabilità, genera una conseguenza nefasta per il sistema.
Vulnerabilità “Zero day”: cos’è e come si risolve
Poi ci sono le vulnerabilità informatiche cosiddette “zero day”, quelle trovate dai cattivi e tenute nascoste per poter poi esser rivendute al miglior offerente nel Dark Web. Conoscere una vulnerabilità “Zero day” di un prodotto diffuso fornisce un potentissimo strumento di attacco contro tutti gli utilizzatori di quel software. Un’arma che rimane valida e potente finché qualcuno non la scopre (magari da giocarsi bene per evitare di bruciarla). Vulnerabilità “Zero day” di Acrobat Reader, ad esempio, sono state sfruttate per diffondere ransomware tramite file PDF allegati alle e-mail.
Esiste un mercato fiorente di queste vulnerabilità informatiche, anche le agenzie governative le hanno sfruttate per le loro operazioni come segnalato da WikiLeaks.
Ma il software che sto usando ha vulnerabilità note?
Man mano che le vulnerabilità vengono rese note c’è qualcuno che si impegna a raccogliere tutte le informazioni utili (versioni del software impattate, problemi potenziali, soluzioni temporanee ecc.) e le inserisce in un database assegnando ad ognuna un identificatore univoco per evitare di duplicare le informazioni.
Il database principale è quello del Mitre. I dati del Mitre vengono utilizzati come punto di partenza per le analisi più dettagliate dell’U.S. National Vulnerability Database i cui record contengono ulteriori elementi come, ad esempio, il livello di rischio e di impatto di ogni vulnerabilità.
A livello aziendale esistono strumenti semiautomatici per fare il Vulnerability assessment, cioè la verifica di non avere delle vulnerabilità informatiche nelle applicazioni sfruttabili da hacker cattivi e virus. La parte automatica di questi strumenti genera spesso falsi positivi e, ancora più grave, falsi negativi a causa della complessità dei sistemi sotto analisi. Nessun “Vulnerability assessment” aziendale potrà dirsi completo senza una verifica del fatto che una vulnerabilità informatica sia effettivamente sfruttabile dall’attaccante (exploitation) e senza una verifica di cosa si trovi davanti l’attaccante dopo aver sfruttato la vulnerabilità (difficilmente riscontrabile con strumenti standard che non tengono conto delle diverse implementazioni aziendali).
Strumenti di difesa: riconoscere e isolare il software vulnerabile
Come ci si può difendere dalle vulnerabilità di sicurezza?
Ragionando a livello di utente finale la prima arma di difesa è ovviamente l’applicazione di tutte le correzioni di sicurezza appena escono.
A livello aziendale è un tema più complesso visto che il processo di applicazione delle correzioni (patching) si inserisce in un discorso più ampio di gestione del software che richiede una trattazione a sé stante.
Negli ambiti personali, o nelle strutture molto semplici, aggiornare sempre tutti i software applicando le correzioni di sicurezza è la difesa base, ma purtroppo viene applicata raramente. Anche in questi casi bisogna ovviamente avere a disposizione salvataggi recenti e funzionanti nel caso le correzioni creassero problemi.
E se la correzione non c’è come ci si deve comportare?
Se siamo certi che la vulnerabilità di sicurezza non verrà mai corretta perché magari il produttore del software non esiste più oppure ha dichiarato che non correggerà il problema (ad esempio Microsoft che ha sospeso la produzione delle correzioni di sicurezza per Windows XP) allora bisogna mettere una mano sul cuore e una sul portafoglio e abbandonare il software vulnerabile passando ad uno più recente o meno insicuro.
E dagli “Zero day” come ci si può difendere?
Tecnicamente non c’è difesa, perché il buco di sicurezza è lì che attende solo di essere attaccato e non c’è antivirus che possa prevenirlo visto che non è noto nemmeno ai produttori. Si può cercare di ridurre i danni adottando una condotta prudente e di buon senso nell’uso dei computer e della rete: disinstallare tutti i software e le applicazioni non strettamente necessari (quello che non c’è non è attaccabile), evitare di scaricare allegati/programmi che possano avviare software sul proprio PC, insospettirsi a fronte di comportamenti anomali del proprio PC o dello smartphone (picchi di carico, dischi che girano senza motivo, processi strani che appaiono nel sistema ecc.). Tutte buone pratiche atte però solamente a mitigare il rischio.
