Español | English
rss facebook linkedin Twitter

Drown a fondo: Un nuevo ataque al SSL.(PARTE IV)




En varios posts a lo largo del mes de abril describimos las características principales del ataque DROWN general. Sin embargo, no hicimos mención a un caso particular de DROWN que lo convierte en un problema mucho más grave frente a versiones de OpenSSL afectadas por dos vulnerabilidades asociadas al mismo. En los próximos posts entraremos más en detalle en estas vulnerabilidades y veremos cómo son explotadas en el contexto del ataque DROWN.

Recapitulando, el ataque DROWN se basaba en descifrar un valor crítico en la negociación TLS, y que se en cuentra cifrado con RSA (pre-master-secret) explotando una característica del cifrado RSA, que permite descifrar un mensaje cifrado si conocemos el valor descifrado de otro mensaje distinto y la relación que existe entre ambos mensajes. Básicamente, se generaban una serie de valores relacionados con el pre-master-secret y utilizando un servidor SSLv2 que utilizara el mismo par de claves RSA se iban rompiendo estos valores por fuerza bruta aprovechando la debilidad de los algoritmos EXPORT. Podemos ver que hay dos puntos críticos en este ataque:

  • El servidor SSLv2 debe permitir el uso de algoritmos EXPORT en la comunicación, ya que en caso de algoritmos que no lo sean, el coste computacional del algoritmo es excesivo.
  • El atacante debe romper por fuerza bruta el cifrado de un algoritmo EXPORT en un tiempo razonable (lo que implica 240 operaciones criptográficas)

El primero de los puntos parece el más importante y el que más seguridad nos da. Simplemente basta con que deshabilitemos los algoritmos EXPORT en nuestro servidor (que seguramente ya estén deshabilitados) y con eso debería ser suficiente para protegernos ante DROWN, ¿no? Pues lo más probable es que no.

El riesgo asociado a este punto es la vulnerabilidad  CVE-2015-3197, que afecta a versiones de OpenSSL anteriores a 1.0.1r y 1.0.2f (en función de la rama que estemos usando). Para entender su funcionamiento debemos volver al protocolo de handshake usado en SSLv2, y ya mencionado en los posts anteriores (incluimos la versión “realista” implementada por los servidores SSLv2 más habituales).


Cuando vimos el ataque DROWN general explicamos este proceso de negociación desde el punto de vista de los datos cruzados para generar las claves simétricas. Sin embargo, en este proceso también se negocia el algoritmo de cifrado a utilizar. Esta información se cruza en los siguientes paquetes:

  • El cliente sugiere una lista de posibles algoritmos a utilizar en el paquete ClientHello
  • El servidor sugiere su propia lista de algoritmos a utilizar en el paquete ServerHello
  • El cliente elige un algoritmo común entre los sugeridos por ambas partes y envía su elección en el paquete ClientMasterKey
  • El servidor calcula las claves simétricas asociadas al algoritmo seleccionado por el cliente y envía los datos de verificación cifrados con dicho algoritmo en el paquete ServerVerify.
La vulnerabilidad de OpenSSL que estamos analizando en este momento consiste en que el servidor no comprueba que el algoritmo seleccionado por el cliente se encuentre en la lista de algoritmos sugeridos por él. Por tanto, la negociación sigue un proceso como el siguiente:

  • ClientHello : “Quiero usar el algoritmo EXP-RC2-CBC-MD5 (con clave de 40 bits)”
  • ServerHello: “Sólo soporto el algoritmo IDEA-CBC-MD5 (con clave de 128 bits)”
  • ClientMasterKey: “Entonces utilizaremos el algoritmo EXP-RC2-CBC-MD5”
  • ServerVerify: “Estos son mis datos de verificación usando EXP-RC2-CBC-MD5”

Es más, en muchas configuraciones se “deshabilitaba” SSLv2 simplemente deshabilitando todos los algoritmos de cifrado de SSLv2, asumiendo que en ese caso la negociación fallará, ya que el cliente no tendrá ningún algoritmo de cifrado común para seleccionar. En ese caso, para un servidor vulnerable, el proceso queda:

  • ClientHello : “Quiero usar el algoritmo EXP-RC2-CBC-MD5 (con clave de 40 bits)”
  • ServerHello: “No soporto ningún algoritmo”
  • ClientMasterKey: “Entonces utilizaremos el algoritmo EXP-RC2-CBC-MD5”
  • ServerVerify: “Estos son mis datos de verificación usando EXP-RC2-CBC-MD5”

En resumen, si usamos versiones de OpenSSL vulnerables a  CVE-2015-3197 no es posible limitar los algoritmos de cifrado para deshabilitar los algoritmos EXPORT, ya que un atacante siempre podrá forzar su uso y por tanto descifrar cada mensaje derivado aplicando 240 operaciones criptográficas en vez de 2128 como tendría que hacer en caso de tener que usar algoritmos no EXPORT.

Esto en cuanto a la negociación de algoritmos EXPORT. Sin embargo, de las dos vulnerabilidades relacionadas con DROWN esta no es la más grave. En el próximo post veremos que realmente un atacante no necesita usar los algoritmos EXPORT, siempre que la versión de OpenSSL esté afectada por la segunda vulnerabilidad. Es más, en ese caso le es más ventajoso usar algoritmos no EXPORT y le permite una velocidad de ataque que permite prácticamente un ataque man-in-the-middle contra una conexión TLS.

En cualquier caso, y como no nos cansaremos de repetir, la solución real no es aplicar parches sobre SSLv2 actualizando la versión de OpenSSL, sino eliminarlo completamente de la instalación y pasar a utilizar la versión TLSv1.1 o (mejor aún) TLSv1.2.  


Ion Larrañaga 
Software Innovation S21sec


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login