Heartbleed bug, quali i rischi per gli utenti ed i gestori di siti web HTTPS?

La scoperta di un grave bug presente nel cuore della libreria crittografica OpenSSL ha in poche ore fatto “il giro della Rete”. Il problema, questa volta, è davvero importante perché ha a che fare con la sicurezza delle informazioni veicolate fra server e client (e viceversa) durante l’utilizzo di connessioni cifrate (protocollo HTTPS) e con la riservatezza dei dati degli utenti.

Le vulnerabilità software sono qualcosa con cui è necessario convivere essendo consapevoli della loro esistenza e provvedendo diligentemente ad installare gli aggiornamenti non appena questi vengono rilasciati dai vari produttori.
Utilizzare software non aggiornati mediante l’installazione delle patch di sicurezza via a via distribuite attraverso i canali ufficiali è quanto di più sciocco si possa effettuare, in ambito aziendale, professionale e privato.

La vulnerabilità scoperta in questi giorni in OpenSSL è tuttavia qualcosa che preoccupa molto più del normale perché un componente software che, proprio per la sua natura, dovrebbe proteggere le comunicazioni online rendendo le transazioni in Rete più sicure.

La crittografia in Rete: cosa sono HTTPS, SSL e TLS

Il protocollo HTTPS (ossia HTTP con l’aggiunta del protocollo crittografico SSL/TLS), insieme con un certificato digitale valido, vengono comunemente usati da tutti i siti web che permettono la gestione di dati particolarmente importanti od informazioni sensibili.

Quando si utilizzano connessioni non sicure, facendo ricorso al solo HTTP – senza l’impiego di un protocollo di crittografia asimmetrica -, infatti, è molto facile, per un aggressore, carpire informazioni personali esaminando i dati in transito (attività di “sniffing“).

Collegandosi, ad esempio, con una piattaforma ricchissima di dati personali qual è un social network utilizzando solo il protocollo HTTP, il “session cookie” creato sul proprio sistema a login effettuato viene scambiato con il server remoto per tutta la durata della sessione di lavoro. Tale cookie contiene importanti informazioni legate all’autenticazione sul sito web: qualora un malintenzionato riuscisse a mettere le mani sul contenuto del cookie, potrebbe immediatamente loggarsi sul servizio impersonificando l’altrui identità.

Ipoteticamente, se le comunicazioni tra server e client (e viceversa) non “viaggiassero” in forma cifrata, analoga operazione potrebbe essere messa in atto da un aggressore su siti di online banking, su strumenti cloud, sui principali servizi che offrono caselle e-mail, e così via. Tutti i dati in transito potrebbero così essere agevolmente spiati e sottratti.

Ecco perché l’adozione di HTTPS è divenuta un imperativo sempre più pressante per difendersi dai furti di dati durante l’effettuazione di qualunque genere di transazione online.

Le più recenti versioni dei vari browser web ben evidenziano quando si sta utilizzando una connessione HTTP e quando, invece, ci si è collegati ad una pagina web che fa uso del protocollo HTTPS.

Sia Internet Explorer, sia Chrome, sia Firefox, ad esempio, espongono un lucchetto nella barra degli indirizzi insieme con l’indicazione https: ogniqualvolta si utilizzi una pagina che utilizza un certificato digitale e che quindi provvede a crittografare i dati cambiati tra client e server (e viceversa).

Per maggiori informazioni, vi suggeriamo di fare riferimento agli articoli Certificati digitali SSL gratuiti: a cosa servono e come ottenerne uno in pochi minuti e I certificati digitali e gli attacchi subiti dalle autorità di certificazione: l’accaduto e le difese da porre in campo.

Tutte le caselle di posta accessibili attraverso una webmail solitamente prevedono l’utilizzo del protocollo HTTPS.

Nel caso in cui, per scaricare ed inviare la posta elettronica, si utilizzasse un software client (Thunderbird, Eudora, Opera Mail,…) installato sul sistema, è indispensabile verificare che i dati vengano inviati e ricevuti utilizzando connessioni sicure (protocollo SSL/TLS):

Nell’esempio, Thunderbird è stato configurato per scaricare la posta in arrivo da un account Google Gmail. Come si vede, Gmail consente di attivare una connessione dati cifrata in modo che il contenuto delle e-mail scaricate non possa essere intercettato da parte di terzi (nell’articolo Configurare Gmail ed usare l’account al meglio abbiamo spiegato come configurare il client di posta per prelevare ed inviare e-mail utilizzando una connessione sicura).

L’utilizzo dei tradizionali protocolli POP3 sulla porta 110 e SMTP sulla porta 25 sono ad esempio assolutamente sconsigliati durante l’impiego di una rete Wi-Fi pubblica. In questo caso, infatti, le informazioni vengono scambiate “in chiaro”, senza alcuna forma di cifratura ed un malintenzionato può, in maniera molto semplice, “leggere” il contenuto dei messaggi di posta in transito.

In HTTPS, quindi, fra il protocollo TCP ed HTTP si interpone un livello di crittografia/autenticazione come SSL o TLS. Si tratta di protocolli che si prefiggono, come obiettivo, quello di garantire una comunicazione end-to-end ossia fra mittente e destinatario dei dati assicurando autenticazione, integrità dei dati e cifratura.

I certificati digitali vengono utilizzati per attestare l’identità di un sito web (così come di un soggetto, di una società, di un sistema e così via). Sul web, l’uso più comune dei certificati digitali è, appunto, per l’accesso ai siti attraverso il protocollo HTTPS.
Ricorrendo all’impiego dei certificati digitali, il browser web può accertarsi che il server a cui si è connessi sia autentico ossia che corrisponda effettivamente a quello che dichiara di essere. Se il certificato è stato firmato da un’autorità di certificazione riconosciuta, il browser provvede ad utilizzare la chiave pubblica indicata nel documento digitale per scambiare dati in modo sicuro, senza la possibilità che vengano in qualche modo essere intercettati.

Ogni messaggio crittografato con una data chiave pubblica può essere decrittato solo da chi possiede la relativa chiave privata (questo approccio si chiama, appunta, cifratura asimmetrica o cifratura a chiave pubblica). Se siamo sicuri che la chiave pubblica appartiene ad una determinata organizzazione (il gestore del sito web nel caso dei certificati digitali), allora siamo anche sicuri che solo l’applicazione web installata sul server dell’organizzazione potrà leggere i messaggi crittografati con quella chiave pubblica in quanto detentrice della rispettiva chiave privata. Ovviamente vale anche l’inverso ossia se possiamo decifrare un messaggio con quella chiave pubblica allora siamo sicuri che quel messaggio è stato criptato dall’organizzazione stessa.

Ad essere caduto, con la vulnerabilità appena scoperta nelle librerie OpenSSL, è proprio questo baluardo.
È bene però essere chiari: non c’è alcun genere di vulnerabilità nel protocollo in sé. Il problema, che potrebbe aver esposto i dati di milioni di persone ad “intercettazioni”, riguarda solo ed esclusivamente l’implementazione di OpenSSL.

Dove risiede il problema?

Il bug di sicurezza appena venuto a galla è presente nelle librerie OpenSSL ufficiali da più di due anni e risiede nell’implementazione dell’estensione Heartbeat, aggiunta in OpenSSL nel mese di dicembre 2011 con la pubblicazione della release 1.0.1.
L’estensione ha come obiettivo quello di ridurre la necessità di ristabilire le varie sessioni e di permettere il mantenimento delle sessioni SSL per un tempo maggiore.

Perché l’“Heartbleed Bug” è pericoloso

La pericolosa vulnerabilità, battezzata “Heartbleed Bug”, è presente in tutte le implementazioni di OpenSSL ove l’estensione Heartbeat sia mantenuta attiva. Tutte le versioni 1.0.1 di OpenSSL sono interessate dal problema, eccezion fatta per l’ultima release, la 1.0.1g che non è stata distribuita proprio per correggere la lacuna di sicurezza.
Per comprendere le dimensioni del problema, basti pensare che OpenSSL è utilizzato nel web server Apache e, quindi, su circa due terzi dei server web di tutto il mondo, per la gestione delle connessioni SSL/TLS attraverso il protocollo HTTPS.
Installando il web server Apache su una qualunque distribuzione Linux, ad esempio, si avrà a disposizione la possibilità di usare OpenSSL per la gestione delle connessioni cifrate.

L’“Heartbleed Bug” consente ad un qualunque malintenzionato, da remoto, di leggere il contenuto di una porzione della memoria del server (64 KB) ed essere immediatamente in grado di estrarre la chiave privata della connessione HTTPS, credenziali d’accesso, nominativi ed altre informazioni sensibili.

Bruce Schneier, crittografo che non ha certo bisogno di presentazioni, ha definito “Heartbleed” come un “bug catastrofico”. “In una scala da 1 a 10, questo bug può essere valutato 11“, ha aggiunto sul suo blog.

È vero che il problema di sicurezza in OpenSSL è stato subito risolto con il rilascio della versione 1.0.1g, al momento in corso d’installazione da parte degli amministratori di sistema di tutto il mondo, ma… è finita così? Tutto risolto? Nient’affatto.

Schneier si pone innanzi tutto qualche domanda. Un bug di sicurezza così grave e, allo stesso tempo, così “vecchio” (la sua prima apparizione è databile dicembre 2011), desta grande scalpore. “Credo che si tratti di un incidente”, ha osservato l’esperto rimarcando comunque che le prove non ci sono. Sull’onda dello scandalo NSA, Schneier ipotizza che i servizi di intelligence di mezzo mondo abbiano potuto, in questi due anni, razziare informazioni private ovunque: “la domanda è se qualcuno abbia deliberatamente inserito questo bug di sicurezza in OpenSSL”, si chiede Schneier.

In effetti, l’“Heartbleed Bug” sembra il “bug perfetto”, la vulnerabilità che fino ad oggi può aver consentito, a “qualcuno”, di impossessarsi delle chiavi del regno, di qualunque segreto.

Che cosa devono fare gli amministratori dei siti web che usano OpenSSL per la gestione delle connessioni HTTPS?

Il primo passo da compiere consiste ovviamente nell’installazione di OpenSSL 1.0.1g, versione della libreria esente dal pericoloso bug di sicurezza.
In aggiunta, però, bisognerà rinnovare la coppia di chiavi pubblica/privata presso l’autorità di certificazione alla quale ci si appoggia, revocare il certificato digitale sin qui utilizzato ed richiedere un nuovo certificato digitale.
A questo punto, il nuovo certificato potrà essere utilizzato e gestito da parte del web server.

Che cosa devono fare gli utenti per proteggersi?

È impossibile sapere se e quali informazioni, in questi due anni, i malintenzionati possano avere sottratto. C’è da aggiungere che il problema dell’“Heartbleed Bug” è venuto a galla da qualche giorno ed è quindi ipotizzabile che, almeno su vasta scala, non ci siano stati furti di dati.
Purtroppo, però, ed è questo ciò che preoccupa, non si può che restare sul piano delle ipotesi.
Gli attacchi che sfruttano l’“Heartbleed Bug”, infatti, non lasciano alcuna traccia e possono essere ovviamente ripetuti nel tempo da parte degli aggressori.

Gli amministratori di siti web, sia i grandi nomi che quelli meno noti, stanno in queste ore aggiornando i rispettivi server.
Adesso, infatti, l’“Heartbleed Bug” è divenuto di pubblico dominio così come i codici exploit in grado di sferrare attacchi verso i server web vulnerabili.
In questa fase, quindi, è importante che gli amministratori dei siti web HTTPS agiscano rapidamente aggiornando OpenSSL all’ultima release e modificando chiavi crittografiche e certificati digitali.
Un malintenzionato che si fosse già impossessato della chiave privata usata durante lo scambio di informazioni cifrate via HTTPS, sarebbe infatti in grado di continuare a “spiare” le comunicazioni se l’amministratore di sistema si limitasse al mero aggiornamento di OpenSSL alla versione 1.0.1g.

Per effettuare un test dei siti vulnerabili all'”Heartbleed Bug”, è possibile usare i seguenti alcuni strumenti:
– Possible.lv heartbleed test
– Filippo Heartbleed test
– LastPass Heartbleed checker
– Test McAfee

Fino a qualche ora fa erano moltissimi i siti che, tra i 10.000 più visitati al mondo, ancora utilizzavano versioni vulnerabili di OpenSSL o che comunque avevano l’estensione Heartbeat abilitata (è immediato rendersene conto visitando questa pagina). Adesso molti amministratori di sistema hanno già preso le misure cautelative del caso mettendo in sicurezza i rispettivi web server.

Dal momento che l’“Heartbleed Bug” può consentire ad un aggressore di appropriarsi delle altrui credenziali d’accesso, una misura che viene suggerita in queste ore è la modifica delle coppie username/password impiegate sui vari servizi online.

A titolo cautelativo, indipendentemente dalla posizione delle rispettive società, viene suggerito il cambio della password sui seguenti servizi:
– Yahoo!
– Google
– Facebook
– Dropbox
– Tumblr

Non sono invece interessati dal problema (generalmente perché la libreria OpenSSL non viene utilizzata):
– LinkedIn
– Amazon
– Microsoft
– eBay
– PayPal
– Evernote
– AOL

La situazione nel caso di Apple e di Twitter non è al momento ancora chiara (il social network non sembrerebbe comunque interessato dal problema).

Su tutti gli altri siti web, il consiglio è quello di verificare – utilizzando i test sopra riportati – se il problema relativo all’“Heartbleed Bug” sia stato o meno risolto.
Questo test, ad esempio, visualizza il messaggio (colore verde) “Your server appears to be patched against this bug” quando il sito web usa una versione correttamente aggiornata di OpenSSL (1.0.1g o successiva).
Il messaggio “TLS extension (heartbeat) seems disabled, so your server is probably unaffected” è egualmente rassicurante perché fa presente come l’estensione vulnerabile risulti completamente disattivata.

EFF (Electornic Frontier Foundation), storica organizzazione con sede negli Stati Uniti che si prefigge di difendere i diritti di libertà di parola in Rete, ha colto l’occasione per invitare i gestori di server HTTPS ad implementare anche Perfect Forward Secrecy, un meccanismo già adottato ad esempio da Google su Gmail che impedisce ad un aggressore di decodificare il traffico dati cifrato in precedenza nel momento in cui dovesse essere sottratta la chiave privata a protezione della connessione.

A questo indirizzo gli autori del progetto Zmap (Scansionare la rete Internet in appena 45 minuti) pubblicano statistiche aggiornate sul numero di server HTTPS ancora affetti dal bug e l’elenco dei siti web più trafficati a tutt’oggi vulnerabili.