CRIME: el nuevo ataque a SSL/TLS sucesor de BEAST

Juliano Rizzo y Thai Duong ya tuvieron una enorme repercusión cuando anunciaron en 2010 el ataque Padding Oracle (CBC) que afectó ampliamente ASP.NET y en 2011 el ataque a TLS 1.0/SSL 3.0 mediante BEAST que era capaz de descifrar las peticiones cliente 'al vuelo' y secuestrar sesiones hacia sitios tan sensibles como los de la banca on-line.

Ahora en la Ekoparty 2012, han presentado otra nueva técnica bautizada como CRIME para comprometer la integridad de las sesiones HTTP protegidas por SSL. Atentos que la explicación es un poco densa...

La técnica

SSL/TLS opcionalmente soporta compresión de datos. En el mensaje ClientHello, el cliente establece la lista de algoritmos de compresión que conoce, y el servidor responde, en el ServerHello, con el algoritmo de compresión que se utilizará.

Los algoritmos de compresión son especificados por identificadores de un byte y TLS 1.2 (RFC 5246) define únicamente el método de compresión nula (es decir, sin compresión). También hay otros documentos que especifican métodos de compresión. En particular, RFC 3749 define el método de compresión 1, basado en DEFLATE, el derivado de LZ77 que es el núcleo del formato gzip y también de los archivos Zip modernos. Cuando se utiliza la compresión, se aplica en todos los datos transferidos, como un stream largo. En particular, cuando se utiliza con HTTPS, la compresión se aplica en todas las sucesivas peticiones HTTP en el stream, la cabecera incluida. DEFLATE funciona mediante la localización de subsecuencias repetidas de bytes.

Supongamos que el atacante es un código javascript que puede enviar peticiones arbitrarias a un sitio destino (por ejemplo, un banco) y se ejecuta en la máquina atacada; el navegador enviará dichas solicitudes con la cookie del usuario del banco - el valor de la cookie que el atacante tiene después. Además, vamos a suponer que el atacante puede analizar el tráfico entre el ordenador del usuario y el banco (para ello, el atacante debe tener acceso a la misma LAN o al punto de acceso WiFi de la víctima, o se ha apropiado de un router de entre medias, posiblemente cerca del servidor del banco).

Para este ejemplo, supongamos que la cookie en cada solicitud HTTP es la siguiente:

> Cookie: secret=7xc89f+94/wa

El atacante conoce la parte "Cookie: secret =" y desea obtener el valor secret. Entonces, programa su código Javascript para emitir una petición que contenga en su cuerpo la secuencia "Cookie: secret = 0". La solicitud HTTP se verá así:

POST / HTTP/1.1 Host: thebankserver.com (…) Cookie: secret=7xc89f+94/wa (…)

Cookie: secret=0

Cuando DEFLATE vea que, hay repeticiones de secuencias "Cookie: secret =" y representan la segunda parte con un token muy corto (uno que dice "la secuencia anterior tiene una longitud de 15 y se encontraron n bytes anteriormente), DEFLATE tendrá para emitir un token adicional para el '0'.

La solicitud va al servidor. Desde el exterior, el atacante ve un blob opaco (SSL cifra los datos), pero puede ver su longitud (con una granularidad de bytes cuando la conexión utiliza RC4; con cifrado de bloques que hay un poco de relleno o padding pero puede ajustar el contenido de las peticiones por lo que, en la práctica, puede conocer también la longitud de las peticiones comprimidas).

Ahora, el atacante lo intenta de nuevo con "Cookie: secret=1" en el cuerpo de la petición. Luego, "Cookie: secret=2", y así sucesivamente. Todas estas peticiones se comprimen con el mismo tamaño (o casi porque hay matices con códigos de Huffman que se utilizan en DEFLATE), excepto el que contiene "Cookie: secret = 7", que comprime mejor (16 bytes de subsecuencia repetida en lugar de 15), y por lo tanto será más corta. El atacante ve eso. Por lo tanto, en unas pocas docenas de peticiones, el atacante habrá adivinado el primer byte del valor secreto.

A continuación, sólo tiene que repetir el proceso ("Cookie: secret = 70", "Cookie: secret = 71", y así sucesivamente) y obtener, byte por byte, el secret completo.

Impacto

Por lo tanto, para que el ataque CRIME tenga éxito, se requieren algunos aspectos:

- Que la compresión SSL/TLS se utilice en ambos extremos
- Que el atacante pueda ejecutar un agente Javascript en la víctima
- Un sniffer que tenga acceso a la sesión cifrada cliente-servidor

Otros factores facilitarían además el ataque:

- El uso de RC4 en lugar de cifrado de bloques como CBC (irónicamente se recomendó el uso de RC4 como una solución temporal contra BEAST...)
- La proximidad del sniffer al punto final del agente de la víctima podría proporcionar información más rápidamente, acortando el tiempo requerido para completar el ataque.

Contramedidas

Basándose en la información actual, parece que la principal contramedida sería desactivar la compresión SSL/TLS, una verdadera lástima en escenarios de conexiones con poco ancho de banda, especialmente en aquellos sitios que contienen muchas imágenes pequeñas o con Ajax pesados que requieren muchas peticiones pequeñas.

También y debido a que el ataque se centra en descifrar las credenciales de sesión, las mejores prácticas estándar para la protección de estas tokens también podrían limitar el impacto:

- Invalidar las credenciales de sesión al salir/idle para limitar la duración de la exposición.
- Invalidar y volver a emitir tokens de sesión periódicamente para limitar la duración de la exposición.
- Tokens de sesión asociados a una IP de origen específica para evitar su reutilización en otros lugares.
- Regenerar los tokens de sesión enlazados a un origen cuando esa fuente envía una solicitud con un token no válido. Esto limita la capacidad de un atacante de realizar fuerza bruta o adivinar tokens.
- Monitorizar los logs del servidor para identificar a un ataque en curso: al intentar enumerar los tokens de sesión, el agente de la víctima generará un gran número de peticiones al servidor web. Un IPS podría además detener el ataque de una forma proactiva.
- Las actualizaciones de software podrían hacer frente a este ataque y probablemente estarán disponible pronto, y hay algunos indicios de que muchos fabricantes ya han actualizado sus productos de forma silenciosa.

Referencias

- Rizzo, Juliano. "The CRIME attack." http://www.ekoparty.org//2012/juliano-rizzo.php
- Duong, Thai. "The CRIME attack." http://www.ekoparty.org//2012/thai-duong.php
- New Attack Uses SSL/TLS Information Leak to Hijack HTTPS Sessions https://threatpost.com/en_us/blogs/new-attack-uses-ssltls-information-leak-hijack-https-sessions-090512
- How can you protect yourself from CRIME, BEAST’s successor? http://security.blogoverflow.com/2012/09/how-can-you-protect-yourself-from-crime-beasts-successor/