Heartbleed è un bug di sicurezza nella libreria di crittografia OpenSSL, che è un’implementazione ampiamente usata del protocollo TLS (Transport Layer Security). È stato introdotto nel software nel 2012 e aperto al pubblico nell’aprile 2014. Heartbleed potrebbe essere sfruttato indipendentemente dal fatto che l’istanza OpenSSL stia girando come server o client TLS. È il risultato di una validazione input impropria (data dalla mancanza di controllo dei limiti) nell’implementazione dell’estensione heartbeat del protocollo TLS, da cui il nome del bug. La vulnerabilità è classificata come un over-read del buffer, una situazione in cui vengono letti più dati di quelli che dovrebbero essere ammissibili.
Heartbleed è registrato nel database Common Vulnerabilities and Exposures come CVE-2014-0160. Il Canadian Cyber Incident Response Centre ha rilasciato un comunicato sulla sicurezza avvisando gli amministratori di sistema riguardo al bug. Una versione corretta di OpenSSL è uscita il 7 aprile 2014, nello stesso giorno in cui Heartbleed è stato reso noto al pubblico.
Al 20 maggio 2014, l’1,5% degli siti più popolari con il protocollo TLS attivo erano ancora vulnerabili all’Heartbleed. A gennaio 2020, secondo il report di Shodan, l'Italia si trovava al settimo posto - nel mondo - per quantità di server ancora vulnerabili (2858; la Cina, al secondo posto, ne aveva ancora 8655).
Altre implementazione del TLS oltre OpenSSL, come GnuTLS, Network Security Service di Mozilla, e le piattaforme di implementazione di TLS di Windows, non sono mai state affette dal bug perché il difetto è esistito solo nell’implementazione TLS di OpenSSL più che nel protocollo in sé per sé.
Storia
L’estensione Heartbeat per i protocolli Transport Layer Security (TLS) e Datagram Transport Layer Security (DTLS) venne proposta come standard nel febbraio 2012 da RFC 6520. Offre un modo per testare e tenere vive connessioni di comunicazione sicure senza il bisogno di rinegoziare la connessione ogni volta. Nel 2011, uno degli autori della RFC, Robin Seggelmann, in seguito studente di dottorato di ricerca della Fachhochschule Münster, implementò l’estensione Heartbeat per OpenSSL. Successivamente Seggelmann richiese di mettere i risultati del suo lavoro in OpenSSL e i suoi cambiamenti furono revisionati da Stephen N. Henson, uno dei quattro sviluppatori principali di OpenSSL. Henson non notò il bug nell’implementazione di Seggelmann e introdusse il codice imperfetto nel repository del codice sorgente di OpenSSL nel 31 dicembre 2011. Il difetto si sparse con il rilascio della versione 1.0.1 di OpenSSL nel 14 marzo 2012. Il supporto a Heartbeat era abilitato di default, lasciando vulnerabili le versioni affette.
Scoperta
In accordo a Mark J. Cox di OpenSSL, Neel Mehta del team di sicurezza di Google segnalò segretamente Heartbleed nel 1 aprile 2014 alle 11:09 UTC.
Il bug fu nominato da un ingegnere al Codenomicon, una compagnia di cybersecurity finlandese che creò anche il logo con un cuore che sanguina e fondò il dominio heartbleed.com per spiegare il bug al pubblico. Mentre il team di sicurezza segnalò per primo Heartbleed a OpenSSL, sia Google che Codenomicon lo scoprirono indipendentemente nello stesso momento circa. Codenomicon segnala il 3 aprile 2014 come la loro data di scoperta e di notifica alla National Cyber Security Center in Finlandia (NCSC-FI) per il coordinamento delle vulnerabilità.
Nel momento della rivelazione, qualcosa come il 17% (circa mezzo milione) dei web server sicuri in internet, certificati dalle Certification Authority diventarono vulnerabili agli attacchi, permettendo il furto delle chiavi private dei server e i cookie di sessioni e le password degli utenti. Electronic Frontier Foundation, Ars Technica e Bruce Schneier ritennero il bug Heartbleed catastrofico. Il colonnista della cybersecurity Joseph Steinberg di Forbes scrisse:
Un portavoce del Gabinetto Britannico raccomandò che:
Nel giorno della rivelazione il Progetto Tor consigliò:
The Sydney Morning Herald pubblicò una timeline della scoperta il 15 aprile 2014, mostrando che alcune organizzazioni erano state in grado di sistemare il bug prima dell’annuncio pubblico. In alcuni casi, non è chiaro come l’abbiano scoperto.
Bugfix e implementazione
Bodo Moeller e Adam Langley di Google prepararono il fix per Heartbleed. La patch risultante fu aggiunta all’issue tracker di Red Hat nel 21 marzo 2014. Stephen N. Henson applicò la patch al sistema di controllo versioni di OpenSSL il 7 aprile di quell’anno. La prima versione corretta, 1.0.1g, fu rilasciata lo stesso giorno. Nel 21 giugno 2014, 309,197 web server pubblici erano ancora vulnerabili.
Rinnovo dei certificati e revoche
In accordo a Netcraft, circa degli oltre certificati X.509 che potevano essere compromessi a causa di Heartbleed furono ripubblicati nuovamente nel 11 aprile 2014, benché alcuni furono revocati.
Per il 9 marzo 2014 solo il 43% dei siti web affetti avevano ripubblicato i loro certificati; in più, il 7% dei certificati di sicurezza ripubblicati usavano ancora le chiavi che potenzialmente potevano essere compromesse. Netcraft commentò:
eWeek disse:
Exploitation
Il Canada Revenue Agency segnalò un furto di Social Insurance Numbers appartenenti a 900 contribuenti, e disse che fu possibile sfruttando il bug durante un periodo di 6 ore l’8 aprile 2014. Dopo la scoperta, l’agenzia chiuse il suo sito ed estese il termine di presentazione dei contribuenti dal 30 aprile al 5 maggio. L’agenzia disse che avrebbe fornito un servizio di protezione del credito gratuitamente agli affetti dal furto. Il 16 aprile RCMP annunciò che avevano accusato uno studente di informatica in relazione al furto con uso non autorizzato di un computer e malizia in relazione ai dati.
Il sito genitoriale britannico Mumsnet ebbe molti account utente dirottati e il suo CEO fu impersonato da un utente maligno. Il sito, più tardi, pubblicò una spiegazione dell’incidente dicendo che fu causato da Heartbleed e che fu prontamente sistemato dallo staff tecnico.
Ricercatori anti-malware utilizzarono anch’essi Heartbleed in loro vantaggio per accedere a forum segreti usati da cybercriminali. Furono inoltre condotti studi utilizzando macchine deliberatamente vulnerabili. Ad esempio, il 12 aprile 2014, almeno due ricercatori indipendenti riuscirono a rubare chiavi private da un server sperimentale creato appositamente da CloudFlare. Successivamente il professor J. Alex Halderman dell’University of Michigan, il 15 aprile 2014, segnalò che il suo server honeypot, un server volutamente vulnerabile utilizzato per analizzare gli attacchi, aveva ricevuto numerosi attacchi originati dalla Cina. Halderman concluse che, dal momento che il server era ben nascosto, quegli attacchi fossero di larga scala e stessero affliggendo ampie aree di Internet.
Nell’agosto del 2014, fu reso pubblico che la vulnerabilità Heartbleed aveva permesso agli hacker di rubare chiavi di sicurezza dal Community Health Systems, la seconda catena di ospedali più grande per profitti degli Stati Uniti, compromettendo i dati confidenziali di 4.5 milioni di pazienti. La violazione avvenne una settimana dopo che Heartbleed fu reso pubblico.
Possibile conoscenza ed exploitation precedenti
Molti dei maggiori siti web sistemarono il bug o disabilitarono Heartbeat nel giro di qualche giorno dal suo annuncio, ma non è chiaro se l’exploit fosse già conosciuto dai potenziali hacker e in che misura sia stato sfruttato.
Basandosi sull’esaminazione dei log dei ricercatori, è stato segnalato che alcuni attaccanti potrebbero aver sfruttato la vulnerabilità per almeno cinque mesi prima della sua scoperta e del suo annuncio. Errata Security puntualizzò che un programma non maligno largamente usato chiamato Massacan, introdotto sei mesi prima della rivelazione di Heartbleed, interrompe bruscamente la connessione durante l'handshaking allo stesso modo di Heartbleed, generando gli stessi messaggi di log, aggiungendo "Due nuove cose che producono gli stessi messaggi di errore potrebbero sembrare che i due siano correlati, ma ovviamente non lo sono."
In accordo con Bloomber News, due fonti interne sconosciute informarono che la National Security Agency statunitense era al corrente del difetto da poco dopo la sua comparsa ma, invece di segnalarlo, lo tenne segreto insieme ad altre zero-day vulnerabilities in modo da sfruttarle per dei propositi propri dell’NSA. L’NSA ha negato l’accusa, stando a Richard A. Clarke, un membro della National Intelligence Review Group on Intelligence and Communications Technologies che recensì la policy della sorveglianza elettronica degli USA; l’11 aprile 2014 disse a Reuters che l’NSA non sapeva nulla di Heartbleed. L’allegazione spinse il governo statunitense a fare per la prima volta una dichiarazione pubblica sulla policy delle zero-day vulnerabilities, accettando la raccomandazione del rapporto 2013 del gruppo di revisione che affermava: “in praticamente tutte le istanze, per codice usato su ampia scala, è di interesse nazionale eliminare vulnerabilità software piuttosto che usarle per le collezioni dell’intelligence Americana”, e dicendo che la decisione di nasconderle deve essere passata dall’NSA alla Casa Bianca.
Comportamento
L’RFC 6520 Hearbeat Extension testa le connessioni sicure TLS/DTLS permettendo ad un computer ad un estremo della connessione di mandare messaggi Heartbeat Request, che consistono in un payload, tipicamente una stringa di testo, insieme alla lunghezza del payload come un integer di 16 bit. Il computer ricevente deve quindi mandare lo stesso esatto payload indietro al mittente.
La versione affetta di OpenSSL alloca un buffer di memoria per il messaggio che deve essere restituito basato sulla lunghezza del campo del messaggio di richiesta, senza riguardi per la vera dimensione del messaggio di payload. A causa del fallimento nel controllo preciso dei limiti, il messaggio di ritorno consiste nel payload, seguito possibilmente da qualsiasi cosa si trovi allocato nel buffer di memoria.
Heartbleed è successivamente sfruttato mandando una richiesta heartbeat malformata con payload minuscolo e un campo molto grande per la macchina vulnerabile (generalmente un server) in modo da provocare una risposta da parte della vittima, permettendo all’attaccante di leggere fino a 64 kilobyte dalla memoria della vittima che molto probabilmente era già stata usata recentemente dal protocollo OpenSSL. Nel caso dell’Heartbeat, viene mandata una richiesta al destinatario del tipo “mandami indietro la parola di quattro lettere ‘bird’”, che risulta nella risposta “bird”, mentre nel caso dell’Heartbleed viene mandata una richiesta maligna del tipo “mandami indietro la parola di 500 lettere ‘bird’” che causa una risposta da parte della vittima che consiste in una parola composta da “bird” e altri 496 caratteri contenuti nel buffer della memoria. Gli attaccanti così facendo possono ottenere dati sensibili, compromettendo la confidenzialità delle comunicazioni della vittima. Sebbene un attaccante ha un buon controllo sulla dimensione del blocco di memoria esposto, non ha controllo sulla sua locazione, e per questo non può scegliere che contenuto verrà rivelato.
Versioni di OpenSSL affette
Le versioni affette di OpenSSL vanno dalla versione 1.0.1 alla versione 1.0.1f (inclusa). Le versioni seguenti (da 1.0.1g in avanti) e quelle precedenti (da 1.0.0 e più vecchie) non sono vulnerabili. Le installazioni delle versioni affette sono vulnerabili, a meno che OpenSSL venga compilato con: DOPENSSL_NO_HEARTBEATS.
Programmi e funzioni vulnerabili
I file sorgenti dei programmi vulnerabili sono t1_lib.c e d1_both.c e le funzioni vulnerabili sono tls1_process_heartbeat() e dtls_process_heartbeat().
Patch
Il problema può essere risolto ignorando i messaggi Heartbeat Request che chiedono più dati di quelli necessari per i payload.