1 mar 2016

DROWN: vulnerabilidad crítica en sitios HTTPS con soporte a SSLv2 (Parchea!)

DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) es una vulnerabilidad grave que afecta a HTTPS y otros servicios que dependen de los protocolos SSLv2 y TLS. DROWN, identificada como CVE-2016-0800, permite a los atacantes romper el cifrado, leer y robar comunicaciones sensibles, incluyendo contraseñas, números de tarjeta de crédito, secretos comerciales o información financiera.

DROWN permite a un atacante descifrar conexiones TLS, mediante el uso de un servidor que soporte SSLv2 y suites de cifrado
de categoría EXPORT, interceptadas mediante conexiones específicamente creadas a un servidor SSLv2 que use la misma clave privada. Según las mediciones actuales, 33% de todos los servidores HTTPS son vulnerable a este nuevo ataque.

DROWN empeora si además el servidor tiene dos vulnerabilidades adicionales de OpenSSL: CVE-2015-3197, que afecta a las versiones de OpenSSL anteriores a 1.0.2f y 1.0.1r y; CVE-2016-0703, que afecta a versiones de OpenSSL anteriores a 1.0.2a, 1.0.1m, 1.0.0r y 0.9.8zf.

Estas dos vulnerabilidades reducen considerablemente el tiempo y costo de llevar a cabo el ataque DROWN. Los 15 investigadores a cargo del descubrimiento han sido capaces de ejecutar el ataque en menos de un minuto usando un solo ordenador. Incluso para los servidores que no tienen estos errores particulares, una variante general del ataque, que funciona contra cualquier servidor SSLv2, puede realizarse en menos de 8 horas a un costo total de U$S 440.

Actualmente hay alrededor de 11,5 millones de sitios web vulnerables y los administradores de estos servidores deben tomar acciones inmediatas. Los clientes no pueden ni deben hacer nada.

Los servidores modernos utilizan el protocolo de cifrado de TLS pero, debido a configuraciones incorrectas, muchos servidores todavía podrían soportar SSLv2, un protocolo de 1995 y que los clientes actuales ya no usan.

Aunque SSLv2 es conocido por ser muy inseguro, hasta ahora no importaba y no era considerado un problema de seguridad porque los clientes nunca los utilizan. Ahora, DROWN demuestra que sólo el brindar soporte a SSLv2 es una amenaza para los clientes y servidores porque permite a un atacante descifrar conexiones TLS enviando "pruebas" a través del protocolo SSLv2 y utilizando la misma clave privada.
En términos técnicos, DROWN es una variante del ataque cross-platform Bleichenbacher Padding Oracle que potencialmente permite interceptar y descifrar conexiones TLS creando conexiones especialmente diseñadas a un servidor de SSLv2 que utiliza la misma clave privada. Este tipo de ataque hace uso de bugs en la implementación de un protocolo (SSLv2 en este caso) para atacar la seguridad de las conexiones realizadas bajo un protocolo totalmente diferente (TLS). Más concretamente, DROWN se basa en la observación de que SSLv2 y TLS soportan el protocolo RSA y, mientras que TLS se protege contra ciertos ataques bien conocidos, las suites de exportación SSLv2 no lo hacen.

Un servidor es vulnerable a DROWN si:
  • Permite conexiones SSLv2. Esto es sorprendentemente común, debido a la mala configuración. Las mediciones muestran que el 17% de los servidores HTTPS todavía permiten este tipo de conexiones SSLv2.
  • La clave privada se utiliza en cualquier otro server que permite conexiones SSLv2, incluso para otro protocolo. Muchas empresas reutilizan el mismo certificado y la clave en sus servidores web y correo electrónico, por ejemplo. En este caso, si el servidor de correo soporta SSLv2 y, aunque el servidor web no lo haga, un atacante puede aprovechar el servicio de correo para romper las conexiones TLS del servidor web. Esto pone en peligro el 33% de los servidores HTTPS.
El sitio web de DROWN tiene un formulario para controlar si el servidor web es vulnerable. El control se basa en datos correlacionados durante febrero de 2016 y no se actualiza automáticamente con los servidores que ya hayan desactivado SSLv2.
Para protegerse contra DROWN, los administradores deben garantizar que sus claves privadas no se reutilizan en cualquier otro tipo de servidor que permiten conexiones SSLv2. Esto incluye servidores web, servidores SMTP, IMAP y POP y cualquier otro software que soporte SSL/TLS. Se puede utilizar el formulario anterior para comprobar si el servidor parece estar expuesto al ataque.

Desactivar SSLv2 puede ser complicado y depende del software específico de servidor. Aquíse ofrecen las instrucciones para varios productos comunes:
  • OpenSSL: la solución más fácil y recomendada es actualizar a una versión reciente de OpenSSL. OpenSSL 1.0.2 deben actualizarse a 1.0.2g y, OpenSSL 1.0.1 deben actualizar a 1.0.1s. Las versiones más antiguas deben actualizar a alguna de estas versiones. OpenSSL ha publicado la actualización que deshabilita el protocolo SSLv2 por defecto y elimina el soporte para SSLv2 EXPORT, siguiendo la RFC 6176.
  • OpenSSL ya ha parcheado y otros como Canonical, RedHat y SUSE publicaran las actualizaciones en las próximas horas. Fedora no es vulnerable porque ha desactivado SSLv2 desde el año 2014. OpenSSL ha publicado las versiones 1.0.2g y 1.0.1s.
  • Microsoft IIS (Windows Server): en IIS 7.0 (y sup.), SSLv2 está desactivado por defecto y, si se ha activado manualmente, se debe deshabilitar. Las versiones anteriores no están soportadas por Microsoft y deben actualizarse.
  • Servicios de seguridad de red (NSS): NSS es una biblioteca criptográfica incorporada en muchos productos de servidor. NSS 3.13 (de 2012) tiene SSLv2 desactivado por defecto. Quienes lo hayan activado manualmente deben deshabilitarlo. Los usuarios de versiones anteriores deben actualizar. También se recomienda comprobar si la clave privada se expone en otro tipo de servidor.
  • Instrucciones para Apache, Postfix, Nginx
Se ha publicado el paper DROWN: Breaking TLS using SSLv2 [PDF] con todo el detalle técnico de la vulnerabilidad y una FAQ con las preguntas más frecuentes. Matthew Green, profesor de la Universidad Johns Hopkins, ha publicado un post explicando como funciona DROWN, al igual que lo hizo Ivan Ristic, Director de SSL Labs.

Actualización 19:00: se ha publicado una herramienta en Python para analizar los servidores internos y en cualquier puerto y, ya existía Nartac, que permite desactivar SSLv2 en IIS.Otro scanner publicado por RedHat.

Fuente: DROWN

Suscríbete a nuestro Boletín

4 comentarios:

  1. Buenas tardes.

    Yo tengo la version de openssl 1.0.1e-42.el6_7.4, servira?

    ResponderBorrar
  2. buenas tardes yo administro exchange si deshabilito sslv2 y 3 podria afectar el flujo normal de correo?

    ResponderBorrar
  3. Jonathan,

    Por lo que preguntas se ve que no tiene conocimiento del papel que juegan estos protocolos en las comunicaciones. Te recomiendo leer un poco más la documentación del producto que administras que es bastante abundante.

    La idea de deshabilitar los protocolos "viejos" que son vulnerables es justamente afectar(impedir) el flujo normal de correo que usen esos protocolos "viejos" para que no haya posibilidad de que sean espiados, capturados los correos. De tal manera se "fuerza" a que sean utilizados protocolos más fuertes que no sufren de vulnerabilidades conocidas.

    En un servidor de correo como Exchange, hay al menos dos tipos de comunicación que usan SSL/TLS: la conexión web de cliente,(un usuario que se conecta por https para leer su correo). Y por otro lado la conexión servidor a servidor donde intercambian correos entre si. (entre dominios diferentes o el mismo dentro de una organizacion con varios servidores)

    En ambos casos se utiliza automáticamente (es lo usual) el protocolo más fuerte que sea común a ambas partes.

    Al deshabilitar SSLv2 y 3 impides que alguien se conecte con un protocolo que ya no es seguro.

    Solo habría problemas con navegadores o clientes de correo MUY viejos y desactualizados.

    Y por el lado de comunicaciones servidor a servidor, no conozco salvo casos puntuales, en los que se fuerze el uso de SSL/TLS solamente.

    De hecho muchos servidores de correo utilizan SSL/TLS porque los administradores no han instalado un certificado ni han configurado su uso. Cabe mencionar que aunque lo hagas, solo se comunicará con otro servidor usando SSL/TLS si el otro servidor lo soporta y lo tiene configurado.

    Slds.
    Raúl

    ResponderBorrar

Gracias por dejar un comentario en Segu-Info.

Gracias por comentar!