¿La vulnerabilidad DROWN en el dominio raíz afecta a los subdominios?

2

Mantengo un servidor departamental alojado en un subdominio de mi red organizativa, como en department.example.com .

Tanto example.com como department.example.com usan HTTPS, pero se ejecutan en máquinas completamente diferentes, usan una Autoridad de certificación diferente y usan pares de claves diferentes.

department.example.com (el servidor sobre el que estoy) no es compatible con SSLv2 o SSLv3; solo soporta TLSv1.0 y superior. La versión de OpenSSL en esta máquina está completamente actualizada.

Sin embargo, el subdominio example.com es compatible con SSLv2 y utiliza un certificado de comodín *.example.com . Utiliza una versión desactualizada de OpenSSL.

Cuando ejecuté mi sitio web a través del verificador de vulnerabilidades de ataque DROWN en enlace , aún me decía que mi sitio web era vulnerable (a un hombre en el medio ataque si lo leo correctamente). Si los pares de claves del servidor en mi subdominio department.example.com están completamente separados del par de claves de example.com , mi versión de OpenSSL está actualizada y no soy compatible con SSLv2, ¿cómo podría ser vulnerable a DROWN? ataque?

¿Puede un subdominio "seguro" ser vulnerable debido a la mala administración del servidor example.com ? Si es así, ¿cómo funciona esto?

    
pregunta therealrootuser 09.06.2016 - 05:02
fuente

2 respuestas

2

Un servidor no configurado correctamente puede hacerte vulnerable a DROWN, déjame mostrarte cómo. Como se ilustra en el sitio web original de DROWN para ser vulnerable, se debe cumplir una de estas 2 condiciones:

  
  1. El servidor permite conexiones SSLv2. Esto es sorprendentemente común, debido a una mala configuración y una configuración predeterminada inapropiada. Nuestro   Las mediciones muestran que el 17% de los servidores HTTPS todavía permiten SSLv2   conexiones

         

    O

  2.   
  3. Su clave privada se usa en cualquier otro servidor que permita conexiones SSLv2, incluso para otro protocolo. Muchas empresas reutilizan lo mismo.   Certificado y clave en sus servidores web y de correo electrónico, por ejemplo. En   En este caso, si el servidor de correo electrónico es compatible con SSLv2 y el servidor web sí lo hace.   no, un atacante puede aprovechar el servidor de correo electrónico para romper TLS   Conexiones al servidor web. Al tomar en cuenta la reutilización de la clave, un   El 16% adicional de los servidores HTTPS son vulnerables, y el 33% de los servidores HTTPS   servidores en riesgo.

  4.   

El segundo caso (el de la derecha) es de nuestro interés aquí. example.com o uno de sus subdominios son compatibles con SSLv2 y su servidor en department.example.com utiliza el mismo Certificado SSL (lo que significa que usa el mismo par de claves pública / privada). Incluso si su servidor solo admite el protocolo TLS y no SSL, el atacante puede abusar del único subdominio que usa SSLv2 para realizar el ataque DROWN y descifrar su sesión TLS segura.

Mitigaciones

  1. Obtenga otros servidores que usan el mismo certificado para aplicar configuraciones seguras y deshabilitar los protocolos antiguos e inseguros (SSLv2).
  2. Si por alguna razón el número 1 es imposible, obtenga otro certificado de dominio único con claves nuevas para su propio servidor en su subdominio. (Aunque esta es una solución parcheada fea)
respondido por el Silverfox 09.06.2016 - 07:45
fuente
1

Si un sitio se ve afectado por el ataque DROWN, solo depende de la configuración del servidor que sirve este sitio, no de ninguna relación con otros servidores. Por lo tanto, si su servidor está configurado para no admitir SSLv2, no debería verse afectado por el ataque DROWN.

Lo que significa que o el informe es incorrecto o que su sitio tiene una configuración diferente a la esperada o que el DNS externo apunta a un servidor diferente al de su DNS interno o que algo salió mal Dada la información que proporciona, es imposible decir cuál de estos es el caso y el problema no se puede reproducir para obtener más información.

    
respondido por el Steffen Ullrich 09.06.2016 - 06:36
fuente

Lea otras preguntas en las etiquetas