Questa vulnerabilità ha un potenziale impatto elevato perché se il tuo sistema è stato attaccato, rimarrà vulnerabile anche dopo l'applicazione di patch e gli attacchi potrebbero non aver lasciato alcuna traccia nei log. È probabile che se hai patchato rapidamente e non sei un bersaglio di alto profilo, nessuno sarà riuscito ad attaccarti, ma è difficile esserne sicuri.
Sono vulnerabile?
La versione buggy di OpenSSL
Il software difettoso è la libreria OpenSSL 1.0.1 fino alla 1.0.1f e OpenSSL 1.0.2 fino alla beta1. Le versioni precedenti (0.9.x, 1.0.0) e le versioni in cui il bug è stato corretto (1.0.1g in poi, 1.0.2 beta 2 in poi) non sono interessate. È un bug di implementazione, non un difetto nel protocollo, quindi solo i programmi che usano la libreria OpenSSL sono interessati.
È possibile utilizzare lo strumento da riga di comando openssl version -aper visualizzare il numero di versione di OpenSSL. Si noti che alcune distribuzioni portano la correzione di bug a versioni precedenti; se il registro delle modifiche del tuo pacchetto menziona la correzione di bug Heartbleed, va bene, anche se vedi una versione come 1.0.1f. Se openssl version -amenziona una data di costruzione (non la data sulla prima riga) del 07-04-2014 intorno alla sera UTC o successiva, dovresti andare bene. Si noti che il pacchetto OpenSSL potrebbe avere il 1.0.0suo nome anche se la versione è 1.0.1 (si 1.0.0riferisce alla compatibilità binaria).
Applicazioni interessate
Lo sfruttamento viene eseguito tramite un'applicazione che utilizza la libreria OpenSSL per implementare connessioni SSL . Molte applicazioni usano OpenSSL per altri servizi di crittografia, e questo va bene: il bug sta nell'implementazione di una particolare funzionalità del protocollo SSL, il "battito cardiaco".
Potresti voler controllare quali programmi sono collegati alla libreria sul tuo sistema. Sui sistemi che usano dpkg e apt (Debian, Ubuntu, Mint, ...), il seguente comando elenca i pacchetti installati diversi dalle librerie che usano libssl1.0.0(il pacchetto interessato):
apt-cache rdepends libssl1.0.0 | tail -n +3 |
xargs dpkg -l 2>/dev/null | grep '^ii' | grep -v '^ii lib'
Se esegui un software server presente in questo elenco e ascolta le connessioni SSL, probabilmente sei interessato. Ciò riguarda i server Web, i server di posta elettronica, i server VPN, ecc. Saprai che hai abilitato SSL perché dovevi generare un certificato, inviando una richiesta di firma del certificato a un'autorità di certificazione o facendo autofirmato certificato. (È possibile che alcune procedure di installazione abbiano generato un certificato autofirmato senza che te ne accorga, ma generalmente viene eseguito solo per server interni, non per server esposti a Internet.) Se hai eseguito un server vulnerabile esposto a Internet, consideralo compromesso a meno che i log non mostrino alcuna connessione dall'annuncio del 07-04-2014. (Ciò presuppone che la vulnerabilità non sia stata sfruttata prima del suo annuncio.) Se il tuo server è stato esposto solo internamente,
Il software client è interessato solo se è stato utilizzato per connettersi a un server dannoso. Quindi, se ti sei connesso al tuo provider di posta elettronica tramite IMAPS, non devi preoccuparti (a meno che il provider non sia stato attaccato, ma in tal caso dovrebbero farti sapere), ma se hai navigato in siti Web casuali con un browser vulnerabile, potresti aver bisogno preoccuparsi. Finora sembra che la vulnerabilità non sia stata sfruttata prima che fosse scoperta, quindi devi preoccuparti solo se ti sei connesso a server dannosi dal 2014-04-08.
I seguenti programmi non sono interessati poiché non utilizzano OpenSSL per implementare SSL:
- SSH (il protocollo non è SSL)
- Chrome / Chromium ( utilizza NSS )
- Firefox (usa NSS) (almeno con Firefox 27 su Ubuntu 12.04, ma non con tutte le build?
Qual è l'impatto?
Il bug consente a qualsiasi client in grado di connettersi al server SSL di recuperare contemporaneamente 64 KB di memoria dal server. Non è necessario che il client sia autenticato in alcun modo. Ripetendo l'attacco, il client può scaricare diverse parti della memoria in tentativi successivi. Ciò consente potenzialmente all'attaccante di recuperare tutti i dati presenti nella memoria del processo del server, inclusi chiavi, password, cookie, ecc.
Uno dei dati critici che l'attaccante potrebbe essere in grado di recuperare è la chiave privata SSL del server. Con questi dati, l'attaccante può impersonare il tuo server.
Il bug consente inoltre a qualsiasi server a cui si è connesso il client SSL di recuperare alla volta circa 64 KB di memoria dal client. Questa è una preoccupazione se hai usato un client vulnerabile per manipolare dati sensibili e successivamente ti sei connesso a un server non attendibile con lo stesso client. Gli scenari di attacco da questo lato sono quindi significativamente meno probabili rispetto al lato server.
Si noti che per le distribuzioni tipiche, non vi è alcun impatto sulla sicurezza sulla distribuzione dei pacchetti poiché l'integrità dei pacchetti si basa sulle firme GPG, non sul trasporto SSL.
Come riparo la vulnerabilità?
Risanamento di server esposti
Porta offline tutti i server interessati. Finché sono in esecuzione, stanno potenzialmente perdendo dati critici.
Aggiorna il pacchetto della libreria OpenSSL . Ormai tutte le distribuzioni dovrebbero avere una correzione (o con 1.0.1g, o con una patch che corregge il bug senza cambiare il numero di versione). Se hai compilato dal sorgente, esegui l'upgrade a 1.0.1 go superiore. Assicurarsi che tutti i server interessati siano riavviati.
Su Linux, puoi verificare se i processi potenzialmente interessati sono ancora in esecuzionegrep 'libssl.*(deleted)' /proc/*/maps
Genera nuove chiavi . Ciò è necessario perché il bug potrebbe aver consentito a un utente malintenzionato di ottenere la vecchia chiave privata. Segui la stessa procedura che hai usato inizialmente.
- Se si utilizzano certificati firmati da un'autorità di certificazione, inviare le nuove chiavi pubbliche alla propria CA. Quando ottieni il nuovo certificato, installalo sul tuo server.
- Se si utilizzano certificati autofirmati, installarlo sul server.
- In ogni caso, sposta le vecchie chiavi e i certificati (ma non eliminarli, assicurati solo che non vengano più utilizzati).
Ora che hai nuove chiavi senza compromessi, puoi riportare il tuo server online .
Revoca i vecchi certificati.
Valutazione del danno : qualsiasi dato che è stato nella memoria di un processo che serve connessioni SSL potrebbe essere stato trapelato. Ciò può includere password degli utenti e altri dati riservati. È necessario valutare quali potrebbero essere stati questi dati.
- Se stai eseguendo un servizio che consente l'autenticazione con password, le password degli utenti che si sono connessi da poco prima dell'annuncio della vulnerabilità dovrebbero essere considerate compromesse. Controlla i tuoi registri e modifica le password di qualsiasi utente interessato.
- Invalida anche tutti i cookie di sessione, poiché potrebbero essere stati compromessi.
- I certificati client non sono compromessi.
- Tutti i dati scambiati da poco prima della vulnerabilità potrebbero essere rimasti nella memoria del server e quindi potrebbero essere stati divulgati a un utente malintenzionato.
- Se qualcuno ha registrato una vecchia connessione SSL e ha recuperato le chiavi del tuo server, ora può decodificare la sua trascrizione. (A meno che PFS non sia stato garantito - se non lo sai, non lo era.)
Risanamento in altri casi
I server che ascoltano solo su localhost o su una intranet devono essere considerati esposti solo se gli utenti non attendibili possono connettersi a loro.
Con i client, ci sono solo scenari rari in cui il bug può essere stato sfruttato: un exploit richiederebbe di utilizzare lo stesso processo client per
- manipolare dati riservati (ad es. password, certificati client, ...);
- e quindi, nello stesso processo, connesso a un server dannoso su SSL.
Quindi, ad esempio, un client di posta elettronica che usi solo per connetterti al tuo provider di posta (non completamente non attendibile) non è un problema (non un server dannoso). Eseguire wget per scaricare un file non è un problema (non ci sono dati riservati da perdere).
Se lo hai fatto tra il 2014-04-07 sera UTC e l'aggiornamento della tua libreria OpenSSL, considera compromessi tutti i dati presenti nella memoria del client.
Riferimenti