El ataque DROWN ( Decrypting RSA with Obsolete and Weakened eNcryption ) es un error de seguridad entre protocolos que ataca a los servidores que admiten los conjuntos de protocolos SSLv3/ TLS modernos utilizando su compatibilidad con el protocolo SSL v2 obsoleto e inseguro para aprovechar un ataque a las conexiones que utilizan protocolos actualizados que de otro modo serían seguros. [1] [2] DROWN puede afectar a todos los tipos de servidores que ofrecen servicios cifrados con SSLv3/TLS pero que aún admiten SSLv2, siempre que compartan las mismas credenciales de clave pública entre los dos protocolos. [3] Además, si se utiliza el mismo certificado de clave pública en un servidor diferente que admite SSLv2, el servidor TLS también es vulnerable debido a que el servidor SSLv2 filtra información de clave que se puede utilizar contra el servidor TLS. [3]
Los detalles completos de DROWN se anunciaron en marzo de 2016, junto con un parche que desactiva SSLv2 en OpenSSL; a la vulnerabilidad se le asignó el ID CVE - 2016-0800. [4] El parche por sí solo no será suficiente para mitigar el ataque si el certificado se puede encontrar en otro host SSLv2. La única contramedida viable es desactivar SSLv2 en todos los servidores.
Los investigadores estimaron que el 33% de todos los sitios HTTPS estaban afectados por esta vulnerabilidad al 1 de marzo de 2016. [5]
DROWN es el acrónimo de “Decrypting RSA with Obsolete and Weakened eNcryption” (Descifrado RSA con cifrado obsoleto y debilitado). [6] Aprovecha una vulnerabilidad en la combinación de protocolos utilizados y la configuración del servidor, en lugar de cualquier error de implementación específico. Según los descubridores, la vulnerabilidad no se puede solucionar haciendo cambios en el software del cliente, como los navegadores web. [3]
El exploit incluye un ataque de texto cifrado elegido con el uso de un servidor SSLv2 como oráculo de Bleichenbacher . SSLv2 funcionaba cifrando el secreto maestro directamente usando RSA, y los conjuntos de cifrados de exportación de 40 bits funcionaban cifrando solo 40 bits del secreto maestro y revelando los otros 88 bits como texto sin formato. El texto cifrado RSA cifrado SSLv3/TLS de 48 bytes se "recorta" a partes de 40 bits y luego se usa en el mensaje SSLv2 ClientMasterKey, que el servidor trata como la parte de 40 bits del secreto maestro SSLv2 (los otros 88 bits pueden ser cualquier valor enviado por el cliente como texto sin formato). Al aplicar fuerza bruta al cifrado de 40 bits, el mensaje ServerVerify se puede usar como oráculo. El ataque de prueba de concepto demostró cómo las configuraciones multi-GPU y la computación en la nube comercial podrían realizar parte de los cálculos de descifrado de códigos, a un costo de alrededor de $18,000 para la configuración de GPU y un costo por ataque de $400 para la nube. Un ataque exitoso proporcionará la clave de sesión para un protocolo de enlace TLS capturado.
Los investigadores, que describieron el ataque anterior como el ataque DROWN general, también encontraron una debilidad específica en la implementación OpenSSL de SSLv2 que permitía lo que llamaron un ataque DROWN especial . Esto redujo enormemente el esfuerzo necesario para romper el cifrado, lo que hizo posible los ataques de intermediario en tiempo real que requerían solo recursos informáticos modestos. La implementación OpenSSL de SSLv2 hasta 2015 no verificaba que las longitudes de clave claras y cifradas fueran correctas, lo que permitía, por ejemplo, que solo se cifraran 8 bits del secreto maestro. Hasta 2015, OpenSSL también sobrescribía los bytes incorrectos en el secreto maestro de SSLv2 durante su intento de aplicar la contramedida de Bleichenbacher. Hasta 2016, OpenSSL también negociaba con gusto conjuntos de cifrados SSLv2 deshabilitados. A diferencia de SSLv3 y posteriores, en SSLv2 se suponía que el cliente debía elegir entre una lista de conjuntos de cifrados ofrecidos por el servidor, pero OpenSSL permitía el uso de conjuntos de cifrados no listados.
Los informantes originales del error fueron los investigadores de seguridad Nimrod Aviram y Sebastian Schinzel. [7]
Para protegerse contra DROWN, los operadores de servidores deben asegurarse de que sus claves privadas no se utilicen en ningún lugar con software de servidor que permita conexiones SSLv2. Esto incluye servidores web, servidores SMTP, servidores IMAP y POP, y cualquier otro software que admita SSL/TLS. [8]
El grupo OpenSSL ha publicado un aviso de seguridad y un conjunto de parches destinados a mitigar la vulnerabilidad eliminando el soporte para protocolos y cifrados obsoletos. [9] Sin embargo, si el certificado del servidor se utiliza en otros servidores que admiten SSLv2, sigue siendo vulnerable, al igual que los servidores parcheados.
Numerosas fuentes han recomendado que los operadores del sitio solucionen la vulnerabilidad lo antes posible.