viernes, 12 de febrero de 2021

SSL/TLS: UNA MIRADA AL ATAQUE BREACH

Para definir y comprender correctamente el ataque BREACH, es necesario tener una noción básica acerca de los ataques de canal lateral de compresión y un claro entendimiento sobre los algoritmos de compresión.

Algoritmos de compresión

Uno de los algoritmos de compresión más famoso es DEFLATE, el cual define la base del formato de archivo ZIP, la biblioteca zlib, gzip, PNGs, etc., y se compone de una combinación de codificación Huffman y compresión LZ77.
En los algoritmos de compresión como DEFLATE, se utilizan dos enfoques:

  • 1°: Las letras más utilizadas obtienen la representación más corta.
  • 2°: Cualquier frase que se repita solo se almacena una vez.

Centrándose en el segundo enfoque, si cierta cadena de caracteres se repite en algún lugar del texto, solo se almacena la primera vez junto con punteros que señalan dónde se encuentra nuevamente la misma secuencia. La segunda vez que ocurre, se incluye una referencia a la primera ocurrencia. 

Cuando un texto aparece varias veces, se comprime de forma muy eficiente, ya que es menor la cantidad de bytes que se envían por lo que el tamaño es menor y también se reduce el tiempo necesario para enviar esos datos.


Considere el siguiente ejemplo:

El insensato que reconoce su insensatez es un sabio. Pero el insensato que se cree un sabio es, en verdad, un insensato.


Como puede ver, hay varias palabras en el texto que ocurren más de una vez. Gzip almacena esto haciendo referencia a una posición anterior cuando se encuentra una palabra o frase repetida.

Compresión utilizando punteros a ocurrencias posteriores
Fig 1. “Compresión utilizando punteros a ocurrencias posteriores”

Observe que la imagen muestra las referencias del archivo comprimido. Por ejemplo, el primer punto azul de la oración hace referencia a un uso anterior de "El insensato que". De esta forma, solo se tienen que almacenar 76 caracteres y 5 referencias a punteros, en lugar de los 121 caracteres originales.

Lo que se debe notar aquí, es que gran parte del texto es el mismo, por lo tanto el tamaño comprimido es menor, y la compresión se realiza con gran rapidez. Esta característica se puede utilizar en un ataque de canal lateral de compresión.

Ataques de canal lateral de compresión

Un ataque de canal lateral es un ataque que utiliza información capturada de la implementación de un sistema informático, en lugar de las debilidades en el algoritmo implementado en sí. Se puede utilizar para leer información confidencial, conociendo solo el tamaño de los datos comprimidos.

Como se explicó anteriormente, la compresión funciona de manera eficiente si una frase aparece varias veces en un texto. Esto significa que, si un texto contiene tanto una parte controlada por el usuario, y la otra es un secreto, podemos adivinar ésta última con solo mirar la longitud del resultado comprimido.

Por ejemplo, considere un sitio web que utiliza cookies comprimidas y cifradas. Algunos de los valores de la cookie son secretos y otros pueden ser establecidos por el usuario. Debido a que la cookie está cifrada, no podemos leer el secreto de inmediato.

Suponga que la cookie de texto sin formato se ve así:


Cookie con una parte secreta y otra controlada por el usuario
Fig 2. “Cookie con una parte secreta y otra controlada por el usuario”

Note que la solicitud acepta compresión GZIP, DEFLATE en el atributo “Accept-Encoding” de la cabecera. Además, los usuarios pueden establecer su color favorito, lo cual conduce a la pregunta: ¿Qué pasa si se establece un nuevo color favorito igual al secreto?

Réplica de atributos en cookie para ataque BREACH
Fig 3. “Réplica de atributos en cookie para ataque BREACH”

Debido a que la frase "tops3cr3t" ahora aparece dos veces, la variable "Cookie" del encabezado se comprime de manera muy rápida y eficiente. Con solo mirar el tamaño de la cookie, que debería ser más pequeño que el tamaño cuando la variable toma el valor de "green", se puede observar que el color "tops3cr3t" está presente en algún otro lugar de la cookie.

En la mayoría de los casos, incluso se puede adivinar un carácter a la vez. Simplemente se debería probar con "a", "b", "c", etc. como el color favorito. Cuando el tamaño de la cookie se reduce en un byte, puede afirmarse con certeza que se ha adivinado correctamente el primer carácter.

Esto solo funciona si el secreto y los datos controlados por el atacante están comprimidos juntos, y podemos leer el tamaño de la respuesta después de la compresión.

Ahora bien, observe en la siguiente imagen que se realiza la búsqueda de la frase "Your secret code is: 1", y el tamaño de la página de respuesta comprimida es de 355 bytes y restan 758 bytes sin comprimir:

NOTA: La frase “Your secret code is: 25bde29a” para este ejemplo en particular que no debería verse por el atacante, es una combinación de caracteres aleatorios, sin embargo, podría ser cualquier tipo de información confidencial, como tarjeta de crédito, token de autorización, etc.

Primera solicitud de ataque BREACH sin éxito
Fig 4. “Primera solicitud de ataque BREACH sin éxito”

Ahora bien, si se busca "Your secret code is: 2" se logra una compresión menor, debido a que coincide exactamente con el secreto:

Segunda solicitud de ataque BREACH con éxito
Fig 5. “Segunda solicitud de ataque BREACH con éxito”

Entonces, si continúa la búsqueda "Your secret code is: 5", "Your secret code is: b", etc., se obtendrá una compresión cada vez menor debido a que se adivina con éxito la frase secreta. Tenga en cuenta que el tamaño disminuye en un byte si adivinó un carácter correctamente. Dado que el mismo texto aparece dos veces, la página se comprime de forma más eficaz.

Por supuesto, en esta demostración, se puede ver explícitamente el atributo “secret”, pero el punto es que también puede determinarlo con solo mirar el tamaño de la página sin necesidad de conocerlo previamente.

Usted puede visitar el siguiente laboratorio de Sjoerd Langkember para comprobar lo que ha aprendido hasta el momento: http://demo.sjoerdlangkemper.nl/compression.php
Recapitulemos hasta este punto, un atacante puede leer información sensible, si y sólo si:

  • Puede leer el tamaño de la página comprimida.
  • Tiene control sobre algunos de los datos de esa página.

Ahora imagine que un atacante quiere obtener el token CSRF de un sitio web que se sirve a través de HTTPS, y se asume que el cibercriminal puede realizar solicitudes al sitio web, por ejemplo, inyectando etiquetas HTML o Javascript en otros sitios web (no HTTPS). Luego, el usuario malicioso no puede leer el resultado porque está cifrado, pero puede leer el tamaño de la respuesta. Si la página web también refleja parte de su entrada, puede atacar el sitio web mediante un ataque de canal lateral de compresión.

Luego, el atacante puede obtener un token CSRF realizando muchas solicitudes y observando el tamaño de la respuesta. Al igual que antes, sólo le restaría realizar solicitudes tales como "csrftoken=a", "csrftoken=b", etc.

Para que funcione de manera efectiva, la página solicitada debe reflejar esta entrada y contener el token CSRF en sí.

Esta es la base de las vulnerabilidades CRIME y BREACH.

¿Qué es BREACH?

En la Ekoparty 2012, Thai Duong y Juliano Rizzo anunciaron CRIME, un ataque de canal lateral de compresión contra HTTPS.

La demostración particular dada en Ekoparty mostró cómo un atacante podría ejecutar este ataque para recuperar los encabezados de una solicitud HTTP. Dado que los encabezados HTTP contienen cookies y las cookies son el vehículo principal para la autenticación de aplicaciones web (después del inicio de sesión), esto presenta un ataque significativo.

Sin embargo, CRIME se mitigó por completo al inhabilitar la compresión TLS/SPDY y al modificar Gzip para permitir la separación explícita de contextos de compresión en SPDY.

Los ataques BREACH, abreviatura de Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext (Reconocimiento y Exfiltración del Navegador a través de la Compresión Adaptativa de Hipertexto), descubierto en 2013, son ataques similares al ataque CRIME.  Ambos ataques son ataques de canal lateral de compresión; sin embargo, CRIME apunta a la información comprimida en las solicitudes HTTP a través de la compresión TLS, mientras que BREACH apunta a la información comprimida en las respuestas HTTP a través de la compresión HTTP. Esto permite esencialmente el mismo ataque demostrado por Duong y Rizzo, pero sin depender de la compresión de nivel TLS.

A pesar de que el ataque BREACH no tiene como objetivo directo la seguridad SSL, pone en peligro el objetivo de privacidad de SSL al reducir HTTPS al cifrado de los encabezados de página, dejando otros contenidos susceptibles al descubrimiento. Mediante una combinación de ataques de fuerza bruta y técnicas de tipo "divide y vencerás", los piratas informáticos pueden utilizar los ataques BREACH para extraer credenciales de inicio de sesión, direcciones de correo electrónico y otros datos confidenciales de identificación personal de sitios web con SSL habilitado.

BREACH es una categoría de vulnerabilidades y no una instancia específica que afecta a un software específico.

Aplicaciones vulnerables

Para ser vulnerable, una aplicación web debe:

  • Ser atendida desde un servidor que utiliza compresión a nivel HTTP.
  • Reflejar la entrada del usuario en los cuerpos de respuesta HTTP.
  • Reflejar un secreto (como un token CSRF) en los cuerpos de respuesta HTTP.

Además, aunque no es estrictamente un requisito, el ataque se ve favorecido en gran medida por respuestas que siguen siendo en su mayoría las mismas. Esto se debe a que la diferencia en el tamaño de las respuestas medidas por el atacante pueden ser bastante pequeñas. Cualquier ruido en el canal lateral hace que el ataque sea más difícil (aunque no imposible).

También es importante mencionar que el ataque funciona contra cualquier conjunto de cifrado:

a. Contra un cifrado de flujo, el ataque es más simple; la diferencia de tamaños entre los cuerpos de respuesta es mucho más granular en este caso.
b. Si se usa un cifrado de bloque, se debe realizar trabajo adicional para alinear la salida con los bloques de texto cifrado.

Características del ataque BREACH

Las características fundamentales del ataque BREACH pueden agruparse en tres conceptos bien marcados:

  • El ataque BREACH se puede explotar con miles de solicitudes y ejecutar en menos de un minuto.
  • El número específico de solicitudes necesarias dependerá del tamaño del secreto.
  • El poder concreto del ataque proviene del hecho de que permite adivinar un carácter secreto por cada iteración, es decir, de uno en uno.

Mitigación de la vulnerabilidad

Las mitigaciones están ordenadas por efectividad, no por su practicidad, ya que esto puede diferir de una aplicación a otra:

a.    Desactivar la compresión HTTP.
b.    Separar secretos de la entrada del usuario.
c.    Aleatorizar secretos por solicitud.
d.    Enmascarar secretos (aleatorización efectiva mediante XORing con un secreto aleatorio por solicitud).
e.    Aplicar protección a páginas vulnerables con CSRF.
f.    Ocultar la longitud agregando un número aleatorio de bytes a las respuestas.
g.    Limitar las solicitudes.

Independientemente de la mitigación que usted elija, se recomienda encarecidamente que también controle su tráfico para detectar intentos de ataque.

Referencias
http://breachattack.com/
https://www.acunetix.com/blog/articles/breach-attack/
https://www.sjoerdlangkemper.nl/2016/08/23/compression-side-channel-attacks/
https://www.venafi.com/


Autor: Gonzalo Carrasco - CEH
Dpto. Auditoría