Heartbleed

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,^[3] da qui il nome del bug.^[2] La vulnerabilità è classificata come un over-read del buffer,^[4] una situazione in cui vengono letti più dati di quelli che dovrebbero essere ammissibili.^[5]

Heartbleed è registrato nel database Common Vulnerabilities and Exposures come CVE-2014-0160.^[4] Il Canadian Cyber Incident Response Centre ha rilasciato un comunicato sulla sicurezza avvisando gli amministratori di sistema riguardo al bug.^[5] Una versione corretta di OpenSSL è stata rilasciata nel 7 aprile 2014, nello stesso giorno in cui Heartbleed è stato reso noto al pubblico.

Al 20 maggio 2014, l’1,5% degli 800,000 siti più popolari con il protocollo TLS attivo erano ancora vulnerabili all’Heartbleed.^[6] 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).^[7]

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é.^[8]

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.^[9] 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.^[10][11][12] 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.^[13][14][15]

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.^[16]

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.^[17] Mentre il team di sicurezza segnalò per primo Heartbleed a OpenSSL, sia Google che Codenomicon lo scoprirono indipendentemente nello stesso momento circa.^[13][18][19] 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à.^[13][20]

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.^{[21][22][23][24][25]} Electronic Frontier Foundation,^[26] Ars Technica^[27] e Bruce Schneier^[28] ritennero il bug Heartbleed catastrofico. Il colonnista della cybersecurity Joseph Steinberg di Forbes scrisse:

Alcuni potrebbero pensare che Heartbleed sia la peggior vulnerabilità mai esistita (almeno in termini del suo potenziale impatto) da quando il traffico commerciale iniziò a scorrere in internet.^[29]

Un portavoce del Gabinetto Britannico raccomandò che:

Le persone dovrebbero prendere nota di cambiare le password dei siti che usano.

La maggior parte dei siti hanno corretto il bug e sono nella posizione migliore per consigliare quale azione, se necessario, le persone devono prendere.^[30]

Nel giorno della rivelazione il Progetto Tor consigliò:

Se si necessita di una forte anonimità o privacy in Internet, si potrebbe voler stare distanti da Internet per i prossimi giorni, finché le cose si sistemano.^[31]

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.^[29]

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.^[30] Stephen N. Henson applicò la patch al sistema di controllo versioni di OpenSSL il 7 aprile di quell’anno.^[31] La prima versione corretta, 1.0.1g, fu rilasciata lo stesso giorno. Nel 21 giugno 2014, 309,197 web server pubblici erano ancora vulnerabili.^[32]

In accordo a Netcraft, circa 30,000 dei 500,000+ certificati X.509 che potevano essere compromessi a causa di Heartbleed furono ripubblicati nuovamente nel 11 aprile 2014, benché alcuni furono revocati.^[33]

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ò:

Con il riuso delle stesse chiavi private, un sito che era affetto dal bug Heartbleed continua a correre lo stesso rischio di quelli che non hanno ancora rimpiazzato i loro certificati SSL.^[34]

eWeek disse:

[Hearbleed è] probabilmente un rischio che rimarrà ancora per mesi, se non per anni.^[35]

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.^[36] Dopo la scoperta, l’agenzia chiuse il suo sito ed estese il termine di presentazione dei contribuenti dal 30 aprile al 5 maggio.^[37] 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.^[34][38]

Il sito genitoriale britannico Mumsnet ebbe molti account utente dirottati e il suo CEO fu impersonato da un utente maligno.^[39] Il sito, più tardi, pubblicò una spiegazione dell’incidente dicendo che fu causato da Heartbleed e che fu prontamente sistemato dallo staff tecnico.^[40]

Ricercatori anti-malware utilizzarono anch’essi Heartbleed in loro vantaggio per accedere a forum segreti usati da cybercriminali.^[41] 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.^[42][43] 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.^[44]

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.^[45]

Molti dei maggiori siti web sistemarono il bug o disabilitarono Heartbeat nel giro di qualche giorno dal suo annuncio^[46], 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.^[47][48] 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.^[49]"

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.^[50][51][52] L’NSA ha negato l’accusa,^[53] 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.^[54] 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.^[55]

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.^[56] 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.

Le versioni affette di OpenSSL vanno dalla versione 1.0.1 alla versione 1.0.1f (inclusa). Le versioni seguenti (da 1.0.1g^[57] in avanti) e quelle precedenti (da 1.0.0 e più vecchie) non sono vulnerabili.^[58] Le installazioni delle versioni affette sono vulnerabili, a meno che OpenSSL venga compilato con: DOPENSSL_NO_HEARTBEATS.^[59][60]

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().^[61][62]

Il problema può essere risolto ignorando i messaggi Heartbeat Request che chiedono più dati di quelli necessari per i payload. La versione 1.0.1g di OpenSSL aggiunge alcuni controlli di limiti per prevenire l’over-read del buffer. Per esempio, il seguente test fu introdotto per determinare se una richiesta heartbeat inneschi Heartbleed; scarta silenziosamente richieste maligne.

if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0; /*silently discard per RFC 6520 sec. 4 */ 

Il sistema di controllo versioni contiene una lista completa di cambiamenti.^[31]

I dati ottenuti da un attacco Heartbleed possono includere scambi non criptati tra le parti TLS che potrebbero essere riservate, inclusi i dati dalle richieste POST delle form compilate dagli utenti. Inoltre, i dati confidenziali esposti possono includere anche dati segreti per l’autenticazione, come i cookie di sessione e le password, che potrebbero permettere agli attaccanti di impersonare un utente del servizio.^[63]

Un attacco potrebbe anche rivelare le chiavi private delle parti compromesse,^[13][15][64] che potrebbero abilitare l’attaccante a decriptare le comunicazioni (traffico futuro o passato catturato da intercettazioni passive, a meno che non venga usato un perfect forward secrecy, nel qual caso solo il traffico futuro può essere decrittato se intercettato da attacchi man-in-the-middle).

Un attaccante che ha ottenuto l’occorrente per l’autenticazione potrebbe impersonare l’utente dopo che la vittima abbia sistemato il bug Heartbleed, nel caso in cui il materiale per l’autenticazione sia ancora valido (ad esempio, finché la password non viene cambiata o la chiave privata non venga revocata). Heartbleed comunque costituisce una minaccia critica alla confidenzialità. Poi, un attaccante che impersona una vittima potrebbe anche alterare i dati. Indirettamente le conseguenze di Heartbleed potrebbero andare ben oltre una violazione di confidenzialità per molti sistemi.^[64]

Un'indagine condotta su adulti americani nell'aprile 2014 ha mostrato che il 60% aveva sentito parlare di Heartbleed. Tra quelli che usano internet, il 39% avevano protetto il loro account online, per esempio cambiando password o cancellando l’account; il 29% credevano che le loro informazioni personali fossero messe a rischio a causa del bug Heartbleed; il 6% infine pensavano che le loro informazioni personali fossero state rubate.^[65]

Sebbene il bug abbia ricevuto molta attenzione a causa della minaccia che rappresentava per i server,^[66] i client TLS che usavano le istanze affette di OpenSSL erano comunque vulnerabili. Con ciò che The Guardian ha quindi soprannominato Reverse Heartbleed, i server malevoli sono in grado di sfruttare Heartbleed per leggere i dati dalla memoria di un client vulnerabile.^[67] Il ricercatore in sicurezza Steve Gibson disse di Heartbleed:

Non si tratta solamente di una vulnerabilità server-side, è anche una vulnerabilità client-side perché anche il server, o qualunque dispositivo a cui si è connessi, è in grado di fare una richiesta heartbeat al client tanto quanto il client è in grado di farla.^[68]

I dati rubati possono contenere username e password.^[69] Reverse Heartbleed ha interessato milioni di istanze dell'applicazione.^[67] Alcune delle applicazioni vulnerabili sono listate nella sezione “Applicazioni Software” qui sotto.

Cisco Systems ha identificato 78 dei suoi prodotti come vulnerabili, compresi i sistemi telefonici IP e i sistemi di telepresenza (videoconferenza).^[70]

Un’analisi postata su GitHub del sito web più visto nell’8 aprile 2014 ha rivelato vulnerabilità in siti che comprendono Yahoo!, Imgur, Stack Overflow, Slate e DuckDuckGo.^[46][71] I seguenti siti hanno servizi affetti o hanno fatto annunci raccomandando che gli utenti aggiornino le password in risposta al bug:

Il governo federale canadese ha temporaneamente spento i servizi online di Canada Revenue Agency (CRA) e diversi dipartimenti governativi che hanno a che fare con il bug Heartbleed.^[96][97]

I manutentori della piattaforma come la Wikimedia Foundation consigliavano ai loro utenti di cambiare password.^[98]

I server di LastPass erano vulnerabili,^[99] ma grazie a crittografia aggiuntiva e forward secrecy, i potenziali attaccanti non furono in grado di sfruttare il bug. In ogni caso LastPass raccomandò agli utenti di aggiornare le password per i siti web vulnerabili.^[100]

Il Tor Project raccomandò che i trasmettitori Tor e i servizi nascosti revocassero e generassero nuove chiavi dopo aver applicato OpenSSL, ma notarono che i trasmettitori Tor utilizzano due set di chiavi e che il design multi-hop di Tor minimizza l'impatto dello sfruttamento di un singolo trasmettitore. 586 trasmettitori che furono successivamente scoperti ad essere vulnerabili al bug Heartbleed furono messi offline come misura precauzionale.

Servizi legati ai giochi come Steam, Minecraft, Wargaming.net, League of Legends, GOG.com, Origin, Sony Online Entertainment, Humble Bundle e Path of Exile erano affetti ma furono prontamente sistemati.

Le applicazioni software vulnerabili includono:

• Alcuni server application Hewlett-Packard, come l’HP System Management Homepage (SMH) per Linux e Windows.
• Alcune versioni di FileMaker 13.
• LibreOffice dalla 4.2.0 alla 4.2.2 (sistemato nella 4.2.3).
• LogMeIn ha annunciato di aver “aggiornato molti prodotti e parte dei nostri servizi che si basano su OpenSSL”.
• Molti prodotti McAfee, in particolare alcune versioni del software che fornisce copertura anti-virale per Microsoft Exchange, firewall software e McAfee Email e Web Gateways.
• MySQL Workbench 6.1.4 e precedenti.
• Oracle MySQL Connector/C 6.1.0-6.1.3 e Connector/ODBC 5.1.13, 5.2.5-5.2.6, 5.3.2.
• Oracle Big Data Appliance (compreso Oracle Linux 6)
• Primavera P6 Professional Project Management (incluso Primavera P6 Enterprise Project Portfolio Management)
• WinSCP (client FTP per Windows) 5.5.2 e alcune versioni precedenti (vulnerabili solo con FTP su TLS/SSL, sistemato nella 5.5.3)
• Molte versioni dei prodotti VMware, compreso VMware ESXi 5.5, VMware Player 6.0, VMware Workstation 10 e la serie di prodotti Horizon, emulatori e suite cloud computing.

Alcune altre applicazione di Oracle Corporation ne erano affette.

Alcune versioni GNU/Linux ne erano affette, incluso Debian (e derivati come Linux Mint e Ubuntu) e Red Hat Enterprise Linux (e derivati come CentOS, Oracle Linux 6 e Amazon Linux), così come i seguenti sistemi operativi e firmware:

• Android 4.1.1, usato in vari device portatili. Chris Smith scrive in Boy Genius Report che solo questa versione di Android ne è affetta ma purtroppo è una versione popolare di Android (Chikita dichiara che la 4.1.1 è su 50 milioni di device; Google invece dice che si tratta di meno del 10% dei dispositivi Android attivi). Altre versioni Android non sono vulnerabili dal momento che hanno Heartbeat disattivato o usano una versione non affetta di OpenSSL.
• Firmware per alcune stazioni basee AirPort.
• Firmware per alcuni Cisco Systems routers
• IPCop 2.1.3 e alcune versioni precedenti (sistemato nella 2.1.4).
• pfSense 2.1.0 e 2.1.1 (sistemato nella 2.1.2).
• Le versioni DD-WRT tra la 19163 e la 23881 comprese (sistemato nella 23882).
• Prodotti della famiglia firmware Western Digital My Cloud.

Alcuni servizi sono stati resi disponibili per testare se un certo sito è affetto da Heartbleed. Comunque molti servizi hanno dichiarato di essere inefficienti a individuare il bug. I tool disponibili comprendono:

• Tripwire SecureScan
• AppCheck – scanner statico binario della Codenomicon
• Arbor Network's Pravail Security Analytics
• Norton Safeweb Heartbleed Check Tool
• Un tool di test per Heartbleed di una società italiana
• Heartbleed Scanner del crittologo italiano Filippo Valsorda
• Heartbleed Vulnerability Test di Cyberoam
• Critical Watch Free Online Heartbleed Tester
• Metasploit Heartbleed scanner module
• Heartbleed Server Scanner di Rehmann
• Lookout Mobile Security Heartbleed Detector, applicazione per device Android che determina la versione OpenSSL e indica se la vulnerabilità Heartbeat è abilitata
• Heartbleed checker di LastPass
• Network range scanner online per la vulnerabilitò di Pentest-Tools.com
• Scanner offline ufficiale di RedHat scritto in Python
• Qualys SSL Labs' SSL Server Test che non è utile solo per il bug Heartbleed, ma cerca anche altri errori di implementazione di SSL/TLS.
• Estensioni per browser come Chromebleed e FoxBleed
• SSL Diagnos
• CrowdStrike Heartbleed Scanner che scannerizza router, stampanti e altri device connessi all’interno di una rete, inclusi siti intranet.
• Netcraft Site Report che indica se la riservatezza di un sito Web potrebbe essere compromessa a causa di un precedente sfruttamento di Heartbleed verificando i dati dal sondaggio SSL di Netcraft per determinare se un sito offriva l'estensione TLS heartbeat prima della divulgazione Heartbleed. Anche le estensioni Netcraft per Chrome, Firefox e Opera eseguono questo controllo, mentre cercano certificati potenzialmente compromessi.

Altri tool di sicurezza hanno aggiunto il supporto per la ricerca di questo bug. Per esempio, Tenable Network Security ha scritto un plugin per il suo scanner di vulnerabilità Nessus che può trovare questa breccia. Lo scanner di sicurezza di Nmap include uno script di ricerca per Heartbleed dalla versione 6.45.

Sourcefire ha rilasciato le regole Snort per scovare traffico di attacchi Heartbleed e possibile traffico di risposta Heartbleed. Software open source per l’analisi di pacchetti come Wireshark e tcpdump possono identificare pacchetti Heartbleed usando specifici filtri per pacchetti BPF che possono essere usati su catture di pacchetti archiviate o traffico live.

La vulnerabilità a Heartbleed è risolta aggiornando OpenSSL a una versione patchata (1.0.1g o più nuove). OpenSSL può essere usato sia come un programma stand-alone, sia come una libreria a collegamento dinamico; in questo modo, l’aggiornamento può richiedere il restart dei processi caricati con una versione vulnerabile di OpenSSL e il re-link dei programmi e delle librerie che sono ad esso linkati staticamente. In pratica ciò significa che vengono aggiornati i pacchetti che sono linkati staticamente a OpenSSL, e il restart dei programmi funzionanti per la rimozione della copia in memoria della versione vecchia e vulnerabile di OpenSSL.

Dopo che la vulnerabilità e patchata, l’amministratore server deve annunciare la potenziale violazione di riservatezza. Dal momento che Heartbleed ha permesso agli attaccanti di scoprire le chiavi private, queste devono essere trattate come se fossero compromesse; le coppie di chiavi devono essere rigenerate e i certificati che le usano devono essere riemessi; i vecchi certificati devono essere revocati. Heartbleed ha inoltre la possibilità di aver esposto altri segreti contenuti in memoria; per questo altri materiali di autenticazione (come le password) devono essere cambiate. È raramente possibile confermare che un sistema affetto dal bug non sia stato compromesso, o determinare se un’informazione specifica non sia trapelata.

Siccome è difficile o addirittura impossibile determinare se le credenziali possono essere compromesse o meno e come possono essere state usate da un attaccante, alcuni sistemi potrebbero richiedere ulteriori interventi di riparazione anche dopo aver corretto la vulnerabilità e aver sostituito le credenziali. Per esempio, le firme fatte dalle chiavi che erano in uso con la versione vulnerabile di OpenSSL potrebbero tranquillamente essere state fatte da un attaccante; ciò alza la probabilità che l’integrità del sistema sia stata violata, e apre le firme al ripudio. La validazione delle firme e la legittimità di altri tipi di autenticazione fatti con chiavi potenzialmente compromesse (come l’uso del certificato client) deve essere fatto con riguardo al sistema specifico coinvolto.

Da quando Heartbleed ha minacciato la privacy delle chiavi private, gli utenti di un sito web compromesso potrebbero continuare a soffrire degli effetti di Heartbleed fino a che il browser non venga messo al corrente della revoca dei certificati o i certificati compromessi scadono. Per questo motivo il rimedio dipende anche dagli utenti che utilizzano browser con elenchi di revoche di certificati aggiornati (o supporto OCSP) e revisioni di certificati d'onore.

Seppur difficile valutare il danno totale causato da Heartbleed, eWEEK stima un punto di partenza di 500$ americani.

Il paper di David A. Wheeler intitolato How to Prevent next Heartbleed analizza il perché Heartbleed non è stato scoperto prima, e promuove alcune tecniche che potrebbero aver portato a scoperte più rapide, oltre a tecniche che avrebbero potuto diminuire il suo impatto. Stando a Wheeler, il modo più efficiente che avrebbe potuto prevenirlo sta in una suite di test atipici che esegue accuratamente ciò che definisce test negativo, ossia testare che input non validi non devono aver successo. Wheeler evidenzia come una singola suite di test general-purpose sarebbero utili come base per qualsiasi implementazione di TLS.

In accordo ad un articolo scritto da Robert Merkel, The Conversation, Heartbleed ha rivelato un fallimento massivo sull’analisi dei rischi. Merkel pensa che OpenSSL dia più importanza alle performance piuttosto che alla sicurezza, che ormai, secondo la sua opinione, non ha più senso. Ma Merkel considera che OpenSSL non dovrebbe essere incolpato tanto quanto i suoi utenti, che decidono di usarlo senza finanziare migliori test e revisioni. Merkel spiega come due aspetti determinino il rischio che bug simili possano causare vulnerabilità: il primo, il codice sorgente della libreria, influenza il rischio di scrivere bug con tale impatto; il secondo, i processi di OpenSSL, influenzano le probabilità di catturare i bug rapidamente. Per il primo aspetto, Merkel menziona l’utilizzo del linguaggio di programmazione C come un fattore di rischio che ha favorito l’apparizione di Heartbleed, facendo da eco per l’analisi di Wheeler.

Sullo stesso aspetto, Theo de Raadt, fondatore e leader di OpenBSD e OpenSSH, critica gli sviluppatori di OpenSSL per aver scritto la loro propria routine di gestione della memoria e per questo di aver aggirato la libreria in C per le contromisure agli exploit di OpenBSD, dicendo che “OpenSSL non è sviluppato da un team responsabile.” Dopo la rivelazione di Heartbleed infatti, i membri del progetto OpenBSD hanno creato un fork di OpenSSL chiamato LibreSSL.

L’autore della modifica che ha introdotto Heartbleed, Robin Seggelmann, ha ammesso di aver mancato la validazione di una variabile contenente una lunghezza (dell’input) e ha negato qualsiasi intenzione di creare un’implementazione imperfetta. A seguito della comparizione di Heartbleed, Segglemann ha suggerito di concentrarsi sul secondo aspetto, legato al fatto che OpenSSL non è revisionato da un numero di persone sufficiente. Sebbene il lavoro di Seggelmann venne controllato da uno degli sviluppatori principali di OpenSSL, la revisione era principalmente incentrata sulla verifica di un aumento delle funzionalità, una condizione che purtroppo ha reso più complesso l’accorgimento di possibili vulnerabilità.

Ben Laurie, lo sviluppatore OpenSSL in questione, ha dichiarato che una verifica della sicurezza di OpenSSL avrebbe sicuramente trovato Heartbleed. L’ingegnere software John Walsh ha commentato:

Pensateci, OpenSSL ha solamente due persone [full-time] che lo sviluppano, mantengono, testano e che verificano 500,000 righe di codice critico.

Il presidente fondatore di OpenSSL, Steve Marquess, disse “Il mistero non è che pochi volontari sovraccarichi di lavoro non si siano accorti del bug; il mistero è come mai ciò non accada più spesso.” David A. Wheeler descrisse le revisioni come un eccellente metodo per trovare vulnerabilità in casi simili, ma notò che “OpenSSL usa strutture complesse non necessarie, che rendono più difficoltoso sia per le persone che per le macchine revisionarlo.” Infatti scrisse:

Dovrebbe esserci un impegno continuo a semplificare il codice, perché altrimenti aggiungendo funzionalità si arriverà lentamente ad avere del software molto complesso. Il codice dovrebbe subire un refactoring nel tempo per renderlo semplice e chiaro, non solo per aggiungere nuove features. L’obbiettivo dovrebbe essere quello di programmare ciò che è “ovviamente giusto”, in opposizione ad un codice che è talmente complicato da “non vederne i problemi”.

LibreSSL ha eseguito una grossa pulizia, rimuovendo più di 90,000 linee di codice in C solamente in una settimana.

Stando a Dan Kaminsky, ricercatore per la sicurezza, Heartbleed è un segno di un problema economico che deve essere sistemato. Vedendo il tempo occupato per trovare questo semplice errore in un ancor più semplice feature di una dipendenza “critica”, Kaminsky teme ancor più vulnerabilità se non viene fatto nulla al riguardo. Quando Heartbleed è stato scoperto, OpenSSL era mantenuto da un insieme di volontari, di cui uno solo lavorava full-time. Le donazioni annuali a OpenSSL erano all’incirca 2,000$ americani. Il sito di Heartbleed di Codenomicon ha consigliato di effettuare donazioni al progetto OpenSSL. Dopo di ciò, per i 2/3 giorni seguenti alla comparsa di Heartbleed le donazioni sono arrivate a 841$ americani; a riguardo, Kaminsky ha commentato “Stiamo costruendo la più importante tecnologia per l’economia globale su un’infrastruttura incredibilmente sottosviluppata.” Il core developer Ben Laurie ha qualificato il progetto come “completamente non finanziato”. Seppur OpenSSL Software Foundation non ha un programma bug bounty, l’iniziativa Internet Bug Bounty ha premiato Neel Mehta di Google con 15,000$ americani per aver scoperto Heartbleed e per averlo reso noto a tutti.

Paul Chiusano ritiene che Heartbleed potrebbe essere il risultato di un fallimento dell’economia software.

La risposta collettiva delle industrie alla crisi fu il Core Infrastructure Initiative, un progetto multimilionario annunciato da Linux Foundation il 24 aprile 2014 per fornire fondi agli elementi critici dell'infrastruttura di informazione globale. L'iniziativa intende consentire agli sviluppatori principali di lavorare a tempo pieno sui loro progetti e pagare per verifiche della sicurezza di infrastrutture software e hardware, viaggi e altre possibili spese. OpenSSL è un candidato a diventare il primo destinatario dei finanziamenti dell'iniziativa.

Dopo averlo scoperto, Google ha fondato Project Zero, che è incaricato di trovare falle zero-day per aiutare a mettere in sicurezza il Web e la società.

• Wikimedia Commons contiene immagini o altri file su Heartbleed Bug

• (EN) Sito ufficiale, su heartbleed.com.

Portale Crittografia

Portale Sicurezza informatica