Antivirus e sicurezza

Heartbleed Bug

11 Aprile 2014

Il 7 aprile 2014 è stata scoperta una vulnerabilità 0-day estremamente critica che, secondo le stime, mette a rischio due terzi dell’intero web. Anche colossi come Yahoo sono coinvolti.


Heartbleed

Il problema riguarda OpenSSL, ossia l’implementazione open-source delle librerie per la gestione del Secure Socket Layer: in pratica è il software che viene usato da tutti i siti che utilizzano il webserver Apache e il protocollo HTTPS.
 
Il termine “sito” ha in questo caso l’accezione più vasta: comprende infatti qualunque dispositivo raggiungibile via web, sia esso un server, un firewall, un server di VPN o un NAS.
 
Cosa comporta questa vulnerabilità?
 
In sostanza, un aggressore può usarla per raccogliere dati sensibili, chiavi di crittografia e password dai sistemi interessati.

Il problema riguarda l’implementazione nella funzionalità Heartbeat TLS / DTLS in tutte le versioni di OpenSSL dalla 1.0.1 alla 1.0.1f: per questo, con una colorita metafora, è stato chiamato Heartbleed Bug, che suona come “bug del cuore che sanguina”.

Si noti che il codice exploit che sfrutta questa vulnerabilità è pubblicamente disponibile. Ulteriori dettagli possono essere trovati nel bollettino CERT/CC Vulnerability Note VU#720951.

Tutti i produttori di sistemi che usano la libreria OpenSSL si sono messi al riparo (o ci si stanno mettendo) attraverso il rilascio di nuove versioni delle applicazioni che usino OpenSSL 1.0.1g, versione imune al problema e già disponibile.

Quindi il consiglio è aggiornare prima possibile.

E’ da sottolineare che qualunque chiave generata da una versione vulnerabile di OpenSSL deve essere considerata compromessa, e quindi rigenerata dopo l’installazione della patch.

Qualora questo non sia possibile a breve giro, si consiglia l’implementazione della Perfect Forward Secrecy per diminuire il danno causato dalla compromissione delle chiavi.

Per verificare se i sistemi sono interessati dal problema, sono disponibili test online. Eccone alcuni: 
E’ sufficiente inserire l’indirizzo pubblico del server da testare (compresa la porta, se non standard).
Autore
Furio Borsi
Si appassiona al mondo digitale fin da bambino, con il glorioso Commodore 64, sul quale si diverte a scrivere semplici programmi in Basic e modificare giochi. Nel 1990 riceve in regalo il suo primo PC (i386), seguito un paio d'anni dopo da un i486dx. In questi anni affina le sue attitudini al problem solving, scassando hardware e software e divertendosi a rimetterlo a posto. ;) Diventa così "quello che se ne capisce" per i suoi familiari e amici, arrivando a collaborare con alcuni studi professionali per la gestione del parco macchine e dei server Windows. Finito il liceo, studia DAMS con indirizzo multimediale a Bologna e Imperia. Nel 2002, dopo un anno sabbatico a Londra, lavora come sviluppatore junior in Sig.la, azienda che produce software per database territoriali in ambito Pubblica Amministrazione. In questo periodo si avvicina con passione a problematiche sistemistiche e di network management su reti estese. Nel 2007 entra a far parte dello staff di Achab, per cui si occupa di formazione e supporto, in particolare riguardo a Kaseya, e gestione del parco macchine e della rete.
Commenti (2)

Ciao Emilio,
confermo che questo bug ha avuto una risonanza particolare, probabilmente anche per il nome molto evocativo.

C’è da dire però che raramente ho visto definire una falla "catastrofica" da esperti di sicurezza (Schneier). La differenza è che, mentre altri bug passati (ad esempio ne ricordo uno dell’implementazione OpenSSL di Debian, l’anno scorso) rendevano teoricamente meno "forti" le chiavi segrete, o introducevano delle backdoor, questo permette direttamente la lettura di chiavi password e dati sensibili, visto che si possono richiedere arbitrariamente stringhe di 64KB al server OpenSSL (e come detto anche nell’articolo, l’exploit è liberamente disponibile).

Sfondi una porta aperta poi sul fatto che anche l’SSL di IIS ha avuto e ha ancora problemi (non ultimo il fatto che supporti ancora implementazioni di SSL ritenute non sicure, come SSL 2.0).

Tra l’altro, penso che parlare di falle e possibili conseguenze possa sensibilizzare gli amministratori dei sistemi a non far finta di niente e sperare di essere fortunati, ma a intervenire attivamente per mettere in sicurezza i loro sistemi.

Grazie per il contributo! 😉

Furio Borsi,

Ciao.
Diciamo che è una delle tante, anche i trascorsi del SSL Microsoft non sono immuni da catastrofiche vulnerabilità, per quanto riguarda OpenSSL le vulnerabilità gravi si ripetono con discreta regolarità, ma spesso passano sotto silenzio.
Ho gestito per diversi anni uno dei mirror italiani del prodotto, parliamo ancora delle versione 0.9x con x minore di 6, anche in quei tempi era un continuo rilascio di FIX. Un’altra grave c’è stata nel 2013 o 2012, ma solo i gestori di sistemi ne hanno parlato, non era certo inferiore a quella di quest’anno.
Questo non significa che debba essere presa sotto gamba, anzi l’opposto, ma semplicemente che queste notizie hanno piò o meno eco in base ai periodi storici e alle tendenze di mercato.

Emilio Polenghi,

Lascia un commento

Il tuo indirizzo e-mail non verrà pubblicato, lo utilizzeremo solamente per inviarti la notifica della pubblicazione del tuo commento. Ti informiamo che tutti i commenti sono soggetti a moderazione da parte del nostro staff.