Come funziona l'attacco OpenSSL Alternative chains forgery certificate (CVE-2015-1793)?

Question

Come funziona l'attacco OpenSSL Alternative chains forgery certificate (CVE-2015-1793)?

#1 da (4 voti)

7

Il advisory sulla sicurezza per il problema può essere trovato qui: link

OpenSSL Security Advisory [9 Jul 2015]

Alternative chains certificate forgery (CVE-2015-1793)

Severity: High

During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and "issue" an invalid certificate.

This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication.

This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.

OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p

This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project.

Note

As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade.

References

URL for this Security Advisory: https://www.openssl.org/news/secadv_20150709.txt

Note: the online version of the advisory may be updated with additional details over time.

For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html

openssl certificates certificate-authority

posta Kamic 09.07.2015 - 20:33

fonte

1 risposta

Leggi altre domande sui tag openssl certificates certificate-authority

cacert.org è più dannoso dell'auto-firma? In che modo le VPN ignorano il monitoraggio ISP

score 4 · Accepted Answer

Dalla descrizione, si può dedurre che l'attacco funziona come segue (attenzione: ho scritto "infer" e intendo - non l'ho provato):

L'attaccante è in grado di intercettare tutto il traffico di rete dalla vittima (ad esempio, l'attaccante gestisce il punto di accesso WiFi a cui la vittima è incautamente connessa).
L'utente malintenzionato possiede (legittimamente!) un dominio, chiamiamolo "evilattacker.com" e ha acquistato un certificato completamente valido con quel nome; in particolare, l'autore dell'attacco possiede un certificato A , che contiene il nome www.evilattacker.com , ed è firmato da qualche root di fiducia V . L'utente malintenzionato spinge una copia di tale certificato (la chiave pubblica) su un sito Web pubblicamente accessibile, ad esempio il proprio sito; l'URL corrispondente può essere (per esempio) http://www.evilattacker.com/cert.crt (potrebbe anche essere su qualsiasi tipo di hosting pubblico, non importa).
La vittima vuole connettersi al proprio sito bancario. Il suo browser tenta di aprire una sessione SSL con www.bank.com .
L'attaccante intercetta quella connessione e finge di essere la banca. A tal fine, l'autore dell'attacco invia una catena di certificati C , X (nell'ordine indicato) dove:
- C è un certificato sintetico che contiene il nome www.bank.com , ed è firmato con la chiave privata dell'aggressore e contiene un Authority Information Access estensione con un URL uguale a http://www.evilattacker.com/cert.crt (cioè, indicando dove l'autore dell'attacco ha pubblicato il proprio certificato C ).
- X è junk casuale.
Il client (browser della vittima) non riuscirà a convalidare la catena C , X , perché X è una spazzatura casuale. Se il browser utilizza un vecchio OpenSSL, le cose si fermano qui e viene segnalato un errore di connessione. Tuttavia, se il browser utilizza una nuova versione interessata di OpenSSL, tenterà di ricostruire una catena alternativa, seguendo l'URL trovato in C . In particolare, il browser scaricherà A (il certificato dell'attaccante) e poi V (l'autorità di certificazione attendibile esterna) e finirà con C , Una , V catena.
Se non ci sono bug, il client rifiuta la nuova catena C , A , V perché anche se tutti corrispondenza di firme crittografiche, il certificato medio A manca dell'estensione Basic Constraints con il flag cA impostato su TRUE : il certificato dell'attacker non è un certificato CA, quindi non può apparire nel mezzo di una catena valida. Tuttavia, a causa del bug, in quella situazione specifica, le versioni interessate di OpenSSL non riescono a controllare il flag cA nell'estensione Basic Constraints e accettano che C , A , V catena come valida. Il browser è persuaso che parla con il vero server di banca e procede senza alcun preavviso. L'attaccante può ora eseguire un attacco Man-in-the-Middle e saccheggiare il conto bancario della vittima .

Ironia della sorte, il mancato controllo dell'estensione Basic Constraints per i certificati medi è stato anche un bug in Windows / Internet Explorer circa 2003, e Microsoft è stata debitamente e pesantemente derisa per questo; gli sviluppatori di OpenSSL hanno quindi perso tutti i diritti su questo tipo di mocking.

Il bug influisce su ogni applicazione che utilizza una versione interessata di OpenSSL (non molti di essi, poiché il codice buggy è stato aggiunto solo di recente) ed è in grado di elaborare una catena di certificati inviata da un peer potenzialmente ostile. Ciò significa SSL client (durante la convalida del certificato di un server); questo significa anche server SSL stessi, quando (e solo quando) questi server richiedono i certificati dai client (l'autenticazione del client basata su certificati è piuttosto rara nel Web di tutti i giorni).