Ataques SMACK sobre TLS: SKIP-TLS & FREAK

El martes por la tarde se expandieron mundialmente las informaciones sobre los SMACK Attacks sobre el protocolo TLS, publicados por los investigadores del Proyecto miTLS, un esfuerzo común entre INRIA y Microsoft Resarch. Cualquier fallo de seguridad que afecta a la capa de cifrado de los protocolos que dan soporte a Internet siempre genera una alerta de máxima seguridad, así que desde Eleven Paths nos pusimos manos a la obra, como el resto de las empresas que trabajan en seguridad, para conocer el alcance de estos fallos, que principalmente son dos: Los bugs de SKIP-TLS y el fallo de FREAK (Factoring RSA Export Keys).

Figura 1: Ataques SMACK TLS

Los bugs de SKIP-TLS 

Los investigadores de este trabajo, llamado SMACK por State Machine AttaCKs, lo primero que han hecho ha sido analizar cómo funciona la máquina de estados de las implementaciones TLS más populares, para ver si es posible saltarse algún paso del autómata y hacer que las implementaciones piensen que están en una conexión segura cuando realmente están en una conexión insegura. Es decir, para ponerlo simple, para hacer creer a los participantes de la comunicación que están enviando el tráfico de forma cifrada cuando realmente no es así.

Supongamos un entorno en el que un cliente y un servidor quieren comunicarse de forma cifrada, pero hay un atacante en el medio de la red. Este atacante tiene acceso a todos los mensajes pero no puede manipularlos todos porque le saldría una alerta de seguridad en el navegador si el proceso de negociación de claves no es correcto.  Sin embargo, estos investigadores han demostrado que existen implementaciones que, saltándose alguno de los pasos o enviando mensajes errores, creen que han negociado las claves de cifrado y establecido el canal cifrado cuando no es así. Este bug afecta, a servidores de Google, Paypal o Amazon Web Services y puede hacer que el tráfico se envíe en texto plano como se muestra en el siguiente vídeo.

Figura 2: Demostración de SKIP-TLS para negociar un canal en texto plano

La explicación técnica es que para establecer un canal seguro, el servidor y el cliente deben ir pasando fases, controladas por una máquina de estados que va cambiando de un estado a otro según la fase del proceso en la que se encuentren y el mensaje que se hayan intercambiado. Sin embargo, los investigadores muestran en el gráfico de la Figura 3 que hay cambios de estados incorrectos que pueden forzarse tanto en el servidor (color verde) como en el cliente (color rojo) en la implementación TLS que hace JSSE - que venían con el JDK de Java desde la versión 1.5 hasta la versión 1.8 antes de la actualización crítica de Enero.

Figura 3: Máquina de estados erróneos en clientes y servidores con JSSE forzados con SKIP-TLS

Esto quiere decir que, un atacante en el medio de la comunicación podría manipular los mensajes para hacer que la máquina de estados del servidor y del cliente llegaran al estado final de "negociado un canal cifrado de forma segura" sin que esto haya sido así.

FREAK (Factoring RSA Export Keys)

El segundo de los bugs es todavía más curioso ya que viene inducido por el miedo histórico de EEUU a exportar sistemas con algoritmos de cifrado que ellos no pudieran descifrar. Por eso, decidieron marcar algunos algoritmos muy seguros para uso interno y otros algoritmos "razonablemente seguros" como válidos para EXPORTAR a otros países. Estos algoritmos de cifrado "razonablemente seguros" en los años 90 son extremadamente inseguros hoy en día, y cualquier atacante en el medio de una comunicación puede descifrarlos sin problemas, tal como se explica en el libro de Criptografía en comunicaciones digitales: de la cifra clásica a RSA.

Para ello, lo que debe suceder es que tanto el servidor como el cliente permitan esta negociación, algo que en el lado del servidor se permiten los algoritmos marcados para exportación con EXP y en el cliente se soportan, como es el caso de Android o Apple Safari. Si las dos partes tienen estos algoritmos permitidos, lo que el atacante deberá hacer es lo que se conoce como un ataque de Downgrade, es decir, forzar al cliente y al servidor a negociar una sesión uno de estos algoritmos inseguros.  En el vídeo siguiente se muestra un ejemplo con la NSA.

Figura 4: Demo de FREAK con la NSA

Normalmente, servidor y cliente se intercambian la lista de algoritmos que soportan y se elige el más seguro, lo que hace el hombre en medio es hacer creer a cada uno de ellos que el otro solo soporta el algoritmo inseguro. Esto se ha hecho desde hace muchos años en el mundo del hacking, como os explicaba en este artículo sobre ataques a LDAP.

Figura 5: Evidencia de detección de algoritmos de EXP en Faast

Por supuesto, la gravedad del asunto era grande y se ha creado la web FreakAttack para poder hacer seguimiento del impacto de este bug, así que nosotros internamente implementamos rápidamente un plugin para nuestro sistema de Pentesting Persistente Faast que realiza a la detección de los algoritmos de exportación en los servidores con soporte SSL, para avisar rápidamente de todos los lugares donde se encuentra permitido un algoritmo de EXP.

Saludos Malignos!