Heartbleed è una vulnerabilità resa nota nel 2014, scoperta all’interno del software OpenSSL, il software più utilizzato per cifrare il traffico fra due macchine.
Questa falla di sicurezza consisteva nell’abusare di una nuova funzione ideata per garantire la continuità di una connessione tra due macchine. I così detti “heartbeat”.
Ovviamente il protocollo era utilizzabile non solo in una connessione client-server, ma anche in una connessione punto-punto.
Gli heartbeat servivano per garantire che sia il client, sia il server, continuassero ad essere operativi e connessi fra loro, inviandosi regolarmente dei “battiti”, come quelli di un cuore (da qui, appunto, “heartbeat”).
Il funzionamento è abbastanza semplice, in teoria:
Il client chiedeva al server qualcosa come “hey, sei sveglio? Ti sto mandando questa stringa lunga 64 byte. Se sei ancora sveglio, rimandameli indietro.”
Il server elaborava la richiesta e inviava di risposta i dati come li aveva ricevuti, per far capire che la comunicazione fosse ancora attiva.
Questo sarebbe stato il funzionamento teorico corretto, ma a quanto pare non è mai esistito, in due anni, un controllo che verificasse che la quantità di dati dichiarata fosse effettivamente la quantità dei dati ricevuta.
A questo punto sarebbe stato possibile sfruttare gli heartbeat in un modo simile a questo:
“Hey, sei sveglio? Ti sto mandando questa stringa lunga 100KB. Se sei attivo, rimandameli indietro”.
Il client, però, ne avrebbe inviati solo una parte, diciamo per esempio 1 byte. Il server, perciò, leggeva il valore dichiarato, ossia 100KB, NON controllava che in realtà ne fosse stato inviato solo 1, e proseguiva con l’inviare l’informazione ricevuta, ossia il byte, più tutto ciò che trovava in memoria fino al raggiungimento dei 100KB richiesti.
“Heartbleed” viene chiamata una vulnerabilità “buffer over-read”, ossia un’anomalia di un programma che, durante una normale attività di lettura della memoria, tenta di superare il limite che gli impone il sistema e prova a leggere spazi di memoria adiacente, come nell’esempio precedente.
Di per sé non è una vulnerabilità così eclatante, basti pensare che qualunque programma scritto in C o C++ può rappresentare un rischio analogo, dato che questi linguaggi non forniscono nativamente una protezione contro questo “superare i limiti di memoria forniti”.
Ciò che scosse l’opinione pubblica, o per lo meno la comunità di ricercatori, furono tre cose:
- Per due anni nessuno si è pubblicamente accordo dell’esistenza della vulnerabilità;
- Se abusata correttamente, Heartbleed non lascia traccia. Perciò, attualmente, non si hanno documentazioni tecniche del suo sfruttamento ai danni di una società o un sistema;
- Nonostante un server possa adottare una cifratura degna di nota per le sue connessioni, in RAM i dati sono mantenuti per la maggior parte delle volte in chiaro, poiché devono essere elaborati dai processi, portando ad uno sforzo per decifrarli inesistente, una volta ricevuti.
In questa dimostrazione si può osservare come sia rapido ed efficace violare la memoria di un server non aggiornato.
Viene effettuato un login regolarmente, senza che il proprio traffico sia intercettato o compromesso.
Si esegue un semplice script con al suo interno la richiesta appositamente costruita…
Ed ecco la memoria del server in chiaro, contenente i dati inseriti nel form di login del sito. Tutto in chiaro e salvato sulla propria macchina.
Considerazione:
Nel raro caso in cui i processi o il server operino con dati cifrati, per esempio con l’hash di una password, l’impatto non sarà certo minore, poiché una volta salvata in locale la stringa cifrata, si potrà ricorrere a tutti i metodi conosciuti per tentare di decifrarla, come le rainbow tables, attacchi a dizionario o addirittura la forza bruta.
Sarà impossibile da intercettare, perché non verrà fatto ogni volta un attacco diverso, ma sarà svolto tutto in locale e all’oscuro del server vittima.
Piccola curiosità:
Lo sviluppatore che collaborò per l’inserimento degli heartbeat in OpenSSL, ha dichiarato pubblicamente che il suo è stato un “banale errore umano di programmazione”. Ovviamente questa dichiarazione non ha placato le voci riguardo una presunta scelta arbitraria di programmazione. Dopotutto si sarebbe trattato di una tecnica di esfiltrazione impossibile da tracciare ed invisibile a qualsiasi amministratore.
