5 jun 2014

(Nuevas) vulnerabilidades en OpenSSL permiten MitM y DoS

Todavía no nos hemos recuperado del susto del Heartbleed cuando aparecen nuevas vulnerabilidades críticas en OpenSSL, reportadas en abril por Jüri Aedla del proyecto ZDI. Parece que se está poniendo de moda las vulnerabilidades en las librerías de cifrado.

Man-in-the-Middle (MitM)

En este caso (CVE-2014-0224) se trata de combinar un ataque de Man-in-the-Middle (MitM) con una inyección de paquetes ChangeCipherSpec (CCS) para renegociar los atributos de seguridad de la conexión segura.

Bien es cierto que para que el ataque tenga éxito, tanto el cliente como el servidor han de ser vulnerables. Parece ser que todos los clientes OpenSSL son vulnerables, y los servidores los de la versión 1.0.1, además el atacante tiene que estar en disposición de poder hacer un MitM. Hoy en día con las redes WiFi disponibles en bares, restaurantes, hoteles o aeropuertos esto es más probable que hace 10 años.

Este problema fue descubierto por Masashi Kikuchi (Lepidum Co. Ltd.) y comunicado a OpenSSL el 1 de mayo a través del JPCERT/CC. Kikuchi ha publicado una explicación sobre el descubrimiento de esta vulnerabilidad. Según han comunicado esta vulnerabilidad es de gravedad, ya que permite a un atacante malicioso interceptar datos cifrados y descifrarlos al forzar a los clientes SSL a emplear claves débiles expuestas al atacante.

En un post explicando cómo descubrió la vulnerabilidad, el investigador de seguridad Masashi Kikuchi escribió que "el error en ChangeCipherSpec(CCS) ha existido desde el primer lanzamiento de OpenSSL y el fallo no ha sido encontrado por más de 16 años debido a revisiones insuficientes en el código, especialmente de parte de expertos que tuvieron experiencias con implementación de TLS/SSL".

¿Cómo se realizaría el ataque?

Las sesiones SSL/TLS se inician con los mensajes de ClientHello y ServerHello desde ambos lados de la conexión, similar al handsake en las conexiones TCP/IP. Durante esta parte del protocolo se negocian los atributos de la sesión como por ejemplo las claves de cifrado o protocolo de cifrado.

Por alguna razón, el cliente o el servidor puede modificar la estrategia de cifrado de la conexión durante la etapa del handshake. Esto es posible gracias al CCS, que consiste en paquetes enviados entre cliente y servidor para informar que los siguientes registros de la conexión estarán protegidos bajo otras especificaciones de cifrado y claves.

El mensaje CCS se envía durante el handshake, después de que los parámetros de seguridad han sido aceptados pero antes de verificar si se ha enviado el mensaje de "Finalizado".

Ante este escenario un atacante podría esperar a una nueva conexión TLS, seguido de los mensajes ClientHello y ServerHello. A continuación emitir un paquete CCS en ambas direcciones provocando que OpenSSL use una clave maestra con longitud cero, obligando a que las claves de sesión usen una longitud cero, así como las futuras claves de sesión, extrapolando la debilidad de la sesión durante toda la conexión. Una vez renegociados los parámetros del handshake, el atacante podrá descifrar y modificar los paquetes que pasen por sus manos.

Denegación de Servicio (DoS)

El identificador de esta vulnerabilidad es el CVE-2014-0221, un atacante podría enviar un handshake DTLS no válido a un cliente OpenSSL vulnerable, únicamente los clientes que utilizan DTLS en OpenSSL están afectados.
Otra vulnerabilidad catalogada con el identificador CVE-2014-0198 permitiría provocar un fallo en la función do_ssl3_write, esta fallo podría ser explotado por un atacante por medio de una referencia a un puntero a "null".

Ejecución de código arbitrario

El identificador de esta vulnerabilidad es el CVE-2014-0195, un atacante podría realizar un ataque de desbordamiento de buffer por enviar fragmentos DTLS no válidos a un cliente o a un servidor. Esto da pie a poder ejecutar código arbitrario.
Por último, también se podría provocar una inyección de datos entre sesiones e incluso un DoS, forzando una condición de carrera en la función ssl3_read_bytes. Esta vulnerabilidad tiene como identificador CVE-2010-5298.

Versiones OpenSSL que solucionan todos estos fallos de seguridad
Las nuevas versiones de OpenSSL que resuelven este fallo de seguridad son las siguientes:
  • OpenSSL 0.9.8za
  • OpenSSL 1.0.0m
  • OpenSSL 1.0.1h
Recomendamos leer el aviso de seguridad de OpenSSL donde tenéis más detalles sobre otras vulnerabilidades que se han corregido.

OpenSSL ya ha corregido estas vulnerabilidades cambiando la forma en la que los paquetes CCS son recibidos y no permitiendo longitudes cero como valores de las claves maestras.
  • OpenSSL 0.9.8 SSL/TLS (client and/or server) debería actualizar a 0.9.8za.
  • OpenSSL 1.0.0 SSL/TLS (client and/or server) debería actualizar a 1.0.0m.
  • OpenSSL 1.0.1 SSL/TLS (client and/or server) debería actualizar a 1.0.1h.
Adam Langley de Google ha escrito un análisis del fallo. En este análisis señala que estos ataques necesitan clientes que utilicen OpenSSL y por lo tanto los navegadores IE, Firefox, Chrome y clientes de Android e iOS no son afectados. Chrome en Android utiliza OpenSSL, pero aún no se ha confirmado que sea vulnerable.

No obstante, todos los usuarios de OpenSSL deberían estar actualizando.

Fuente: Hacking Etico e Hispasec

Suscríbete a nuestro Boletín

0 Comments:

Publicar un comentario

Gracias por dejar un comentario en Segu-Info.

Gracias por comentar!