La vulnerabilità DROWN sul dominio principale interessa i sottodomini?

Question

La vulnerabilità DROWN sul dominio principale interessa i sottodomini?

#1 da (2 voti)
#2 da (1 voti)

2

Gestisco un server dipartimentale ospitato su un sottodominio della mia rete aziendale, come in department.example.com .

Sia example.com che department.example.com utilizzano HTTPS, ma vengono eseguiti su macchine completamente diverse, utilizzano un'autorità di certificazione diversa e utilizzano coppie di chiavi diverse.

department.example.com (il server su cui sono finito) non supporta SSLv2 o SSLv3; supporta solo TLSv1.0 e versioni successive. La versione di OpenSSL su questa macchina è completamente aggiornata.

Tuttavia, il sottodominio example.com supporta SSLv2 e utilizza un certificato *.example.com con caratteri jolly. Utilizza una versione obsoleta di OpenSSL.

Quando ho eseguito il mio sito web attraverso il correttore di vulnerabilità di attacco DROWN al link , mi diceva ancora che il mio sito web era vulnerabile (a un l'uomo nell'attacco centrale se l'ho letto correttamente). Se la coppia di chiavi del server sul mio sottodominio department.example.com è completamente separata dalla coppia di chiavi example.com , la mia versione di OpenSSL è aggiornata e non supporto SSLv2, come potrei essere ancora vulnerabile a DROWN attacco?

Un sottodominio "protetto" può essere vulnerabile a causa della cattiva gestione del server example.com ? Se sì, come funziona?

openssl tls man-in-the-middle

posta therealrootuser 09.06.2016 - 03:02

fonte

2 risposte

1

Se un sito è influenzato dall'attacco DROWN dipende solo dalla configurazione del server che serve questo sito, non da alcuna relazione con altri server. Quindi se il tuo server è configurato per non supportare SSLv2 non dovrebbe essere influenzato dall'attacco DROWN.

Il che significa che il rapporto è errato o che il tuo sito ha una configurazione diversa dal previsto o che il DNS esterno punta a un server diverso dal tuo DNS interno o qualcos'altro è andato storto. Date le informazioni fornite, è impossibile dire quale di queste è il caso e il problema non può essere riprodotto per ottenere ulteriori informazioni.

risposta data 09.06.2016 - 04:36

fonte

Leggi altre domande sui tag openssl tls man-in-the-middle

Metodologia di test di penetrazione delle applicazioni Web Richiesta di PIN per l'installazione di app Android?

score 2 · Accepted Answer

Un server non configurato correttamente può effettivamente renderti vulnerabile a DROWN, lascia che ti mostri come. Come illustrato nel sito web originale di DROWN per essere vulnerabile, una di queste 2 condizioni deve essere soddisfatta:

The server allows SSLv2 connections. This is surprisingly common, due to misconfiguration and inappropriate default settings. Our measurements show that 17% of HTTPS servers still allow SSLv2 connections.

Or

Its private key is used on any other server that allows SSLv2 connections, even for another protocol. Many companies reuse the same certificate and key on their web and email servers, for instance. In this case, if the email server supports SSLv2 and the web server does not, an attacker can take advantage of the email server to break TLS connections to the web server. When taking key reuse into account, an additional 16% of HTTPS servers are vulnerable, putting 33% of HTTPS servers at risk.

Il secondo caso (quello a destra) è di nostro interesse qui. example.com o uno dei suoi sottodomini supportano SSLv2 e il tuo server su department.example.com utilizza lo stesso certificato SSL (il che significa che utilizza la stessa coppia di chiavi pubblica / privata). Anche se il tuo server supporta solo il protocollo TLS e non SSL, l'utente malintenzionato può abusare del sottodominio che utilizza SSLv2 per eseguire l'attacco DROWN e decodificare la tua sessione TLS protetta.

Mitigations

Ottieni altri server che utilizzano lo stesso certificato per applicare configurazioni sicure e disabilitare i protocolli obsoleti e non sicuri (SSLv2).
Se per qualsiasi motivo il numero 1 è impossibile, procurati un altro certificato di dominio singolo con nuove chiavi per il tuo server sul sottodominio. (Si tratta comunque di una brutta soluzione patchy)