FORSETI BLOG. Readcast. Aprile 2014 Speciale Heartbleed.

Transcript

1 FORSETI BLOG Readcast Aprile 2014 Speciale Heartbleed

2 Indice di 3

3 Forseti Blog - Aprile di Dottore in Sicurezza dei Sistemi e delle Reti Informatiche, Dottore Magistrale in Sicurezza Informatica; entrambe le lauree sono state conseguite presso il Dipartimento di Tecnologie dell Informazione (DTI) dell Università degli Studi di Milano, polo di Crema. Attualmente è dipendente della Consoft Sistemi S.p.A. presso la filiale di Milano. Gli interessi principali, oltre alla sicurezza in sé, sono il mondo Open Source, il diritto d autore e le problematiche legate alla privacy. La settimana si è aperta con una notizia di rilevanza internazionale: OpenSSL ha un bug di sicurezza grave (Heartbleed), che potenzialmente coinvolge 2/3 della rete Internet. Sebbene sia un ambito abbastanza tecnico (e da tecnici ), come da tradizione del blog si cercherà di rendere l argomento più edibile anche per i nostri lettori, soprattutto in virtù della risonanza data all annuncio. Il contesto: SSL SSL (Secure Sockets Layer, letteralmente strato di socket sicuri ) è un protocollo crittografico utilizzato per rendere sicure (le virgolette sono d obbligo) le comunicazioni sulla Rete. In poche parole, si occupa di cifrare la comunicazione, in modo che eventuali attaccanti non siano in grado di comprenderne il contenuto. Molti siti Web usano TLS/SSL (che in questo articolo, per semplicità, consideriamo analoghi - si tratta in realtà di due protocolli diversi, ma SSL è predecessore di TLS), e sono riconoscibili dall icona di un lucchetto nella barra degli indirizzi (oltre che dalla specifica di protocollo HTTPS anziché HTTP). Il protocollo richiede una serie di scambi di informazioni preliminari tra client e server, in modo che ciascuno dei due riconosca l altro come legittimo e in seguito possa cifrare la comunicazione, sapendo che le informazioni rilasciate finiranno in buone mani. In particolare, l handshake (lo scambio iniziale di informazioni, dall inglese stretta di mano, che è anche l unica parte di comunicazione in chiaro) avviene in questo modo: 1. Il client (che inizia la comunicazione) invia al server una serie di informazioni necessarie per le fasi successive, quali la versione di TLS/SSL utilizzata. 2. Il server risponde con le medesime informazioni, più il proprio certificato; se la sessione richiede mutua autenticazione, richiede il certificato al client. 3. Il client verifica il certificato. Se risulta valido, procede con il prossimo passo; altrimenti, l utente riceve una notifica dell impossibilità di proseguire con una comunicazione cifrata e il protocollo si interrompe. 4. Il client genera una prima chiave (pre-master secret) e la invia al server, cifrata con la chiave pubblica ricevuta insieme al certificato del server. 5. Se è richiesta mutua autenticazione, il client firma un ulteriore insieme di dati unici per la comunicazione in corso, e la invia al server insieme al proprio certificato. 6. Se è richiesta mutua autenticazione, il server procede come il client nel punto 3. Se il certificato del client è valido, entrambi generano la chiave principale (master secret), a partire dal premaster secret.

4 4 Forseti Blog - Aprile Entrambi i partecipanti, usando il master secret, generano la chiave (simmetrica, quindi uguale per entrambi) di sessione. 8. Il client notifica al server la fine dell handshake; la prossima comunicazione sarà cifrata. 9. Il server notifica al client la fine dell handshake; può iniziare la sessione sicura. In questo protocollo si utilizzano sia la crittografia simmetrica (stessa chiave per entrambi) che quella asimmetrica (chiave pubblica e chiave privata, diverse): la crittografia simmetrica è estremamente più rapida, ma c è bisogno di concordare la chiave da utilizzare e verificare l identità dei due attori; per questo si usa anche la crittografia asimmetrica. Nel corso della sessione cifrata, possono avvenire disconnessioni temporanee o eventi esterni, che possono richiedere la possibilità di rinegoziazione (la ripetizione dell handshake sopra descritto); può anche essere necessario verificare la presenza in linea della controparte. In questo secondo caso, in cui è comparsa la vulnerabilità, il server e il client si scambiano un pacchetto appositamente costruito, denominato heartbeat (battito cardiaco), in una sorta di botta e risposta. Heartbeat e heartbleed I pacchetti di tipo heartbeat o che svolgono le medesime funzioni prevedono generalmente uno scambio rapido, e in informatica questo significa effettuare il minor numero di calcoli possibile. Nel caso di OpenSSL, è previsto semplicemente che la risposta abbia lo stesso contenuto della richiesta. Come in molti protocolli pensati per la rete, i pacchetti SSL hanno uno header (testata) e un contenuto; nello header è riportata, tra gli altri dati, la lunghezza del contenuto. La vulnerabilità risiede proprio nel rapporto tra lunghezza dichiarata nello header e dimensione effettiva del contenuto. Per un banale quanto pericoloso errore di programmazione, anche se qualcuno sostiene sia stato inserito di proposito, all atto della risposta non era verificata la corrispondenza tra lunghezza dichiarata nello header e dimensioni del contenuto. Un attaccante (A) può sfruttare la vulnerabilità, ad esempio, inviando una richiesta heartbeat con lunghezza dichiarata di 64 KB (il massimo consentito dal protocollo), mentre il contenuto del pacchetto è in realtà di solo un byte. La macchina attaccata (B) per comprendere il messaggio deve salvarlo in memoria e leggerlo. Una volta che ha capito che si tratta di un heartbeat, teoricamente dovrebbe inviare il medesimo contenuto alla macchina A; a causa dell errore sopra citato, invece, invia un pacchetto il cui contenuto ha la lunghezza dichiarata nello header (64 KB), recuperando i dati mancanti dalle celle di memoria immediatamente successive. Tali celle contengono informazioni in corso di elaborazione da parte del computer. Il grosso problema è che sulla memoria di una macchina ci può essere qualsiasi cosa, da una porzione della fotografia che stiamo stampando alla password che abbiamo appena inserito per accedere al nostro conto bancario online. Da qui deriva il grande allarme generato dalla notizia: di fatto, tutti i dati trattati dalla macchina B del nostro esempio possono essere compromessi. Considerazioni Per esaminare la pericolosità dell attacco, ci si concentrerà di seguito sui fattori che aumentano o diminuiscono l impatto di un possibile attacco. Fattori mitiganti L attaccante non può scegliere quale porzione di memoria ricevere, quindi non sa a priori se essa conterrà informazioni interessanti.

5 Forseti Blog - Aprile Tutti i pacchetti di una connessione SSL, compreso l heartbeat, sono cifrati con una chiave segreta non nota dall attaccante. L errore non è presente nel protocollo di per sé, ma solo in una delle sue numerose implementazioni. Il bug è stato corretto e pubblicizzato in breve tempo dalla sua scoperta. Fattori aggravanti L area di memoria restituita potrebbe contenere dati estremamente sensibili o segreti. Se inviato durante l handshake iniziale, l heartbeat non è cifrato. Non è possibile individuare un attacco a posteriori, perché gli heartbeat non sono loggati. Il bug è rimasto latente per circa due anni, ed è presente su diverse versioni di OpenSSL (dalla alla 1.0.1f, più la beta). La libreria OpenSSL è utilizzata di default sui principali web server e sistemi operativi (per server), a livello mondiale. Non è un caso se le cattive notizie sono state inserite per ultime. Il bug rimane estremamente pericoloso (secondo Bruce Schneier, guru della sicurezza informatica, in una scala di pericolosità crescente da 1 a 10 questo problema ha valore 11) ed ha coinvolto i principali attori del Web (come Yahoo!, Twitter, GitHub, Tumblr, DropBox), e non si può avere la garanzia che tutti i siti (anche quelli meno conosciuti o visitati) che utilizzano HTTPS abbiano già provveduto ad aggiornare OpenSSL. Inoltre, come ci ricorda sempre Bruce Schneier, Heartbleed potrebbe coinvolgere sistemi embedded (con il software strettamente legato all hardware), che non sono facilmente aggiornabili. Consigli Una buona notizia è che sia i principali sistemi operativi client, cioè Windows e Mac OS, di per sé non sono affetti da questo bug perché non utilizzano OpenSSL. Lo stesso vale per i browser Chrome (versione desktop) e Firefox. Tuttavia, alcune applicazioni che si connettono ad Internet potrebbero utilizzare OpenSSL. In generale, per l utente base è possibile che i vostri dati (ma, visto quanto detto sopra, difficilmente le vostre password) siano stati ricavati dalla memoria dei server di alcuni dei siti Web che comunemente visitate: una buona misura di protezione è verificare se questi siti siano (ancora) vulnerabili (ad esempio, digitandone l indirizzo su quindi visualizzare il certificato e verificare la data di rilascio. Se il sito risulta non vulnerabile e il certificato è stato rilasciato dopo il 7 aprile 2014, è opportuno (e sicuro) cambiare la propria password.

6 Associazione FORSETI via Camillo Benso Conte di Cavour, VARESE (VA) CC BY: $\ Documento rilasciato con licenza Creative Commons BY-NC