La seguridad HTTPS comprometida en 30 segundos en un ataque tipo BREACH

Dentro de la Black Hat USA 2013, sin duda una de las conferencias de
seguridad más prestigiosas, un grupo de investigadores demostraron cómo
es posible obtener información sensible del texto cifrado https en menos
de 30 segundos.

El ataque recibe el nombre de BREACH que no solo puede traducirse como
“brecha” sino que además atiende a las siglas de “Browser Reconnaissance
and Exfiltration via Adaptive Compression of Hypertext” (Reconocimiento
y Exfiltración del navegador a través de compresión adaptativa del
hipertexto).

Los investigadores Angelo Prado, Neal Harris y Yoel Gluck demostraron el
ataque en la Black Hat contra la aplicación web Outlook Web Access
(OWA). Una vez abierta la aplicación web y lanzado el ataque BREACH, en
tan solo 30 segundos habían conseguido extraer la información del canal
seguro. El ataque se basa en la inyección de texto plano en una petición
https y medir los cambios en las respuestas comprimidas.
http://www.youtube.com/watch?v=pIKIXQNFplY

El ataque BREACH es un tipo de vulnerabilidad y no una instancia
específica que afecta a una parte específica del software. Para ser
vulnerable, una aplicación web debe:
* Ser servida desde un servidor que utiliza compresión a nivel http (la
mayoría lo hacen).
* Reflejar entradas del usuario en el cuerpo de la respuesta http.
* Reflejar un secreto (como un token CSRF) en el cuerpo de la respuesta
http.

El atacante necesitará realizar peticiones estratégicamente construidas
al sitio atacado para recuperar un secreto concreto en el cuerpo de una
respuesta https (incluyendo IDs de usuarios, direcciones de correo
electrónico e incluso tokens de autenticación). Será necesario enviar
un par de peticiones para cada carácter del secreto a adivinar.

Para un token de una longitud de 32 caracteres y un espacio de
caracteres (alfabeto) de 16 (en hexadecimal), el atacante necesitará una
media de aproximadamente 1.000 peticiones si no se necesitan mecanismos
de recuperación adicionales (en caso de obtener múltiples respuestas
posibles). En la práctica, se ha comprobado que es posible recuperar
tokens CSRF con menos de 4.000 peticiones. Navegadores como Google
Chrome o Internet Explorer son capaces de realizar esas peticiones en
menos de 30 segundos (de ahí el titular), incluyendo las llamadas de
vuelta al centro de comando y control del atacante (que puede ser un
sitio controlado por el atacante con un iframe apuntando al servidor
vulnerable, o directamente con la intercepción y modificación del
tráfico no asegurado).

Actualmente no se conoce una solución práctica y global a este problema.
Sin embargo se ofrecen diversas contramedidas, algunas de ellas pueden
proteger aplicaciones completas mientras otras solo sirven ante páginas
web concretas. Entre las contramedidas se describen el desactivar la
compresión http, separar secretos de las entradas del usuario, que los
secretos en cada petición cliente sean aleatorios, enmascarar secretos,
proteger páginas web de ataques CSRF y ofuscar la longitud de las
respuestas web añadiendo cantidades aleatorias de bytes arbitrarios.
 Fuente