heartbleedSono giorni che giornali e siti internet non fanno altro che parlare di questo #Heartbleed. A meno che tu non abbia vissuto sotto una pietra nel deserto, sicuramente già ne avrai sentito parlare.

 

 

 

 

 

 

 

 

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

heartbleed.com

Parliamo di una vulnerabilità di una certa importanza. Uno dei più noti esperti di sicurezza a livello mondiale la definisce in questa maniera:

Heartbleed is a catastrophic bug in OpenSSL: “Catastrophic” is the right word. On the scale of 1 to 10, this is an 11.

Bruce Schneier 

Trovare una vulnerabilità in questo protocollo significa avere le chiavi di internet in mano. Possiamo tranquillamente dire che se internet fosse il Titanic questa vulnerabilità è sicuramente l’iceberg.

I file vulnerabili della libreria OpenSSL sono  t1_lib.c e d1_both.c  dalla versione 1.0.0 alla 1.0.0f

Entriamo più nei dettagli.

Per capire più o meno come funziona questa vulnerabilità andiamo a fare una differenza di codice dall’ultima versione vulnerabile cioè la 1.0.0f a quella con la patch 1.0.0g

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902

Come si evidenza nel codice sono stati aggiunti dei controlli mirati.

10
11
12
13
14
15
16
17
18

[...]
if (1 + 2 + 16 > s->s3->rrec.length)
  return 0; /* silently discard */
  hbtype = *p++;
 n2s(p, payload);
if (1 + 2 + payload + 16 > s->s3->rrec.length)
              return 0; /* silently discard per RFC 6520 sec. 4 */
  pl = p;
[...]

Le seconda IF quella più importante permette di fare un controllo sulla dimensione del payload in base alla versione. Risolvendo di fatto la vulnerabilità.

Banalmente, il mondo sta fremendo per una riga di codice.

Ma questo non è il solo punto cardine della faccenda. In ambienti enterprise, di solito, il cambiamento di librerie importanti come quelle soggette alla vulnerabilità potrebbero portare a qualche conflitto sui software interni. E questa cosa mette in gioco dei meccanismi abbastanza costosi per un’azienda medio/grande.

Questa policy largamente usata porta ad individuare su scala mondiale target come banche, istituzioni e medio/grandi aziende dove gli aggiornamenti contemplano anche altri tipi di problemi.

L’utilizzo di queste librerie non viene fatto soltanto in ambito “http” ma anche su altri tipi di servizi. Si va a colpire una più ampia scala di potenziali target. Sono vulnerabili servizi  ftps, smtp con auth SSL, App…etc etc

Il bug Heartbleed è stato introdotto in OpenSSL nel 2011. E’ noto dal 14 Marzo 2012!! ed è stato corretto 3 giorni fa! Il 7 Aprile 2014.  Troppo tempo! A quanti ha fatto comodo un bug simile? Quante spiegazioni potrebbero esserci per i data leaks fatti nel 2013? Ma sopratutto, è grazie a questo che l’NSA poteva intercettare il traffico da qualsiasi parte del mondo? (Ecco la risposta a questa domanda) ed ecco subito la smentita dell’NSA; Esempio pratico: se tu rubi in un negozio e qualcuno ti sorprende e vieni arrestato, la prima cosa che fai qual è? Ammetti di essere un ladro? Oppure neghi tutto? Bravi americani!

Questi giorni abbiamo visto una corsa al patching mai vista prima. Ma può bastare?

C’è una questione, secondo me, di primaria importanza.  In che percentuale questa vulnerabilità potrebbe avere successo nel rubare dalla memoria la chiave privata del certificato?

Ho visto alcuni exploit che mettendo in loop la richiesta, eseguivano ad ogni ciclo dei controlli su Sessione per rubare i cookies in memoria.

Se utilizzassi una tecnica simile per la chiave privata? Quanto tempo potrei impiegare?

Un utente su twitter è riuscito a prendere la chiave privata su FreeBSD, ma ad alcune condizioni che potrebbero rendere difficile il lavoro.

 

Lo stesso utente però non è riuscito a farlo su Linux.

Nel caso in cui sia possibile rubare la chiave privata (cosa molto probabile, ma complicata), il patching non è sufficiente. Si devono necessariamente revocare tutti i certificati in proprio possesso e cambiare tutte le password.

Facendo un pò di ricerche su internet ho trovato un po di risorse utili.

Raccomandazione: vi ricordo che eseguire PoC presi da internet, se non si sa cosa si sta facendo, potrebbe essere molto rischioso. Fate attenzione!

http://filippo.io/Heartbleed/ (An online test for exposure to Heartbleed) and https://github.com/FiloSottile/Heartbleed (The codebase the @filippo indicates is running on the site)
http://pastebin.com/WmxzjkXJ (ssltest.py)
https://www.ssllabs.com/ssltest/index.html (An online test for exposure to Heartbleed)
https://github.com/rapid7/metasploit-framework/pull/3206/files (Metasploit module)
https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse (Nmap NSE script)
https://github.com/titanous/heartbleeder?files=1  (POC in Go)
https://github.com/mothran/tlslite/tree/master/scripts
https://gist.github.com/rcvalle/10223042 (A C version from @rcvalle)
https://bitbucket.org/fb1h2s/cve-2014-0160/src (Scanner in python) and http://www.garage4hackers.com/entry.php?b=2551 (Writeup)
https://gist.github.com/RealRancor/10140249 (Another Nmap NSE script)
https://www.nth-dimension.org.uk/pub/s_client-vs-cve-2014-0160.diff.txt(Patch which allows exploitation using the OpenSSL client)
https://gist.github.com/anantshri/10238615 (Modified for readability)
http://1337day.com/exploit/22114 (Exploit POC)
https://play.google.com/store/apps/details?id=com.bblabs.heartbleedscanner (Mobile test for exposure)
https://github.com/HackerFantastic/Public/blob/master/exploits/heartbleed.c(Exploit POC)
https://github.com/sensepost/heartbleed-poc (Exploit POC)
https://gist.github.com/eelsivart/10174134 (Improved on ssltest.py)
http://www.tenable.com/plugins/index.php?view=single&id=73404 (Official Tenable NASL plugin)
https://chrome.google.com/webstore/detail/chromebleed/eeoekjnjgppnaegdjbcafdggilajhpic (Chrome plugin using test by Filippo Valsorda)
https://nextsuite.websecurify.com/apps/heartbleed/  (Test multiple targets)
https://lastpass.com/heartbleed/ (Test for exposure with added features for lastpass users)

Se avete altri link utili potete segnalarli nei commenti o scrivermi su twitter @FabioNatalucci

Conclusioni:

Una vulnerabilità troppo pericolosa per essere in the wild da tutto questo tempo. Mezzo mondo era impreparato sul problema, a rischio miliardi di dati, privacy, carte di credito, credenziali, password…e chi ne ha più ne metta. Un sistema che doveva proteggerci ci ha ingannato per diverso tempo. Eravamo convinti di essere al sicuro, ci fideremo ancora di quella piccola icona a forma di lucchetto giallo?