Articolo Pubblicazioni
Heartbleed (2014): il bug di OpenSSL e la fragilità del software open source critico
di Vincenzo Calabrò · Pubblicato il 5 maggio 2014
Abstract
Il 7 aprile 2014 è stata resa pubblica una vulnerabilità nella libreria OpenSSL, usata da una larga parte dei server web per le connessioni cifrate. Il difetto permette a chiunque di leggere porzioni della memoria del server, che possono contenere chiavi private, password e cookie di sessione. L’articolo spiega il meccanismo, le azioni necessarie per rimediare e le domande che il caso pone sulla sicurezza dei componenti open source da cui dipendono servizi critici.
Che cosa è successo
OpenSSL è la libreria open source più diffusa per implementare i protocolli SSL e TLS, che proteggono le connessioni HTTPS, la posta elettronica cifrata, molte VPN e innumerevoli applicazioni. Il 7 aprile 2014 il progetto ha pubblicato un avviso e una versione correttiva per una vulnerabilità identificata come CVE-2014-0160 e subito chiamata Heartbleed, con un logo e un sito dedicati. La scoperta è stata fatta in modo indipendente da un ricercatore di Google e da un’azienda finlandese di sicurezza, Codenomicon.
Le versioni vulnerabili sono quelle dalla 1.0.1 alla 1.0.1f, pubblicate a partire dal marzo 2012. La versione 1.0.1g corregge il problema. Le versioni precedenti, 1.0.0 e 0.9.8, non sono colpite.
Il meccanismo
L’estensione heartbeat del protocollo TLS, descritta nella RFC 6520, serve a verificare che l’altra parte della connessione sia ancora attiva senza doverla rinegoziare. Un lato invia un messaggio con un contenuto e ne dichiara la lunghezza, l’altro risponde restituendo lo stesso contenuto. Il codice di OpenSSL non controllava che la lunghezza dichiarata corrispondesse a quella effettiva. Un attaccante poteva inviare un messaggio di un byte dichiarandone fino a 64 kilobyte, e il server rispondeva copiando nella risposta il contenuto della propria memoria che seguiva quel byte.
Ogni richiesta restituisce un frammento diverso della memoria del processo. Ripetendo le richieste si possono raccogliere grandi quantità di dati. L’operazione non lascia tracce nei log applicativi ordinari e non richiede autenticazione. Il difetto colpisce sia i server sia i client che usano le versioni vulnerabili.
Che cosa si può rubare
La memoria di un server web che gestisce connessioni cifrate contiene informazioni molto delicate:
- nomi utente e password inviati dagli utenti nelle richieste di accesso;
- cookie di sessione, che permettono di impersonare un utente collegato;
- contenuto delle richieste e delle risposte, compresi dati personali;
- nelle condizioni giuste, la chiave privata del certificato del server.
Nei primi giorni si è discusso se fosse davvero possibile ottenere la chiave privata. Una prova pubblica lanciata da un fornitore di servizi web ha chiuso la discussione in poche ore, con più partecipanti che sono riusciti a estrarla. Con la chiave privata un attaccante può impersonare il server e, se la connessione non usa la perfect forward secrecy, decifrare il traffico registrato in passato.
Come rimediare
La correzione richiede più passaggi, e fermarsi al primo lascia aperti rischi:
- aggiornare OpenSSL alla versione corretta o ricompilarla senza l’estensione heartbeat, e riavviare tutti i servizi che usano la libreria;
- generare nuove chiavi private e ottenere nuovi certificati, perché le chiavi potrebbero essere state sottratte prima dell’aggiornamento;
- revocare i certificati precedenti;
- invalidare le sessioni attive e chiedere agli utenti di cambiare le password, dopo che il server è stato corretto;
- verificare apparati e prodotti di terze parti, come VPN, dispositivi di rete, stampanti e sistemi industriali, che incorporano OpenSSL e dipendono dagli aggiornamenti dei produttori.
L’ultimo punto è il più lungo. Molti prodotti chiusi includono la libreria senza dichiararlo, e il cliente lo scopre solo dall’avviso del produttore, quando arriva.
Quanto era diffuso
Le prime stime parlano di circa mezzo milione di siti web sicuri vulnerabili al momento della divulgazione, una quota rilevante dei server HTTPS raggiungibili in Internet. A questi si aggiungono server di posta, concentratori VPN, apparati di rete e una parte dei dispositivi Android di una specifica versione, vulnerabili come client. Nei giorni successivi molti grandi servizi hanno comunicato di aver aggiornato i sistemi e hanno invitato gli utenti a cambiare le password.
La divulgazione
Il caso ha anche riaperto il dibattito sulla divulgazione coordinata. Alcune aziende sono state avvisate prima dell’annuncio pubblico e hanno potuto correggere i propri sistemi in anticipo. Altri, comprese molte distribuzioni Linux e grandi fornitori, hanno appreso la notizia insieme al resto del mondo e hanno dovuto rincorrere. Trovare un equilibrio tra la necessità di preparare le correzioni e il rischio che la notizia trapeli resta difficile quando il componente è usato ovunque. Secondo le informazioni diffuse, uno dei due gruppi che hanno scoperto il difetto lo ha individuato durante test automatici con tecniche di fuzzing, che inviano a un programma grandi quantità di input malformati.
Si può sapere se si è stati attaccati
La risposta è difficile. Lo sfruttamento non compare nei log del server web. Chi registra il traffico di rete completo o dispone di sistemi di rilevamento delle intrusioni con regole aggiornate può cercare messaggi heartbeat anomali, con una lunghezza dichiarata superiore a quella reale. Per il periodo precedente la divulgazione le tracce sono di solito assenti. Per questo la prudenza suggerisce di considerare compromesse le chiavi e le credenziali che sono transitate su un server vulnerabile.
La questione open source
Heartbleed ha rivelato un dato sorprendente. Un componente da cui dipende la sicurezza di gran parte di Internet era mantenuto da un gruppo molto ridotto di sviluppatori, in buona parte volontari, con risorse economiche minime. Il codice era pubblico, ma nessuno lo aveva esaminato con l’attenzione necessaria. Ad aprile la Linux Foundation ha annunciato una iniziativa, sostenuta da grandi aziende tecnologiche, per finanziare i progetti open source critici, a partire da OpenSSL.
Per le organizzazioni la lezione è pratica. Occorre sapere quali componenti open source si usano, in quali versioni e in quali prodotti, e avere una procedura per reagire quando uno di questi presenta una vulnerabilità grave. Senza un inventario dei componenti la prima domanda, cioè dove siamo esposti, richiede giorni di ricerca.
Vedi anche: l’articolo del 2003 OWASP Top 10 (2003), l’articolo del 2021 Log4Shell e l’articolo del 2026 Software Bill of Materials per l’IA.
Vincenzo Calabrò | Ingegnere informatico specializzato in sicurezza informatica e investigazioni digitali. Funzionario informatico del Ministero dell'Interno; su incarico autorizzato si occupa di sicurezza informatica e di perizie informatiche forensi. Autore di articoli e saggi. Lecturer, Speaker, Trainer.Profili: Google Scholar · ORCID · ResearchGate · Academia.edu · CyberSecurity360 · AgendaDigitale · ICT Security Magazine · LinkedIn