HeartBleed: origine, spiegazione e rimedi

Logo di heartbleed

HeartBleed logo

In questi giorni, è stata diffusa la notizia della presenza di una falla di sicurezza nel meccanismo di crittografia più diffuso al mondo, cioè OpenSSL. La falla si chiama HeartBleed e, vista la gravità, è stato anche creato un sito omonimo: http://heartbleed.com/

Gli informatici con nozioni di crittografia possono saltare direttamente alla sezione Descrizione della falla di sicurezza.

OpenSSL viene usato ovunque nel mondo e, soprattutto, in quasi tutti i casi in cui è richiesta crittografia: in particolare, viene usata nell’HTTPS, cioè il meccanismo con cui viene criptato l’accesso alle pagine web. Se ci fate caso, buona parte delle pagine di login (Google, Facebook, Windows Live e simili) hanno un indirizzo che inizia con https:// . Ecco, questo vuol dire che il vostro browser, nel connettersi a quella pagina, sta usando HTTPS.

Anche chi scarica la posta con Outlook o Windows Mail, spesso, usa SSL. Molti provider di posta moderni, infatti, richiedono che Outlook/Windows Mail scarichi ed invii la posta crittando il traffico.

Anche quelli più fissati per la navigazione criptata, volenti o nolenti, usano SSL. La rete Tor, quella su cui si poggia il famoso TorBrowser, è costituita da collegamenti criptati con questa tecnologia.

Ma che cos’è in pratica, HeartBleed?

Brevissimi cenni di crittografia

Prima di spiegare conseguenze e rimedi della falla, spiego molto brevemente cos’è la crittografia.

Tutte le informazioni manipolate dai sistemi informatici sono dei numeri, anche quando sono in chiaro. Sì, magari noi le vediamo come immagini e caratteri alfabetici. Di contro, “lì sotto”, ci sono sempre e solo numeri.

Cosa vuol dire, in pratica, criptare una di queste informazioni? Vuol dire:

  • prendere il numero corrispondente;
  • elevarlo ad un certo esponente (chiamato chiave pubblica);
  • dividere il risultato per un certo numero, uguale per tutti.

Il resto di questa divisione è l’informazione criptata.

Cosa vuol dire decrittare? Vuol dire:

  • prendere il resto di prima, cioè l’informazione criptata;
  • elevarlo ad un altro esponente (chiamato chiave privata), avente determinate relazioni matematiche con l’esponente di prima;
  • dividere il risultato per lo stesso numero di prima;
  • prendere il resto.

Se le proprietà matematiche sopra citate sono soddisfatte, il resto di quest’ultima divisione è esattamente il numero originale (cioè l’informazione originale).

La sicurezza di tutto questo meccanismo sta nel fatto che, anche se la chiave pubblica è nota, calcolare la chiave privata, cioè il numero che soddisfa le proprietà matematiche sopra citate, richiede qualche anno di calcoli, rendendo obsolete le informazioni criptate raccolte nel frattempo. Questo fatto, in realtà, mi porta ad aprire una parentesi, che chiuderò immediatamente: per quanto tempo desidero che una certa informazione privata o personale rimanga riservata? Pochi mesi? Pochi anni? Tanti anni? Dalla risposta, dovrebbe conseguire una politica di rinnovamento chiavi e/o password con tempistiche appropriate. Fine parentesi.

Tornando al discorso originale: quando una compagnia mette in piedi un sito o un servizio, e desidera criptare il traffico, non può scegliere due esponenti a caso ed usarli come chiavi. Deve rivolgersi ad un’autorità di certificazione, cioè una società esterna, che:

  • generi la coppia di chiavi, chiamata certificato;
  • dichiari di essere l’emettitrice della coppia di chiavi;
  • si faccia garante del fatto che, ad una certa chiave pubblica, corrisponde la società che vuole criptare il sito/servizio.

 

Funzionamento normale di una connessione HTTPS

Il contenuto di questa sezione può essere esteso, a parte pochi dettagli, a tutti i casi in cui è solo il server a dover dimostrare la propria identità.

Per spiegare bene ciò che intendo, faccio sempre l’esempio della pagina di login, che tipicamente è raggiungibile ad un indirizzo che inizia per https:// (ad esempio, https://www.facebook.com ).

Quando mi connetto ad https://www.facebook.com, il fatto usare OpenSSL per connettermi ad un sito per il quale è stato richiesto un certificato mi dà la garanzia che io mi sto connettendo realmente al server di Facebook, e non a qualcun altro che ne ha rubato l’identità.

Di contro, il server di Facebook non sa nulla di me. O meglio, sa qualcosa di me solo dopo che mi sono loggato. In un meccanismo di mutua autenticazione, invece, il server di Facebook sarebbe in grado di identificarmi (o meglio, identificare il mio computer) già prima che io mi logghi, con la certezza ragionevole (vi rammento la riflessione sulla politica di cambio chiave/password periodica) che si tratti esattamente del mio computer, e non un dispositivo che ne mima il comportamento.

La tipica connessione HTTPS, però, come dicevo, fa parte del primo tipo di connessione: solo il server garantisce la propria identità, mentre sul client non si sa nulla. Ora, cosa accade?

Nel momento in cui, nell’indirizzo, c’è scritto https://, il mio browser sa che, prima di contattare il sito, deve aprire una connessione SSL. Di conseguenza:

  • il browser apre la connessione SSL;
  • il server, per farla semplice, risponde con la chiave pubblica e con l’identificativo dell’autorità di certificazione;
  • il browser riconosce l’identificativo dell’autorità di certificazione, quindi si fida della chiave pubblica ottenuta, e può prendere per certo il fatto che sta parlando realmente con Facebook;
  • Di conseguenza, comincia a chiedere i contenuti del sito. Non lo fa, però, in chiaro. Ogni richiesta viene criptata usando come esponente la chiave pubblica del server. Tra le richieste ci sono, ad esempio, quella di mostrare l’home page, tipicamente corredata da username e password del richiedente;
  • il server riceve le informazioni criptate e le decritta con la chiave privata. Se sono username e password, e se il browser ha richiesto l’home page, il server risponde con la home page del servizio. Non mi dilungo sul modo in cui viene criptata la risposta.

Meccanismo di Heartbeat

Mentre noi utenti leggiamo la home page del servizio, smettiamo di inviare richieste al server. La connessione SSL alla base, invece, nella maggior parte dei casi, è configurata per rimanere sempre attiva. Di conseguenza, in assenza di click dell’utente, il browser invia dei pacchetti, per due motivi:

  • per assicurarsi che il server sia ancora “vivo” e
  • per dire al server che anche lui è ancora pronto a connettersi.

Questo meccanismo, chiamato “Heartbeat” (battito cardiaco), consiste nell’invio di “parole” casuali al server. Il server, se è “vivo”, risponde con la stessa parola, a mo’ di eco. Ad esempio, il browser invia la parola “ehi”. La richiesta reale assomiglia più a qualcosa del tipo: (“ehi”, 3), dove “3” è la lunghezza della parola inviata. Il server, quindi, se è “vivo”, risponde con (“ehi”, 3).

Non mi dilungo sul motivo tecnico per cui è necessario specificare la lunghezza della parola. E’ roba per informatici come me, ai quali consiglio questo link, che riporta appieno le spiegazioni tecniche del bug: http://blog.cryptographyengineering.com/2014/04/attack-of-week-openssl-heartbleed.html

Descrizione della falla di sicurezza

Il client chiede al server di ripetere una parola, indicandogliene anche la lunghezza. Se, però, la lunghezza indicata è maggiore della lunghezza reale, il server risponde con la parola, più il contenuto dell'area di memoria contigua, fino al raggiungimento della lunghezza indicata

Spiegazione HeartBleed

In che cosa consiste la falla di sicurezza? Il fumetto precedente, raggiungibile a questo link ( http://m.xkcd.com/1354/ ) è estremamente esplicativo; in ogni caso, a scopo di massima chiarezza, vi accompagno nella lettura.

Il trucco, purtroppo banale, consiste nel chiedere al server una parola e di specificare una lunghezza più alta del reale. Ad esempio, gli chiediamo (“ehi”, 640). Così facendo, il server comincia a “parlare troppo”.

Cosa vuol dire “parlare troppo”? Quando il server riceve la parola da ripetere, la posiziona in una zona della sua memoria, in attesa di ripeterla al client. Se viene indicata una lunghezza maggiore del reale, il server invia al client la parola, più il contenuto della porzione di memoria contigua, fino al raggiungimento della lunghezza indicata (con un valore totale massimo di 65535).

Cosa c’è in questa memoria contigua? Non lo si può sapere a priori, perché OpenSSL supporta 70 piattaforme diverse, ed ognuna gestisce la memoria in modo diverso.

Nella peggiore delle ipotesi, in quella porzione di memoria sono salvate la chiave pubblica e la chiave privata del server.

Di conseguenza, il client si vede arrivare l’informazione più preziosa e riservata di quel server, cioè la chiave privata. Questa fuoriuscita è talmente grave da indurre gli scopritori a chiamare il bug “HeartBleed” (storpiatura di “Heartbeat”), cioè “emorragia cardiaca”.

Domanda da programmatore (non-programmatori, potete saltare questo pezzo a pié pari): ma in una situazione del genere, non dovrei vedermi sbattere in faccia un bel segmentation fault, come succede a me ogni volta che sbaglio a gestire la terminazione di stringa? Domanda sensatissima. La risposta la dà Theo de Raadt qui: http://article.gmane.org/gmane.os.openbsd.misc/211963.
Come si vede, OpenSSL wrappa la malloc(), a causa della cattive performance di questa chiamata di sistema su alcune piattaforme, disabilitandone anche il bound control e, in generale, il controllo sulle porzioni di memoria allocata.

Conseguenze

Quali sono le conseguenze?

Un client in possesso della chiave privata di un server è in grado di decrittare tutte le comunicazioni in entrata a quel server.

La cosa peggiore è che una falla del genere non lascia traccia. Vale a dire, non c’è modo di sapere se un server ha subito questo prelievo di informazioni.

Di conseguenza, l’unica politica di sicurezza degna di questo nome è assumere che tale prelievo sia avvenuto e che ci sia qualcuno in grado di decrittare i nostri messaggi.

Rimedi per chi gestisce dei server

Anche se non siete gestori di server, ma semplici utenti, leggete lo stesso, perché così capite quali sono i doveri di chi gestisce le vostre informazioni private e i vostri account.

Qual è il rimedio?

Per quanto riguarda le vecchie informazioni transitate, una politica seria di sicurezza impone al gestore di assumerle già decriptate e “rubate”. Di conseguenza, non possono più essere sottratte all’eventuale “spione”.

Per quanto riguarda le informazioni che transiteranno in futuro, invece, ci si può tutelare.

Aggiornamento di OpenSSL

Il primo passo è installare l’aggiornamento OpenSSL sul server, per la precisione la versione 1.0.1g.

Non appena è stata individuata questa falla, infatti, gli sviluppatori di questa libreria hanno provveduto a “tapparla”, rilasciando immediatamente l’aggiornamento. Installare l’aggiornamento di OpenSSL, quindi, mette i gestori di server al riparo da futuri prelievi di chiave. Di contro, se la chiave è stata già prelevata, come bisogna assumere in una politica di sicurezza degna di questo nome, il traffico del server è ancora spiabile.

Revoca vecchio certificato e richiesta nuovo certificato

Una volta tappata la falla, quindi, bisogna cambiare chiave privata, in modo da criptare il traffico con un altro esponente, impedendo all’eventuale “ladro di informazioni” di spiare il server con la vecchia chiave privata.

Nella pratica, “cambiare chiave” equivale a:

  1. Rivolgersi all’autorità di certificazione;
  2. Revocare il vecchio certificato, cioè dichiarare invalida la vecchia coppia <chiave pubblica, chiave privata>;
  3. Richiedere un nuovo certificato, cioè una nuova coppia di chiavi;
  4. Installare sul server il nuovo certificato

Rimedi per gli account personali

Finora ho parlato di chi gestisce. Cosa deve fare, invece, colui che ha un account da qualche parte, sia esso di Google, di Twitter, di Facebook, di gioco, e chi più ne ha più ne metta?

Ogni singola persona, infatti, per tutelarsi, dovrebbe applicare a se stessa una politica di sicurezza come quella indicata.

Se ci fate caso, quasi tutti i siti su cui ci logghiamo hanno una schermata di login protetta con HTTPS. Di conseguenza, anche loro, molto probabilmente, sono stati soggetti all’attacco HeartBleed. Anzi, più informazioni critiche/private contengono, più è facile che siano stati attaccati. Di conseguenza, come abbiamo detto nella sezione dei server, in assenza di tracce di intrusione, bisogna assumere che quei servizi siano stati attaccati.

Quindi:

  1. in prima battuta, bisogna informarsi per capire se i gestori dei servizi presso cui abbiamo un account hanno già provveduto ad aggiornare l’infrastruttura di crittografia;
  2. poi, visto che, tra le informazioni che potrebbero essere state spiate grazie alla falla, potrebbero esserci le nostre password:
    1. se i gestori del servizio non hanno aggiornato i server, bisogna disattivare l’account, per evitare qualsiasi uso indesiderato;
    2. se, invece, i gestori del servizio hanno aggiornato i loro server, bisogna cambiare la password del proprio account su quel server.


Nel caso di modifica della password, questa può essere l’occasione per abituarsi ad un meccanismo di login ancora più sicuro: l’autenticazione in due passi.

Io la uso ovunque essa sia a disposizione: consiste nel loggarsi normalmente, con username e password e poi, su richiesta del sito, inserire un codice di conferma, che viene inviato per SMS, o che viene fornito da un’app di autenticazione da installare sul proprio smartphone. Quest’app si chiama Authenticator, almeno per i dispositivi con Android e può essere usata per securizzare gli account Google, gli account Microsoft, gli account Facebook e, wow, anche l’account WordPress di questo blog. La lista è limitata alle mie sole conoscenze attuali, quindi i servizi securizzabili tramite quest’app potrebbero essere molti di più.

Annunci
Questa voce è stata pubblicata in Scienza, Uncategorized e contrassegnata con , , , , , , . Contrassegna il permalink.

3 risposte a HeartBleed: origine, spiegazione e rimedi

  1. Salvatore Capolupo ha detto:

    Approfondimento davvero splendido e molto chiaro, complimenti.

    Anch’io avevo discusso questo tema sul mio blog, in termini molto più semplici peraltro. Ciao e grazie 🙂

    • mastrotux ha detto:

      Il tuo è di lettura decisamente più facile. Io, purtroppo, non riesco a resistere alla tentazione di “evangelizzare tecnicamente” i possibili lettori, e di renderli coscienti dei dettagli.

  2. Pingback: Spiegazione Heartbleed dettagli tecnici esempio di attacco con Nmap e Metasploit | Tech Inquiry Blog

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...