Ogni tanto una vulnerabilità esce dai bollettini tecnici e finisce sui giornali. Succede quando colpisce un software usato quasi ovunque, o quando le sue conseguenze diventano evidenti a tutti. Ripercorrere alcune di queste falle famose non serve a fare paura: serve a capire che gli stessi errori si ripetono, e che le lezioni valgono anche per un piccolo sito WordPress o un negozio PrestaShop. Ne raccontiamo alcune, senza dettagli tecnici, con quello che ci hanno insegnato.
Heartbleed (2014): il componente invisibile
Nel 2014 venne scoperta una falla in OpenSSL, la libreria che milioni di server usavano (e usano) per le connessioni cifrate, quelle con il lucchetto nel browser. Permetteva a chi attaccava di leggere piccoli pezzi della memoria del server, che potevano contenere password, dati di sessione e perfino le chiavi segrete dei certificati. Fu una delle prime falle ad avere un nome, un logo e una pagina dedicata.
La lezione: molti amministratori scoprirono in quei giorni di usare un componente di cui ignoravano l’esistenza. Il software moderno è fatto di strati, e una falla in uno strato profondo colpisce tutto ciò che c’è sopra. Vale anche per i plugin che includono librerie di terzi. E dopo la correzione non bastava aggiornare: bisognava anche cambiare certificati e password, perché potevano essere già stati letti.
Shellshock (2014): il difetto vecchio di decenni
Pochi mesi dopo toccò a Bash, l’interprete di comandi presente su quasi tutti i sistemi Linux e Unix. Il difetto era nel codice da moltissimi anni, ma nessuno se n’era accorto. In certe configurazioni dei server web permetteva di eseguire comandi da remoto. Alla prima correzione ne seguirono altre, perché analizzando il problema ne emersero di collegati.
La lezione: un codice vecchio e stabile non è per forza un codice sicuro. E la prima patch non è sempre l’ultima: dopo una falla grave conviene aspettarsi altri aggiornamenti nei giorni successivi, e installarli.
La falla che non fu corretta in tempo (2017)
Nel 2017 una grande agenzia statunitense di informazioni creditizie subì il furto dei dati di decine di milioni di persone. Gli attaccanti entrarono sfruttando una falla in Apache Struts, un framework per applicazioni web, per cui la correzione era già disponibile da settimane. Semplicemente, non era stata installata su un sistema.
La lezione: è forse la più importante di tutte. Il disastro non arrivò da una falla sconosciuta, ma da una falla nota e già corretta. La maggior parte degli attacchi funziona così: falle pubbliche contro sistemi non aggiornati.
WannaCry (2017): il ransomware che correva da solo
Sempre nel 2017 il ransomware WannaCry bloccò in pochi giorni centinaia di migliaia di computer in tutto il mondo, compresi ospedali e grandi aziende, cifrando i file e chiedendo un riscatto. Si propagava da solo sfruttando una falla di Windows nella condivisione di file in rete. Microsoft aveva pubblicato la correzione circa due mesi prima.
La lezione: gli attacchi automatici non scelgono le vittime, colpiscono chiunque sia esposto. E in quei giorni chi aveva backup separati e funzionanti poté ripartire; chi non li aveva dovette scegliere fra perdere i dati e pagare. È lo stesso motivo per cui sui nostri servizi i backup hanno anche una copia cifrata fuori sede.
Drupalgeddon 2 (2018): la corsa contro il tempo
Nel 2018 il progetto Drupal, un CMS molto diffuso, annunciò con qualche giorno di anticipo il rilascio di una correzione critica, invitando tutti a tenersi pronti. La falla permetteva di prendere il controllo dei siti da remoto. Dopo la pubblicazione, nel giro di poco tempo comparvero dimostrazioni pubbliche e subito dopo attacchi automatici su larga scala, che installavano programmi per minare criptovalute e porte di servizio.
La lezione: per un CMS, la finestra fra la pubblicazione di una falla grave e gli attacchi di massa può essere molto breve. Chi aggiornò subito fu al sicuro; chi aspettò la manutenzione del mese successivo spesso trovò il sito già compromesso.
Log4Shell (2021): ovunque, senza saperlo
A dicembre 2021 venne pubblicata una falla in Log4j, una libreria Java usata per scrivere i registri delle applicazioni. Ricevette il punteggio di gravità massimo, 10 su 10. Il problema era la sua diffusione: Log4j era incluso in una quantità enorme di prodotti, spesso in profondità, e molte organizzazioni passarono settimane solo a capire dove fosse. Gli attacchi iniziarono quasi subito.
La lezione: sapere cosa si ha installato è metà della difesa. E quando la correzione non si può installare subito ovunque, servono protezioni temporanee che fermino i tentativi di attacco mentre si aggiorna: filtri davanti alle applicazioni, quelle che oggi si chiamano patch virtuali.
E i plugin di WordPress?
Nel mondo WordPress non c’è un singolo caso simbolo, ma una storia che si ripete: plugin molto diffusi (per moduli di contatto, costruttori di pagine, gestione file, SEO) in cui viene scoperta una falla grave, una correzione rilasciata in fretta e, nei giorni seguenti, ondate di attacchi automatici contro i siti rimasti indietro. Ogni volta, a essere colpiti sono quasi sempre i siti non aggiornati, oppure quelli con plugin abbandonati.
Cosa ci hanno insegnato, tutte insieme
- Le falle sfruttate sono quasi sempre note. Aggiornare resta la difesa principale.
- Il tempo conta. Fra la pubblicazione e gli attacchi di massa possono passare pochi giorni, a volte meno.
- Bisogna sapere cosa si ha. Un inventario dei componenti trasforma il panico in una lista di cose da fare.
- Servono protezioni per i giorni critici. Filtri mirati coprono il tempo che serve ad aggiornare.
- Dopo una compromissione, la patch non basta. Vanno cambiate le credenziali e verificato che non siano rimaste porte di servizio.
- I backup sono l’ultima rete. Separati, frequenti e verificati.
Come applichiamo queste lezioni
La nostra Gestione vulnerabilità nasce proprio da qui: ogni notte confronta il software installato davvero sui server e nei siti con le banche dati delle vulnerabilità note, le falle gravi arrivano subito allo staff e, quando serve, Security Intelligence applica una protezione mirata anche prima della correzione ufficiale. Intanto cPGuard sorveglia file e database e JetBackup conserva le copie. A te resta la parte che nessuna protezione sostituisce: aggiornare.