Innanzitutto , prima di andare fuori di testa, assicurati di capire se questa vulnerabilità si applica effettivamente a te. Se hai un server, ma in realtà non hai mai avuto applicazioni che utilizzano TLS, questa non è una cosa prioritaria da risolvere. Se, d'altra parte, hai mai avuto applicazioni abilitate per TLS, beh, allora sei pronto per una sorpresa. Continuare a leggere:
Che cos'è esattamente CVE-2014-0160 alias "Heartbleed"?
È un gran casino, ecco cos'è. In breve, una vulnerabilità sfruttabile in remoto è stata scoperta nelle versioni OpenSSL da 1.0.1 a 1.0.1f attraverso le quali un utente malintenzionato può leggere determinate parti della memoria di sistema. Tali parti sono quelle che contengono tra l'altro dati sensibili come chiavi private, chiavi già condivise, password e dati aziendali di alto valore.
Il bug è stato scoperto in modo indipendente da Neel Mehta di Google Security (21 marzo 2014) e dalla società finlandese di test di sicurezza IT Codenomicon (2 aprile 2014).
Qual è la causa?
Bene, codice errante in OpenSSL. Ecco il commit che ha introdotto la vulnerabilità, ed ecco il commit che ha risolto la vulnerabilità. Il bug è apparso nel dicembre del 2011 ed è stato corretto oggi, 7 aprile 2014.
Il bug può anche essere visto come un sintomo di un problema più grande. I due problemi correlati sono (1) quale processo è in atto per garantire che il codice errante non sia introdotto in una base di codice e (2) perché i protocolli e le estensioni sono così complessi e difficili da testare. L'articolo (1) è un problema di governance e di processo con OpenSSL e molti altri progetti. Molti sviluppatori semplicemente resistono a pratiche come la revisione del codice, l'analisi e la scansione. Il punto (2) è in discussione nel WG TLS dell'IETF. Vedi complessità Heartbleed / protocollo .
Il codice errante è stato inserito in modo pericoloso?
Non speculerò sul fatto che questo sia stato davvero un errore o forse un po 'di codice inserito per conto di un cattivo attore. Tuttavia, la persona che ha sviluppato il codice per OpenSSL afferma che è stato involontario. Vedi l' uomo che ha introdotto un grave difetto di sicurezza "Heartbleed" nega di averlo inserito deliberatamente .
Quali sistemi operativi e versioni di OpenSSL sono vulnerabili?
Come accennato in precedenza, qualsiasi sistema operativo che sta utilizzando o un'applicazione collegata a OpenSSL da 1.0.1 a 1.0.1f.
Quali sono i sintomi, esistono metodi per rilevare un exploit di successo?
Questa è la parte spaventosa. Per quanto ne sappiamo, non esiste un modo noto per rilevare se questa vulnerabilità è stata sfruttata o meno. È teoricamente possibile che presto saranno rilasciate firme IDS in grado di rilevare questo exploit, ma al momento della stesura di queste, quelle non sono disponibili.
Ci sono prove che Heartbleed è stato attivamente sfruttato in natura già nel novembre 2013. Vedi il Wild 's Heart di EFF : le agenzie di intelligence stavano usando Heartbleed nel novembre 2013? E Bloomberg riferisce che l'NSA aveva armato l'exploit poco dopo l'introduzione della vulnerabilità. Vedere NSA ha detto di sfruttare bug Heartbleed per intelligenza per anni . Tuttavia, la US Intelligence Community nega le affermazioni di Bloomberg. Vedi IC ON THE RECORD .
Come posso verificare se il mio sistema è interessato?
Se stai mantenendo OpenSSL sul tuo sistema, puoi semplicemente emettere openssl version:
$ openssl version
OpenSSL 1.0.1g 7 Apr 2014
Se la distribuzione è mantenere OpenSSL, allora probabilmente non può determinare la versione di OpenSSL a causa di tornare patch utilizzando opensslcomandi o le informazioni del pacchetto (ad esempio, apt-get, dpkg, yumo rpm). Il processo di back patching utilizzato dalla maggior parte (tutte?) Delle distribuzioni utilizza solo il numero di versione di base (ad esempio "1.0.1e"); e non include una versione di sicurezza efficace (ad esempio "1.0.1g").
C'è una domanda aperta su Super User per determinare la versione di sicurezza efficace per OpenSSL e altri pacchetti quando i pacchetti vengono sottoposti a backpatch. Sfortunatamente, non ci sono risposte utili (oltre a controllare il sito web della distro). Vedere Determinare la versione di sicurezza effettiva di fronte al backpatching ?
Come regola generale: se hai mai installato una delle versioni interessate e hai mai eseguito programmi o servizi collegati a OpenSSL per il supporto TLS, sei vulnerabile.
Dove posso trovare un programma per verificare la vulnerabilità?
A poche ore dall'annuncio Heartbleed, diverse persone su Internet avevano pubblicizzato applicazioni Web accessibili al pubblico che presumibilmente potevano essere utilizzate per controllare la presenza di questa vulnerabilità su un server. Al momento della stesura di questo documento, non ne ho esaminato nessuno, quindi non pubblicizzerò ulteriormente le loro domande. Possono essere trovati relativamente facilmente con l'aiuto del tuo motore di ricerca preferito.
Come viene mitigata questa vulnerabilità?
Eseguire l'aggiornamento a una versione non vulnerabile e reimpostare o proteggere nuovamente i dati vulnerabili. Come notato sul sito Heartbleed , i passaggi di risposta appropriati sono in generale:
- Patch sistemi vulnerabili.
- Rigenera nuove chiavi private.
- Invia nuovo CSR alla tua CA.
- Ottieni e installa un nuovo certificato firmato.
- Chiavi e cookie di sessione non validi
- Reimposta password e segreti condivisi
- Revoca i vecchi certificati.
Per un'analisi e una risposta più dettagliate, vedere Cosa dovrebbe fare un operatore del sito Web in merito all'exploit di Heartbleed OpenSSL? sullo scambio dello stack di sicurezza.
Dovrei preoccuparmi che le mie chiavi o altri dati privati siano stati compromessi? Di quali altri effetti collaterali dovrei preoccuparmi?
Assolutamente. Gli amministratori di sistema devono presumere che i loro server che hanno utilizzato versioni vulnerabili di OpenSSL siano effettivamente compromessi e rispondano di conseguenza.
Poco dopo la divulgazione della vulnerabilità, Cloudfare ha offerto una sfida per vedere se la chiave privata di un server potesse essere recuperata in pratica. La sfida è stata vinta in modo indipendente da Fedor Indutny e Ilkka Mattila. Vedi The Heartbleed Challenge .
Dove posso trovare maggiori informazioni?
Link dump, per chi cerca maggiori dettagli:
Una cronologia piuttosto dettagliata degli eventi di divulgazione è disponibile nella cronologia di divulgazione Heartbleed: chi sapeva cosa e quando .
Se sei un programmatore e sei interessato a vari trucchi di programmazione come il rilevamento di un attacco Heartbleed attraverso il msg_cbcallback di OpenSSL , allora consulta l' Advisory Security 2014047 di OpenSSL .
