domingo, marzo 29, 2015

Bar Mitzvah: Nuevo ataque a SSL/TLS te roba las sesiones

En la reciente Black Hat Asia 2015 se acaba de presentar un nuevo trabajo de investigación sobre las vulnerabilidades de las conexiones SSL/TLS cuando estas utilizan el algoritmo de cifrado RC4. Éste es uno de los algoritmos criptográficos comúnmente utilizado en el cifrado de comunicaciones digitales, y de él se conocen vulnerabilidades que lo hacen totalmente inseguro desde hace más de trece años. Ahora en este nuevo trabajo, publicado por Imperva se ha mostrado un ataque curioso al que han denominado Bar Mitzvah, y que está correctamente explicado en el artículo de investigación.

Figura 1: Bar Mitzvah: Nuevo ataque a SSL/TLS te roba las sesiones

Para entender los ataques, hay que describir primero el concepto de Invariance Weakness que ellos utilizan como base de su investigación. Esta debilidad se conoce desde hace tiempo y se produce por el sistema pseudo-aleatorio que tiene el algoritmo RC4 para generar las claves. Este fallo hace que el motor de aleatoriedad, produzca unas claves de cifrado inseguras concretas - a las que denominan "Hits" - con un patrón en forma de L que las caracteriza.

Figura 2: Claves inseguras en forma de L generan que los LSB (Least Significant Bit)
del Pseudo-Random Stream sean inseguros

En el paper "Weaknesses in the Key Scheduling Algorithm of RC4" se estudia en profundidad y se dice que, de todas las claves que se utilizan en una implementación RC4 hay muchas que tienen debilidades y podrían romperse.

Figura 3: Paper que estudia las debilidades de las claves utilizadas en RC4

Estas claves con el bug de Invariation Weakness permiten que un atacante pueda descifrar en poco tiempo los primeros 100 bytes de una conexión SSL/TLS, dejando parte del tráfico de la sesión al descubierto. Esos 100 bytes no son mucho, más teniendo en cuenta que el Handshake de la sesión SSL/TLS ya se lleva 35 bytes, pero conseguir descifrar 65 bytes puede ser más que suficiente, como han demostrado.

Ataque 1: Captura de tráfico de red sin ataque man in the middle

En un escenario de ataque de red en el que solo se pueda acceder al tráfico, se podrían estar escuchando todas las sesiones SSL y descifrar los 65 bytes de aquellas que vinieran cifradas con una clave "Hit". Una vez analizados esos 65 bytes, se procedería a ver qué contenido va en esos, para lanzar un ataque a posteriori.

Figura 4: Bytes que se pueden descifrar. Desde el 36 al 100 del Upstream.
(Upstream: del cliente al servidor)

El éxito del ataque es cuando en esos 65 bytes se puede sacar parte de la cookie de sesión de la aplicación. Con una parte de 65 bytes de una cookie de sesión de ASP.NET o de PHP, se puede realizar un ataque de fuerza bruta para conseguir obtener una cookie válida en tiempo y forma. Una vez conseguida las cookies, se podría hacer un hijacking completo. En el estudio, los investigadores también hacen sus cálculos de si en esos 65 bytes vienen partes de una contraseña, para saber cuánto se tardaría en crackear la contraseña de forma total.

Ataque 2: Captura de tráfico de red con un ataque man in the middle

Como se puede suponer en el ataque 1, para conseguir tener éxito hay que tener algo de fortuna para capturar las claves "Hits" y que en los 65 bytes que se pueden descifrar haya algo que permita crackear información sensible para secuestrar una cuenta o sesión. Sin embargo, si se tuviera un control en el cliente mediante un ataque de man-in-the-middle similar al que propone BEAST, se puede entonces generar mucho más tráfico en la sesión del cliente para conseguir más "Hits" y por tanto conseguir más partes de la cookie de sesión o de una clave.

Figura 5: Porcentajes de contraseñas crackeadas en ataques utilizando más o menos LSBs

Al final, existiendo estas debilidades, y conociendo todo lo que ya ha pasado en las redes WiFi que utilizan WEP - basado en RC4 - está claro que la conclusión a la que llegan los investigadores es la adecuada. Deshabilita RC4 en el servidor y en el cliente.

Saludos Malignos!

2 comentarios:

Anónimo dijo...

@Chema Alonso,
Interesante la verdad, sin desperdicio alguno vamos, esque tiene de todo >.<

Un pregunta, en un ariculo que publique en mi blog sobre unas prubas que hice sobre ataques de fuerza bruta a redes ocultas titulado Wifislax: Brute Force Attak! un usuario/lector publico el siguiente comentario/pregunta;

¿hay alguna forma de evitar el ataque de "expulsión del cliente del AP"? Ya que si no me equivoco, si se consiguiera evitar este paso se evitaría que el atacante consiguiera el handshake y por lo tanto todo lo demás...

Como se podría evitar eso Chema?
Saludos!

Anónimo dijo...

Afecta esto a la variante RC4-drop-N (donde N es habitualmente 256, 768 o 1024)?

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares