El triple Handshake de TLS es vulnerable a ataques Man In The Middle

El triple Handshake de TLS es vulnerable a ataques Man In The Middle

Sergio De Luz

Un grupo de investigadores han conseguido realizar un ataque Man In The Middle contra el triple handshake de TLS que se usa para establecer una conexión segura entre un cliente y un servidor. Los últimos ataques contra TLS se lograron por errores en la implementación, sin embargo el ataque de estos investigadores es debido a la forma en que los clientes se autentican en la renegociación TLS.

Aunque esto que os hemos contado puede parecer que es muy grave, no debemos alarmarnos demasiado ya que el impacto de este ataque está limitado contra sitios que usa certificados cliente TLS en la autenticación durante la renegociación, y protocolos que dependen del «channel binding» de TLS. La mayoría de usuarios nunca usan certificados en los clientes por lo que este ataque recién descubierto no les afecta.

Según los propios autores, la solución a este problema sería que el cliente fuera más estricto en verificar el certificado intercambiado durante la renegociación. En esta web han subido una imagen que hace una renegociación con certificados no relacionados antes de mostrar la información, como se puede «ver» en la imagen, la foto no se muestra por lo que este ataque contra TLS no nos afecta ya que no usamos certificados TLS cliente.

Las debilidades del protocolo TLS

Los investigadores han identificado cuatro vulnerabilidades en el protocolo TLS:

  • En el handshake con RSA, el cliente envía el PMS (Pre-master secret) al servidor de forma cifrada bajo la clave pública de A. Si A es un servidor malicioso, podría actuar como cliente de un servidor S legítimo enviando el mismo PMS en una nueva conexión. Estas dos conexiones se pueden «sincronizar» porque A puede usar los mismos valores aleatorios y el identificador de sesión en ambas conexiones, por tanto comparten el mismo identificador, MS (Master Secret) y claves de conexión. En el ámbito del intercambio de claves, esto es un ataque UKS (Unknown key-share), que por sí mismo no es una vulnerabilidad grave.
  • En el handshake DHE (Diffie-Hellmann), el servidor malicioso podría elegir un grupo no primo por lo que el PMS estaría bajo su control, por tanto, podría montar un ataque MITM como ocurre con RSA para montar dos sesiones que comparten identificador, MS y claves de la conexión (otro ataque UKS).
  • En la reanudación de una sesión TLS, el protocolo sólo verifica que el cliente y el servidor comparten el mismo MS, suite de cifrados y el identificador, no re-autentica al cliente en el servidor. Por tanto, esta forma de funcionar permite a un servidor malicioso montar un ataque UKS con dos sesiones. La renegociación segura se realiza en la misma conexión, pero esto no se aplica si la sesión se reanuda en una nueva conexión.
  • Durante la renegociación, los certificados del cliente y servidor pueden cambiar. El protoclo TLS lo permite pero no fija cómo se debe adoptar este cambio. Algunas implementaciones lo asocian al primer certificado y otras al último.

El ataque contra el triple handshake TLS

Si un cliente TLS se conecta a un servidor malicioso y presenta un certificado de cliente, el servidor puede suplantar al cliente en cualquier otro servidor, siempre y cuando este servidor acepte el certificado del cliente. El servidor malicioso realiza un ataque Man In The Middle y se sitúa en medio del triple handshake TLS haciéndose pasar por el cliente en el tercer handshake. Los ataques se pueden realizar en los navegadores web más populares y las librerías SSL más conocidas, siempre y cuando se utilice para realizar la autenticación los certificados, además los servidores deben permitir la reanudación y renegociación.

El ataque se realiza en tres pasos:

El primer paso consiste en que el cliente se conecta al servidor malicioso, y este al servidor legítimo haciéndose pasar por el cliente.

tls_triple_handshake_1

El segundo paso es que el cliente realiza una re-conexión contra el servidor malicioso y pregunta sobre la sesión anterior, el servidor malicioso hace lo propio con el servidor legítimo. Los parámetros en las dos sesiones bien diferenciadas son los mismos.

tls_triple_handshake_2

Llegados a este punto, el cliente cree que la conexión con el servidor atacante es legítima, y el servidor legítimo cree que tiene una conexión real con el cliente. Sin embargo, ambas sesiones son exactamente la misma y la información intercambiada en la renegociación TLS tendrán los mismos valores.

En el tercer y último paso, el servidor legítimo exige una renegociación TLS con la autenticación del cliente, por lo que se realiza un handshake completo y el servidor atacante lo único que hace es reenviar los diferentes mensajes. Al final de esta renegociación el servidor malicioso no conoce las llaves de la conexión o el MS, sólo lo conocen el servidor legítimo y el cliente, por tanto el servidor malicioso ya no podrá leer o enviar mensajes entre estas conexiones. Sin embargo, los mensajes anteriores que se han enviado, se podrían haber fijado después de la renegociación o ser capaz de leer y escribir datos en estas conexiones siguiendo la política de origen.

tls_triple_handshake_3

Al final de estos tres pasos, el cliente todavía cree que está conectado al servidor atacante pero realmente está en el servidor legítimo. Aunque el cliente ha recibido un certificado distinto (el del servidor legítimo) en la renegociación, no hay ningún tipo de aviso de este cambio. Esta confusión podría hacer que el cliente revele información sensible al servidor atacante de lo que ha intercambiado con el servidor legítimo, de hecho, se podrían manipular los mensajes.

Un ataque típico que un servidor atacante web podría realizar es inyectar un código JavaScript que se ejecute después de la renegociación para poder seguir teniendo el control de la conexión.

Posibles soluciones

  • Aplicar la misma política de validación de certificados recibidos a través de una conexión, de esta forma se asegura que los certificados son válidos para el parámetro actual del servidor y abortar el handshake si no lo es. Se rechaza la conexión si hay un cambio de certificados durante la renegociación.
  • Usar el Master Secret para el handshake completo.
  • Enlazar el handshake de la sesión de reanudación al handshake completo original.

Se pueden realizar otras variaciones del ataque y suplantar otros mecanismos de autenticación basados en TLS como PEAP o EAP-TTLS, el mecanismo que usan las redes inalámbricas con servidores RADIUS.

Estamos seguros que muy pronto veremos actualizaciones de estos protocolos para solucionar estos problemas.

Tenéis el ataque al triple Handshake a TLS en detalle en esta web, y una explicación resumida del ataque en este otro enlace. También podéis ver el paper en detalle en este enlace el PDF original.

Os recomendamos el tutorial que explica qué es la técnica MAC Flooding un ataque que puede que comprometer nuestra red.

1 Comentario