DROWN: Ataque a través de protocolo en TLS mediante SSLv2 (CVE-2016-0800)

Red Hat Product Security ha tenido conocimiento de una vulnerabilidad en el protocolo SSLv2, la cual ha sido asignada CVE-2016-0800 y se le conoce en el ataque a través de protocolo como DROWN - Decrypting RSA using Obsolete and Weakened eNcryption.

Visión General

Un grupo de investigadores de seguridad descubrió que SSLv2 ( La versión 2.0 del protocolo de Capa de conexión segura) es vulnerable al ataque Padding Oracle de Bleinchenbacher RSA , el cual puede utilizarse para descifrar el texto cifrado sin el conocimiento de la llave RSA privada. Esto se realiza al observar las respuestas de un servidor que tenga una llave privada y realice el descifrado de textos de cifras provistos por el atacante mediante dicha llave. Los investigadores también demostraron un nuevo ataque a través de protocolo que permite el descifrado de sesiones SSL/TLS mediante versiones de protocolo más recientes - SSLv3 o cualquier otra versión TLS (Seguridad de capa de transporte) (1.0 - 1.2) - aprovechando la debilidad de SSLv2. Esta vulnerabilidad es un problema de protocolo SSLv2 y afecta a todas las implementaciones del protocolo. Los investigadores se refieren a este ataque como general DROWN.

Además, se encontraron fallos en la implementación del protocolo en la criptografía SSLv2 y en la biblioteca SSL/TLS, lo cual posibilita la realización de una variante de ataque DROWN más eficiente, conocida como special DROWN. A estos problemas se les asignaron CVE-2016-0703 y CVE-2016-0704 y ya se corrigieron como parte de la corrección para CVE-2015-0293.

Para más información sobre este ataque, consulte el documento de investigación titulado DROWN: Breaking TLS using SSLv2.

Información de fondo

El protocolo SSLv2 ha presentado problemas de seguridad conocidos y se ha considerado inseguro desde su remplazo, SSLv3, fue publicado en 1996. Igualmente, fue depreciado en 2011 a través de RFC 6176. Su uso en Internet hoy es limitado, ya que los clientes modernos de SSL/TLS o bien no soportan esta versión de protocolo o, usan una versión más reciente cuando es posible. Sin embargo, muchos servidores SSL/TLS aún lo habilitan. Estos parámetros incluso permiten a clientes muy viejos conectarse y antes de la publicación del ataque DROWN, no hubo amenazas conocidas a la seguridad de las conexiones de clientes que soportan versiones de protocolo más recientes.

Configuraciones afectadas por el ataque DROWN

Un servidor es vulnerable a un ataque DROWN si habilita el protocolo SSLv2 aparte de SSLv3 o TLSv1.x, y si usa paquetes de cifras de intercambio RSA. Un servidor que no habilite SSLv2 también puede ser vulnerable si comparte su llave privada RSA con otro servidor o servicio que tenga habilitado SSLv2. Por ejemplo, el ataque DROWN aún puede ser utilizado para descifrar sesiones HTTPS para un servidor web que no habilite SSLv2, si dicho servidor comparte la llave RSA, por ejemplo, un servidor IMAP, posiblemente ejecutándose en el mismo host, que habilite SSLv2. Para poder realizar un ataque se necesitan cifras débiles o de exportación SSLv2.

Las conexiones SSL/TLS que usan una llave que no es RSA , tal como Diffie-Hellman o Elliptic Curve Diffie-Hellman, no pueden ser descifradas mediante el ataque DROWN.

Descripción e impacto del ataque

El ataque DROWN descrito por los investigadores consta de los siguientes pasos:

• Primero, el atacante debe registrar un número de sesiones SSL/TLS entre el cliente y servidor con cualquier versión del protocolo y mediante los paquetes de cifras RSA. Una de estas sesiones registradas será descifrada. Los investigadores indican que aproximadamente 1.000 sesiones son suficientes para el ataque.

• Como consecuencia, el atacante abre varias conexiones SSLv2 para el servidor. Para algunas de estas conexiones, el atacante necesita fuerza bruta de unos 40 bits (si una de las cifras SSLv2 EXPORT puede ser utilizada) o una llave de sesión de 56 bits (para un paquete de cifras que usan DES). Los investigadores estiman que se necesitan aproximadamente 40.000 conexiones.

• Después, el atacante puede descifrar los datos "premaster secret" del apretón de manos registrado originalmente. Esos datos sirven para generar llaves de sesión simétrica, y por lo tanto, descifran toda la sesión SSL/TLS registrada. Además, se pueden obtener datos confidenciales de la sesión descifrada, por ejemplo, credenciales o cookies.

Los investigadores indican que pudieron descifrar un apretón de manos TLS 1.2 con un servidor mediante llaves RSA de 2048 bits con apretones de manos de 1.000 registrados, 40.000 conexiones SSLv2 y 2⁵⁰ computaciones fuera de línea. Su ataque tomó menos de 8 horas mediante los recursos de un proveedor de nube pública a un costo de US$ 440.

También indican que el uso del ataque special DROWN reduce el número de conexiones a 14.000 y se pueden realizar en una estación de trabajo en menos de 3 minutos. Esto hace posible que esta debilidad se aproveche para realizar un ataque hombre en el medio (MITM) y suplantar un servidor TLS para conectarse al cliente TLS.

Bibliotecas SSL y TLS con soporte SSLv2

Los productos de Red Hat incluyen los siguientes componentes que implementan soporte para el protocolo SSLv2. Dicho soporte puede establecerse con base en el número de aplicaciones que usan estas bibliotecas SSL/TLS.

SSLv2 en OpenSSL

Las aplicaciones que usan OpenSSL deben seleccionar un método de conexión para informar a la biblioteca qué versiones de protocolo SSL/TLS desean utilizar. Los métodos de conexión OpenSSL habilitan una versión de protocolo única o el método especialSSLv23para habilitar todas las versiones de protocolo soportadas por la biblioteca. Este es el método de conexión más utilizado. El protocolo SSLv2 se activa automáticamente cuando el método es seleccionado. Las aplicaciones deben establecer la opción explícita SSL_OP_NO_SSLv2 en los objetos relevantes SSL_CTX oSSL para desactivar SSLv2. Aunque muchas aplicaciones lo hacen, ya sea incondicionalmente o basados en su configuración, otras aplicaciones usan el conjunto predeterminado de protocolos habilitados. Las aplicaciones que usan una biblioteca OpenSSL pueden, por lo tanto, ejecutarse con SSLv2 habilitado.

Los siguientes cambios han sido aplicados a OpenSSL en productos Red Hat para abordar este problema:

• El protocolo SSLv2 ya no se habilita automáticamente mediante el método de conexión SSLv23.
• Todos los paquetes de cifras SSLv2 que usan llaves de cifrado simétrico de 40 bits (EXPORT) o 56 bits (single DES) están inhabilitadas y no pueden ser utilizadas. Los siguientes paquetes de cifras ya no están disponibles:
  • EXP-RC2-CBC-MD5 / SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
  • EXP-RC4-MD5 / SSL_CK_RC4_128_EXPORT40_WITH_MD5
  • DES-CBC-MD5 / SSL_CK_DES_64_CBC_WITH_MD5
• Las versiones OpenSSL en los paquetes openssl en todas las actualizaciones para Red Hat Enterprise Linux 4 y 5 ahora chequean la variable de entorno OPENSSL_ENABLE_SSL2 y si está definida, SSLv2 se habilita automáticamente al usar el método de conexión. Esta variable de entorno puede servir para reactivar SSLv2 si es necesario.

El método de conexión SSLv2 no se afecta por el cambio para el método de conexión SSLv23 y aún puede establecer conexiones mediante el protocolo SSLv2.

Observe que mientras que la lista de cifras DEFAULT en versiones OpenSSL distribuidas en Red Hat Enterprise Linux 6 y 7 excluye todos los paquetes de cifras SSLv2, este predeterminado no evita que los servidores acepten conexiones SSLv2 de los clientes que impongan el uso del paquete de cifras inhabilitado. Este problema se asignó CVE-2015-3197 y también fue corregido en actualizaciones que abordan el problema de DROWN.

SSLv2 en NSS (Servicios de seguridad de red)

La biblioteca de criptografía NSS implementa el protocolo SSLv2, pero no lo habilita automáticamente. Las aplicaciones deben pedir, explícitamente, que se habilite SSLv2. Las versiones NSS distribuidas con Red Hat Enterprise Linux 7 no permiten la habilitación del protocolo SSLv2. Es poco probable que las aplicaciones que utilizan la biblioteca NSS se ejecuten con SSLv2 habilitado.

Ya que la biblioteca NSS no habilita automáticamente SSLv2, no se planean actualizaciones inmediatas para abordar el problema de DROWN. Se espera que futuras actualizaciones en Red Hat Enterprise Linux 6 inhabiliten el protocolo en una forma similar a como se inhabilita en Red Hat Enterprise Linux 7.

Bibliotecas SSL y TLS sin soporte SSLv2

Los productos Red Hat incluyen los siguientes componentes que implementan alguna versión de protocolo TLS o SSL, pero no implementan el soporte para SSLv2. Por lo tanto, estos componentes no se ven afectados por este problema. Observe que las aplicaciones que utilizan estas bibliotecas que no son afectadas, aún pueden se atacadas por DROWN si comparten su llave privada RSA con otra aplicación que usa una biblioteca SSL/TLS que soporta SSLv2.

• GnuTLS
• OpenJDK (paquetes java-1.6.0-openjdk, java-1.7.0-openjdk, java-1.8.0-openjdk)
• Oracle JDK (paquetes java-1.6.0-sun, java-1.7.0-oracle, java-1.8.0-oracle)
• IBM JDK (paquetes java-1.6.0-ibm, java-1.7.0-ibm, java-1.7.1-ibm, java-1.8.0-ibm)

Resolución

Red Hat recomienda a los clientes efectuar un análisis de prioridades de riegos de sus sistemas afectados e inmediatamente aplicar los correctivos disponibles para remediar el problema. Arrancar el sistema después de actualizar es la forma más segura para garantizar que todos los servicios afectados usen la biblioteca actualizada OpenSSL. Si no es posible volver a arrancar el sistema, reinicie todos los servicios de red que dependen de OpenSSL después de aplicar los correctivos.

Agradecimientos

Red Hat desea agradecer al proyecto OpenSSL para reportar estos problemas. La corriente de desarrollo principal agradece a Nimrod Aviram y Sebastian Schinzel como los reporteros originales.

Preguntas frecuentes

¿Cómo inhabilitar SSLv2 en aplicación X?

Consulte el artículo de la base de conocimientos Securing Application 'X' in RHEL 'Y' ? para obtener más información sobre cómo cambiar los parámetros relacionados con SSL/TLS, tales como las versiones de protocolo habilitadas, en varias aplicaciones distribuidas con varias versiones de Red Hat Enterprise Linux.

¿Deben generarse los certificados o las llaves de servidor debido a este problema?

No. DROWN no expone directamente las llaves RSA privadas, sino que ataca las llaves de sesión individuales que se generan durante los apretones de manos de conexión SSL/TLS y se utilizan para el cifrado simétrico. El compromiso de dichas llaves le permite descifrar sesiones SSL/TLS específicas. Así, incluso si se detecta un servicio como vulnerable para el ataque DROWN, no se requiere generar la llave de servicio o certificado.

¿Está SSLv2 activado en las versiones del servidor web Apache httpd distribuido con productos Red Hat?

El servidor web httpd Apache puede usar alguno de los siguientes módulos para proveer el servicio HTTPS:

• mod_ssl - Este módulo usa la biblioteca criptográfica OpenSSL y se incluye como parte de la distribución de servidor web httpd.
• mod_ssl - Este módulo usa la biblioteca criptográfica NSS y se desarrolla y distribuye independiente del proyecto httpd de Apache.

Ambos módulos se incluyen en los productos Red Hat.

Los parámetros predeterminados para httpd con mod_ssl son:

• Las versiones httpd distribuidas con Red Hat Enterprise Linux 7, en la colección httpd24en Red Hat Software Collections y con Red Hat JBoss Web Server 3, se basan en la versión 2.4 httpd y no pueden ser configurados para permitir el protocolo SSLv2.

• Las versiones httpd distribuidas con Red Hat Enterprise Linux 5 y 6, Red Hat JBoss Web Server 1 y 2, y Red Hat JBoss Enterprise Application Platform 6 se basan en las versiones httpd 2.2 de la corriente de desarrollo principal. Estas versiones pueden ser configuradas para usar SSLv2, sin embargo ese protocolo se inhabilita en la configuración predeterminada. El archivo de configuración/etc/httpd/conf.d/ssl.conf incluye la directiva de configuración que inhabilita SSLv2:

SSLProtocol all -SSLv2

• Las versiones httpd distribuidas con Red Hat Enterprise Linux 4 se basan en las versiones 2.0 de la corriente de desarrollo principal. La configuración predeterminada habilita SSLv2, la cual puede inhabilitarse al agregar la misma directiva SSLProtocolcomo se lista arriba al archivo de configuración/etc/httpd/conf.d/ssl.conf y reiniciando el servicio httpd.

Los parámetros predeterminados para httpd con mod_nss son:

• Las versiones mod_nss distribuidas con Red Hat Enterprise Linux 5, 6 y 7 no habilitan SSLv2 de forma predeterminada. El archivo de configuración /etc/httpd/conf.d/nss.confincluye, según la versión del paquete mod_nss, una de las siguientes directivas de configuración que solo permiten SSLv3 o posterior o TLSv1.0 o posterior:

NSSProtocol SSLv3,TLSv1
NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2

NOTA: Debido a problemas de protocolo SSLv3 conocidos, seguimos recomendando inhabilitar la sesión. Consulte el artículo POODLE: SSLv3 vulnerability (CVE-2014-3566) para obtener más información e instrucciones de cómo inhabilitar el protocolo SSLv3 en varios componentes de productos Red Hat.

¿Está SSLv2 habilitada en los servidores de correo SMTP distribuido con Red Hat Enterprise Linux?

Las configuraciones predeterminadas de servidores de correo Postfix y Sendmail en Red Hat Enterprise Linux, 5, 6 y 7 no habilitan el cifrado SSL/TLS.

Si un administrador habilita SSL/TLS en Postfix, SSLv2 se activará con un cifrado oportunista y desactivará con un cifrado obligatorio por defecto. En Red Hat Enterprise Linux 6 y 7, es posible desactivar SSLv2 con cifrado oportunista mediante la opción de configuración smtpd_tls_protocols.

Si un administrador de sistemas habilita SSL/TLS en Sendmail, SSLv2 se activa automáticamente. En Red Hat Enterprise Linux 5, 6 y 7 es posible inhabilitar SSLv2 mediante la opción de configuración ServerSSLOptions.

Vea la pregunta "¿Cómo inhabilitar SSLv2 en la aplicación X?" arriba para ver enlaces a otros recursos sobre cómo configurar SSL/TLS en Postfix y Sendmail.

¿Necesito actualizar mi instalación EAP 6.4?
EAP puede ser configurado para usar el proveedor de criptografía Java (JSSE) o el proveedor nativo (APR/OpenSSL). Si está utilizando el proveedor Apr/OpenSSL, entonces siga los siguientes pasos:

• Red Hat Enterprise Linux
  Actualice OpenSSL para su versión.
• Windows o Solaris
  Estará disponible una actualización para bibliotecas openssl en Customer Service Platform. Esta actualización remplazará las bibliotecas libssl y libeay y la aplicación openssl.

EAP 6.4 ha sido probado en Windows mediante APR/OpenSSL y aunque la biblioteca OpenSSL requiere una actualización, EAP 6.4 automáticamente usa TLSv1 y rechaza solicitudes de cifras para SSLv2 y SSLv3. No se espera que EAP sea vulnerable a este fallo.

¿Necesito actualizar mi instalación EAP 5.2?
EAP puede ser configurado para usar el proveedor de criptografía Java (JSSE) o el proveedor nativo (APR/OpenSSL). Si está utilizando el proveedor Apr/OpenSSL, entonces siga los siguientes pasos:

• Red Hat Enterprise Linux
  Actualice OpenSSL para su versión.
• Windows o Solaris
  Una actualización para bibliotecas openssl estará disponible en Customer Service Platform. Dicha actualización remplazará las bibliotecas libssl y libeay y la aplicación openssl.

En este momento EAP 5.2 se está probando en Windows para evaluar su nivel de vulnerabilidad frente a este fallo.

¿Necesito actualizar mi instalación EWS 2.1?
Este fallo solamente afecta instalaciones WIndows y Solaris cuando APR/OpenSSL ha sido configurado como proveedor de seguridad. EWS 2.1 actualmente soporta SSLv2 y SSLv3.
Si utiliza el proveedor Apr/OpenSSL entonces debe seguir los siguientes pasos:

• Red Hat Enterprise Linux
  Actualice OpenSSL para su versión.
• Windows o Solaris
  Una actualización para bibliotecas openssl estará disponible en Customer Service Platform. Dicha actualización remplazará las bibliotecas libssl y libeay y la aplicación openssl.

A: Sí EWS 2.1 se afecta, habrá actualizaciones disponibles desde el Portal del servicio al cliente. Este fallo afecta instalaciones WIndows y Solaris donde APR/OpenSSL ha sido configurado como proveedor de seguridad. La configuración JSSE predeterminada no se afecta. Las actualizaciones estarán disponibles desde el Portal del servicio al cliente.

¿Necesito actualizar mi instalación EWS 3.0.2?
Este error afecta las instalaciones WIndows y Solaris donde APR/OpenSSL ha sido configurado como proveedor de seguridad. EWS 3.0.2 actualmente soporta SSLv2 y SSLv3. Cuando se lance EWS 3.0.3, ya no ofrecerán SSLv2 o SSLv3.

Si utiliza el proveedor Apr/OpenSSL entonces debe seguir los siguientes pasos:

• Red Hat Enterprise Linux
  Actualice OpenSSL para su versión.
• Windows o Solaris
  Una actualización para bibliotecas openssl estará disponible en Customer Service Platform. Dicha actualización remplazará las bibliotecas libssl y libeay y la aplicación openssl.

¿Cuál es el estatus del paquete tomcat-native?

El paquete tomcat nativo no es afectado por este error. El paquete tomcat-native depende del sistema provisto por bibliotecas OpenSSL.