viernes, 9 de agosto de 2013

El cifrado HTTPS no es tan seguro como se suponía.

El cifrado HTTPS no es tan seguro como se suponía.

 
Why Is HTTPS Important?
 
Muchos usuarios notaran que al acceder a las paginas de sus bancos Online encontraran al principio del enlace “https” en lugar de “http”, esto es un cifrado de seguridad que supuestamente aseguraba que los datos ingresados estaban protegidos de personas ajenas. Pues bien, se ha descubierto un ataque que compromete 
la seguridad HTTPS en tan solo 30 segundos.

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.


Más información:

BREACH
http://breachattack.com

BREACH: REVIVING THE CRIME ATTACKhttp://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf

SSL, gone in 30 seconds - a BREACH beyond CRIMEhttps://www.blackhat.com/us-13/briefings.html#Prado

Vulnerability Note VU#987798 BREACH vulnerability in compressed HTTPShttp://www.kb.cert.org/vuls/id/987798

No hay comentarios:

Publicar un comentario