Come posso risolvere / risolvere la vulnerabilità di SSLv3 POODLE (CVE-2014-3566)?

158

Dopo l'attacco BEAST e Bug heartbleed , ora ho sentito parlare di una nuova vulnerabilità in SSL / TLS chiamata BARBONCINO . Come posso proteggermi dal fatto di essere sfruttato?

  • Sono interessati solo i server o anche i client?
  • Questo OpenSSL / GnuTLS è specifico?
  • Che tipo di servizi sono interessati? Solo HTTPS o anche IMAPS, SMTPS, OpenVPN, ecc.?

Mostrami esempi su come evitare questa vulnerabilità.

    
posta gertvdijk 15.10.2014 - 01:49

4 risposte

210

Informazioni di base

SSL è progettato per garantire il livello di trasporto su Internet. Per "il web", noto anche come HTTP, questo verrà riconosciuto come HTTPS, ma verrà utilizzato anche per altri protocolli di applicazione. SSLv2 è stato il primo protocollo di sicurezza per il trasporto ampiamente utilizzato, ma è stato trovato insicuro non molto tempo dopo. Successori SSLv3 e TLSv1 sono ampiamente supportati ora. TLSv1.1 e TLSv1.2 sono più recenti e stanno ottenendo molto supporto. La maggior parte se non tutti i browser Web rilasciati dal 2014 hanno il supporto per questo.

La recente scoperta da parte dei tecnici di Google sottolinea che SSLv3 non dovrebbe essere più utilizzato (come SSLv2 è deprecato molto tempo fa). I client che non saranno in grado di connettersi al tuo sito / servizio sono probabilmente molto limitati. CloudFlare ha annunciato che meno dello 0.09% dei visitatori continua a fare affidamento su SSLv3.

Soluzione semplice: disabilita SSLv3.

Ubuntu fornisce aggiornamenti?

Sì, tramite usn-2385-1 con l'aggiunta della funzione SCSV, ma non attenua completamente il problema in quanto non disabilita SSLv3 e la patch funzionerà solo se sono stati riparati entrambi i lati della connessione. Lo riceverai tramite i tuoi regolari aggiornamenti di sicurezza nel gestore dei pacchetti.

Quindi, TU devi agire tu stesso per disattivare SSLv3 (è configurabile). Le versioni future di client / browser disabiliteranno molto probabilmente SSLv3. Per esempio. Firefox 34 lo farà.

Disattivare SSLv3 completamente per impostazione predefinita in Ubuntu a livello di implementazione probabilmente rompere alcune cose là fuori anche per l'utilizzo SSL non HTTPS che non è così vulnerabile, quindi presumo che i manutentori non lo faranno e solo questa patch SCSV sarà applicata.

Perché l'aggiornamento SCSV in OpenSSL tramite usn-2385-1 non attenua il problema?

Davvero, smetti di fare domande del genere e salta alcuni paragrafi e disabilita SSLv3. Ma hey, se non sei convinto, ecco qua:

POODLE mostra che SSLv3 con cifrari CBC è rotto, l'implementazione di SCSV non lo cambia. SCSV si limita a non eseguire il downgrade da alcuni protocolli TLS a nessun protocollo TLS / SSL inferiore, se necessario, con l'attacco Man-in-the-Middle richiesto per i soliti casi.

Se devi accedere ad alcuni server che non offrono affatto TLS, ma solo SSLv3, allora il tuo browser non ha realmente scelta e deve parlare con il server usando SSLv3, che è quindi vulnerabile senza alcun attacco di downgrade .

Se devi accedere ad alcuni server che offrono TLSv1 + e SSLv3 (che è scoraggiato) e vuoi essere sicuro che la tua connessione non verrà declassata a SSLv3 da un utente malintenzionato, allora entrambi il server e il client ha bisogno di questa patch SCSV.

Per mitigare completamente il problema, la disabilitazione di SSLv3 è sufficiente e si può essere certi che non verrà eseguito il downgrade. E non sarai in grado di parlare con i server SSLv3-only.

Va bene, quindi come disattivare SSLv3?

Vedi sotto nelle sezioni specifiche dell'applicazione: Firefox, Chrome, Apache, Nginx e Postfix sono coperti per ora.

Sono interessati solo i server o anche i client?

La vulnerabilità esiste se sia il server che il client accettano SSLv3 (anche se entrambi sono in grado di TLSv1 / TLSv1.1 / TLS1.2 a causa di un attacco di downgrade).

Come amministratore del server dovresti disabilitare SSLv3 ora per la sicurezza dei tuoi utenti.

Come utente, dovresti disabilitare SSLv3 nel tuo browser ora per proteggerti quando visiti siti Web che supportano ancora SSLv3.

Questo OpenSSL / GnuTLS / browser è specifico?

No. È un bug di protocollo (design), non un bug di implementazione. Ciò significa che non puoi realmente applicarlo (a meno che tu non stia cambiando il design del vecchio SSLv3).

E sì, c'è una nuova versione di sicurezza OpenSSL , ma leggi sotto ( Ma io davvero hai bisogno del supporto SSLv3 ... per la ragione X, Y, Z! ) sul perché dovresti concentrarti maggiormente sulla disabilitazione di SSLv3.

Posso uccidere SSLv3 a livello di rete (firewall)?

Beh, sì, probabilmente. Lo metto in un post sul blog separato per ulteriori riflessioni e lavoro. Potremmo avere una magica regola iptables che puoi usare!

Il mio post sul blog: Come rimuovere SSLv3 nella rete usando iptables per POODLE?

È rilevante solo per HTTPS o anche per IMAP / SMTP / OpenVPN e altri protocolli con supporto SSL?

L'attuale vettore di attacco, come mostrato dai ricercatori, funziona con il controllo del testo in chiaro inviato al server utilizzando Javascript in esecuzione sulla macchina della vittima. Questo vettore non si applica agli scenari non HTTPS senza utilizzare un browser.

Inoltre, normalmente un client SSL non consente il downgrade della sessione a SSLv3 (avendo TLSv1 + visto nelle funzionalità di handshake), ma i browser vogliono essere molto compatibili con le versioni precedenti e lo fanno. La combinazione con il testo in chiaro di controllo e il modo specifico con cui viene creata un'intestazione HTTP lo rende sfruttabile.

Conclusione: disabilita SSLv3 per HTTPS ora , disattiva SSLv3 per altri servizi nella prossima finestra di servizio.

Qual è l'impatto? Devo revocare e rigenerare il mio certificato del server? (Come con Heartbleed)

No, non è necessario ruotare i certificati per questo. La vulnerabilità espone il ripristino in testo normale dai dati della sessione, non fornisce accesso a nessun segreto (né la chiave di sessione né la chiave del certificato).

L'autore di un attacco è probabilmente solo in grado di rubare le intestazioni di testo in chiaro come i cookie di sessione per eseguire violazione delle sessioni . Un ulteriore vincolo è la necessità di un attacco MitM completo (attivo)

.

C'è altro che posso fare per migliorare la mia configurazione SSL in generale?

Come utente, oltre a disabilitare SSLv3 nel tuo browser, non proprio. Bene, installa sempre gli ultimi aggiornamenti di sicurezza.

Per i server, segui la guida del server TLS di Mozilla . E prova con test Labs SSL di Qualys . Non è davvero così difficile ottenere una valutazione A + sul tuo sito. Aggiorna i pacchetti e implementa i suggerimenti dalla guida di Mozilla.

Ma ho davvero bisogno del supporto SSLv3 ... per la ragione X, Y, Z! E adesso?

Bene, c'è una patch che aggira l'attacco di downgrade dei client abilitati a TLSv1, chiamato la protezione di sicurezza SSLv3. A proposito, migliorerà anche la sicurezza di TLSv1 + (l'attacco downgrade è più difficile / impossibile). Viene offerto come backport da una versione OpenSSL più recente nel advisory sulla sicurezza di Ubuntu usn-2385-1 .

Big catch: sia i client che i server hanno bisogno di questa patch per funzionare. Quindi, secondo me, mentre aggiorni sia i client che i server, dovresti comunque effettuare l'upgrade a TLSv1 +.

Tuttavia, per favore, per ora basta ritirare SSLv3 nella tua rete. Sforzati di aggiornare gli standard di sicurezza e metti da parte SSLv3.

Ho sentito parlare del supporto SCSV per eliminare l'attacco di downgrade del protocollo. Ne ho bisogno?

Solo se hai davvero bisogno di SSLv3 per qualche strana ragione, ma migliora anche la sicurezza in TLSv1 +, quindi sì, ti consiglio di installarlo. Ubuntu fornisce un aggiornamento per questa funzione in usn-2385-1 . Lo riceverai tramite i tuoi regolari aggiornamenti di sicurezza nel gestore dei pacchetti.

Test della vulnerabilità per siti ospitati privatamente (ad es. intranet / offline).

I tuoi server sono vulnerabili semplicemente se supportano SSLv3. Diverse opzioni qui:

  • Con OpenSSL s_client:

    openssl s_client -connect <server>:<port> -ssl3
    

    Se la connessione ha esito positivo, sslv3 è abilitato. Se fallisce, è disabilitato. Quando fallisce dovresti vedere qualcosa del tipo:

    error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
    
  • Uso di nmap :

    nmap --script ssl-enum-ciphers -p 443 myhostname.tld
    

    Dovrebbe produrre ' SSLv3: No supported ciphers found '. Regola il tuo nome host / porta.

  • Utilizzo di cipherscan . Clona / scarica il file binario ed eseguilo:

    ./cipherscan myhostname.tld
    

    Dovrebbe non elencare nulla con SSLv3 sotto la colonna "protocolli".

Browser Firefox

Apri about:config , trova security.tls.version.min e imposta il valore su 1 . Quindi riavvia il browser per eliminare eventuali connessioni SSL aperte.

Firefox dalla versione 34 in poi disabiliterà SSLv3 per impostazione predefinita e quindi non richiede alcuna azione ( fonte ). Tuttavia, al momento della scrittura, 33 è appena uscito e il 34 è impostato per il 25 novembre.

Google Chrome (Linux)

Modifica il file /usr/share/applications/google-chrome.desktop , ad es.

sudo nano /usr/share/applications/google-chrome.desktop

Modifica tutte le linee iniziando con Exec= per includere --ssl-version-min=tls1 .

es. una linea come

Exec=/usr/bin/google-chrome-stable %U

diventa

Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U

Quindi assicurati di chiudere completamente il browser (le app di Chrome potrebbero mantenere il tuo browser attivo sullo sfondo!).

Nota: potrebbe essere necessario ripetere questo ogni aggiornamento del pacchetto google-chrome, sovrascrivendo questo file di avvio .desktop . Un browser Google Chrome o Chromium con SSLv3 disabilitato per impostazione predefinita non è ancora stato annunciato al momento della scrittura.

Server HTTPD Apache

Se si sta utilizzando un server Web Apache che attualmente supporta SSLv3, sarà necessario modificare la configurazione di Apache. Sui sistemi Debian e Ubuntu il file è /etc/apache2/mods-available/ssl.conf . Su CentOS e Fedora il file è /etc/httpd/conf.d/ssl.conf .Dovrai aggiungere la seguente riga alla configurazione di Apache con altre direttive SSL.

SSLProtocol All -SSLv2 -SSLv3

Ciò consentirà tutti i protocolli tranne SSLv2 e SSLv3.

Mentre ci sei, potresti prendere in considerazione il miglioramento della configurazione di ciphersuite per il tuo webserver come spiegato su il server TLS di Mozilla Guida . Aggiungi ad esempio:

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder     on
SSLCompression          off
# Read up on HSTS before you enable it (recommended)
# Header add Strict-Transport-Security "max-age=15768000"

Quindi controlla se la nuova configurazione è corretta (senza errori di battitura ecc.):

sudo apache2ctl configtest

E riavvia il server, ad es.

sudo service apache2 restart

Su CentOS e Fedora:

systemctl restart httpd

Ulteriori informazioni: documentazione di Apache

Ora testalo: se il tuo sito è pubblicamente disponibile, testalo utilizzando lo strumento Labs SSL di Qualys .

Server Nginx

Se stai eseguendo Nginx, includi semplicemente la seguente riga nella tua configurazione tra le altre direttive SSL:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Mentre ci sei, potresti prendere in considerazione il miglioramento della configurazione di ciphersuite per il tuo webserver come spiegato su il server TLS di Mozilla Guida . Aggiungi ad esempio:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
# Read up on HSTS before you enable it (recommended)
# add_header Strict-Transport-Security max-age=15768000;

E riavvia il server, ad es.

sudo service nginx restart

Riferimento: documentazione Nginx

Ora prova: se il tuo sito è pubblicamente disponibile, testalo utilizzando lo strumento Labs SSL di Qualys .

Lighttpd webserver

Le versioni Lighttpd & gt; 1.4.28 supportano un'opzione di configurazione per disabilitare SSLv2 e v3. Le versioni Lighttpd precedenti alla 1.4.28 consentono di disabilitare SOLO SSLv2. Si noti che Ubuntu 12.04 LTS e precedenti installano al meglio lighttpd v1.4.28 e quindi una semplice correzione non è disponibile per quelle distribuzioni. Quindi questa correzione dovrebbe essere usata solo per le versioni di Ubuntu maggiori di 12.04.

Per Ubuntu versione 12.04 o Debian 6, un pacchetto lighttpd aggiornato è disponibile dal repository openSUSE: link

Il pacchetto è destinato a Debian 6 (squeeze) ma funziona anche su 12.04 (preciso)

Modifica il /etc/lighttpd/lighttpd.conf per aggiungere le seguenti righe dopo la direttiva ssl.engine = "enable"

ssl.use-sslv2          = "disable"
ssl.use-sslv3          = "disable"

Quindi dovresti riavviare il servizio lighttpd con sudo service lighttpd restart ed eseguire un test di handshake ssl3 come descritto nelle sezioni precedenti per assicurarti che la modifica sia stata implementata con successo.

Tratto da link .

Postfix SMTP

Per "SSL opportunistico" (la politica di crittografia non applicata e semplice è accettabile anche), non è necessario modificare nulla. Anche SSLv2 è meglio che semplice, quindi se hai bisogno di proteggere il tuo server dovresti comunque utilizzare la modalità 'SSL obbligatorio'.

Per la modalità "SSL obbligatorio" già configurata, aggiungi / modifica l'impostazione smtpd_tls_mandatory_protocols per inbound connessioni e smtp_tls_mandatory_protocols per le connessioni in uscita:

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3

Se lo desideri, se vuoi disabilitare SSLv3 anche per la crittografia opportunistica (anche se non è necessario come spiegato sopra), fallo così:

smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3

e riavvia Postfix:

sudo service postfix restart

Sendmail

(modifica non verificata da utente anonimo, non mi sento a mio agio con Sendmail, verifica.)

Queste opzioni sono configurate nella sezione LOCAL_CONFIG del tuo sendmail.mc

LOCAL_CONFIG
O CipherList=HIGH
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3

Dovecot

In Dovecot v2.1 +, aggiungi quanto segue al tuo /etc/dovecot/local.conf (o a un nuovo file in /etc/dovecot/conf.d ):

ssl_protocols = !SSLv2 !SSLv3

e riavvia Dovecot:

sudo service dovecot restart

Per le versioni precedenti dovrai correggere il codice sorgente .

Courier-imap (imapd-ssl)

Courier-imap consente SSLv3 di default su Ubuntu 12.04 e altri. Devi disabilitarlo e utilizzare invece STARTTLS per forzare TLS. Modifica il tuo file di configurazione /etc/courier/imapd-ssl per riflettere le seguenti modifiche

IMAPDSSLSTART=NO
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=1
TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="<take those from the Mozilla TLS Server guide!>"

Server HAProxy

SSL è supportato in HAProxy & gt; = 1.5.

Modifica il file /etc/haproxy.cfg e trova la tua riga bind . Aggiungi no-sslv3 . Ad esempio:

bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3

Riferimento: Documentazione HAProxy

OpenVPN

Sembra non essere influenzato ( fonte ).

  

OpenVPN utilizza TLSv1.0, o (con & gt; = 2.3.3) facoltativamente TLSv1.2 e quindi non è influenzato da POODLE.

Puppet

Puppet utilizza SSL su HTTPS ma non viene utilizzato dai client "browser", solo gli agenti di Puppet che non sono vulnerabili al vettore di attacco mostrato.Tuttavia, è consigliabile disattivare semplicemente SSLv3.

Il mio consiglio è di usare il stephenrjohnson / puppetmodule modulo Puppet per configurare il tuo burattinaio in cui ho ucciso SSLv3 qualche tempo fa.

    
risposta data gertvdijk 15.10.2014 - 01:49
4

Potrebbe non essere specifico di Ubuntu ma per aggirare la vulnerabilità di Poodle in Node.js puoi impostare secureOptions su require('constants').SSL_OP_NO_SSLv3 quando crei un server https o tls.

Vedi link per ulteriori informazioni

    
risposta data 3rdEden 15.10.2014 - 10:59
0

La "correzione" per corriere disabilita tls 1.1 e tls 1.2. Non sembra essere un modo per eseguire il corriere con tls 1.1 o superiore. Una scansione PCI sul tuo server potrebbe tornare con la raccomandazione:

Configurare i server SSL / TLS per utilizzare TLS 1.1 o TLS 1.2 solo se supportati. Configura i server SSL / TLS per supportare solo pacchetti di crittografia che non utilizzano cifrari a blocchi.

    
risposta data PrgWiz 27.02.2015 - 15:45
-1

Poiché la vulnerabilità di POODLE è un difetto di progettazione nel protocollo stesso e non un bug di implementazione, non ci saranno patch. L'unico modo per mitigare questo è disabilitare SSLv3 nel server Apache. Aggiungi le linee sottostanti in ssl.conf ed esegui il riavvio di Apache.

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
    
risposta data Lal Krishna 16.10.2014 - 00:55

Leggi altre domande sui tag