Il nome non è certo dei più rassicuranti e la rappresentazione grafica di questo pericoloso bug informatico che ha minato la sicurezza dei dati di migliaia di utenti a livello globale, lo è ancora meno. Heartbleed può infatti abbattersi su un server nel tempo di un battito e può, potenzialmente, rubarne le informazioni più preziose.
Da cosa è scaturita, in cosa consiste questa vulnerabilità, e cosa è necessario fare se si crede di esserne caduti vittima? Lo abbiamo chiesto al nostro esperto, Fabio Coatti, Chief Security Officier di Dada, che ci ha spiegato non solo come il problema è stato arginato, ma cosa è possibile fare per limitare l’esposizione a rischi informatici di questo tipo, perennemente in agguato.
Heart Bleed: Cos’è?
“Semplicemente una vulnerabilità che si è verificata in una specifica versione di OpenSSL, per la precisione nella 1.0.1. OpenSSL è uno dei “motori” crittografici più frequentemente utilizzati per gestire i protocolli SSL/TLS, ossia per fornire una trasmissione sicura, cifrata e autenticata di dati sul web. Per evitare confusione è importante sottolineare fin da subito che OpenSSL e i Certificati SSL sono cose ben distinte. Per spiegare la differenza tra i due in termini molto semplici, OpenSSL rappresenta il meccanismo che gestisce e che invia il certificato, mentre il certificato è il documento usato da OpenSSL per garantire che il server sia chi dice di essere, un po’ come una carta d’identità. Tale certificato non è soggetto alla vulnerabilità.”
Da cosa è stata generata la vulnerabilità?
“Sostanzialmente da un errore umano. Sebbene circolino varie teorie complottistiche, la versione più credibile per l’esistenza di questo bug è quella di un semplice errore di programmazione. Il protocollo TLS utilizza una funzione chiamata heartbeat per tenere viva la connessione con il server ed evitare di doverla ristabilire tutte le volte. Questa funzione si basa su un dialogo tra client (il browser) ed il server che possiamo immaginare così:
Client: “Server, sei vivo? Rispondi con ciao, 4 caratteri” (heartbeat request’)
Server: “Sì, ci sono, ecco la risposta: ciao” (‘heartbeat response message’)
Il problema è che il server si fida un po’ troppo del client, appunto a causa del bug, e se quest’ultimo fa il “furbo”, chiedendo più caratteri in risposta, può succedere qualcosa del genere:
Client: “Server, sei vivo? Rispondi con ciao, 4000 caratteri”
Server: “Sì, ci sono, ecco la risposta: ciaoXYALBEOSDOS…”
Non avendo abbastanza caratteri nella risposta (solo 4, in effetti) il server recupera gli altri 3996 cercando nella memoria dove di solito tiene i dati scambiati nella comunicazione e quindi probabilmente delicati. In pratica la quantità di dati inviati come messaggio di risposta sarà evidentemente molto più ampia del previsto, con una certa probabilità di contenere dati sensibili come cookies, password, o addirittura chiavi dei certificati SSL che, nelle mani sbagliate, potrebbero essere utilizzate a fini illeciti.Il caso dei cookies è sicuramente quello più interessante. Statisticamente infatti è molto più probabile che un attacco trovi questi ultimi, che sono scambiati di continuo tra client e server, piuttosto che le password, che vengono scambiate solo ad inizio sessione. Un hacker in possesso dei cookies può inserirli sul proprio browser e trovarsi loggato sul servizio vulnerabile con le credenziali dell’utente proprietario dei cookies. Questione diversa è la chiave segreta del certificato. I server usano una chiave segreta per poter attivare una connessione SSL e alla partenza del server viene caricata in memoria. Se l’attacco porta a individuare tale chiave il danno è molto consistente: il possesso di tale chiave permette di decifrare ed intercettare il traffico protetto con il certificato SSL, anche dopo che il server è stato aggiornato con una versione di OpenSSL non vulnerabile. Alcune analisi hanno dimostrato che recuperare la chiave segreta è molto difficile, al contrario dei cookies, ma non impossibile, soprattutto se il server viene fatto ripartire. Tale vulnerabilità non è comunque presente su tutte le versioni di SSL, ma solo sulla 1.0.1 nelle versioni dalla A alla F e solo nel caso in cui la funzione heartbeat sia attivata. Tutte le altre versioni non sono soggette alla vulnerabilità.”
Cosa è possibile fare nel caso in cui questo caso si fosse verificato?
“Se c’è stata compromissione delle credenziali, la correzione del bug ha valore solo da quel momento in poi. Se il materiale segreto è stato perso, il danno è fatto. Detto in altre parole, tutte le password e certificati usati da un server vulnerabile sono da considerarsi compromesse, anche se, ripeto, la probabilità che questo si sia verificato è effettivamente bassa. Inoltre non c’è modo di capire se la vulnerabilità sia stata sfruttata da un attaccante, nei log non rimane infatti traccia di attività anomale. Detto questo, la versione di Open-SSL affetta da questo bug di sicurezza non è l’unica esistente ed è stata già sostituita da una versione sicura.”
Quanti sono stati i siti web affetti da heartbleed?
“Come si può immaginare è una risposta difficile da dare: se per i siti più frequentati le analisi sono state immediate, anche da parte di terzi, non è facile sapere se ci sono siti vulnerabili e poi sistemati senza tanta pubblicità. E’ anche immaginabile che vi siano siti poco frequentati, dimenticati o comunque poco curati ancora in situazione problematica. Secondo Wikipedia, al momento della divulgazione della vulnerabilità circa il 17% (circa mezzo milione) dei server sicuri certificati da autorità di certificazione erano vulnerabili. Da notare che fino a pochi giorni fa quasi l’1% dei 200.000 server più popolari erano ancora vulnerabili.”
Qual è la situazione attuale per i clienti di Register.it?
“In questo momento non esiste alcun rischio per i clienti che utilizzano i nostri server, in quanto abbiamo provveduto immediatamente a controllare i nostri server e ad effettuare le manutenzioni necessarie. Non mi risultano vulnerabilità su server che gestiscono credenziali di utenti. Per massima precauzione abbiamo comunque proceduto a sostituire i certificati ove ci fosse un minimo dubbio di sicurezza. Come dicevo, la probabilità che la chiave fosse stata compromessa è molto bassa, ma attraverso la sua sostituzione il problema è totalmente azzerato.I clienti che si appoggiano sui nostri sistemi possono quindi stare tranquilli: stiamo usando versioni di OpenSSL ritenute al momento sicure. Ovviamente, data la natura di queste vulnerabilità, il monitoraggio è continuo per poter reagire nel minor tempo possibile ad altre minacce. Diversa è la situazione per i clienti che utilizzano i nostri prodotti, ma che non si appoggiano ai nostri server. In questo caso dovrà essere loro cura procedere alla valutazione della situazione ed eventualmente alla sostituzione dei certificati per eliminare qualsiasi rischio.”
Cosa è possibile fare per limitare i rischi derivanti da queste falle di sicurezza informatica?
“In linea generale è fondamentale attenersi ai consigli che diamo sempre ai nostri utenti, relativi soprattutto all’utilizzo delle password. Una vulnerabilità come questa ha avuto molto impatto mediatico, ma all’atto pratico deve essere risolta da chi si occupa della gestione dei server. Va però sottolineato che buona parte degli incidenti di sicurezza sono dovuti a comportamenti dei singoli utenti e l’adozione di alcune semplici misure (che definirei di buon senso) possono ridurre drasticamente i rischi in termini di sicurezza. Innanzitutto è essenziale non utilizzare mai password identiche per siti diversi: è chiaro infatti che in questo caso se un sito viene ‘bucato’, anche gli altri potranno essere colpiti senza difficoltà. Altra cosa da evitare è l’utilizzo di password troppo semplici da identificare o decifrare. La diversificazione nelle chiavi di accesso è il primo aspetto da tenere in considerazione per proteggersi da potenziali rischi. Nel caso in cui la gestione di troppe password diventasse eccessivamente onerosa, è possibile utilizzare software dedicati che permettono di semplificare questo aspetto, detti “password managers”: ce ne sono parecchi per tutte le piattaforme, compresi smatphones e tablet. Il consiglio è quello di usare un motore di ricerca con “Password Manager” e trovare quello più adatto per le proprie esigenze. (ed ovviamente tenendolo aggiornato!!)”
