Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-response-smuggling-desync.md

12 KiB
Raw Blame History

HTTP Response Smuggling / Desync

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Desincronización de la Cola de Peticiones HTTP

Primero que nada, esta técnica abusa de una vulnerabilidad de HTTP Request Smuggling, por lo que necesitas saber qué es eso:

La principal diferencia entre esta técnica y un HTTP Request Smuggling común es que en lugar de atacar la petición de la víctima añadiendo un prefijo a la misma, vamos a filtrar o modificar la respuesta que recibe la víctima. Esto se hace, en lugar de enviar 1 petición y media para abusar del HTTP Request Smuggling, enviando 2 peticiones completas para desincronizar la cola de respuestas de los proxies.

Esto se debe a que vamos a poder desincronizar la cola de respuestas para que la respuesta de la petición legítima de la víctima sea enviada al atacante, o por inyectar contenido controlado por el atacante en la respuesta a la víctima.

Desincronización de Pipeline HTTP

HTTP/1.1 permite solicitar diferentes recursos sin necesidad de esperar a los anteriores. Por lo tanto, si hay un proxy en el medio, es tarea del proxy mantener un emparejamiento sincronizado de las peticiones enviadas al backend y las respuestas recibidas de este.

Sin embargo, hay un problema al desincronizar la cola de respuestas. Si un atacante envía un ataque de HTTP Response Smuggling y las respuestas a la petición inicial y la contrabandeada se responden inmediatamente, la respuesta contrabandeada no será insertada dentro de la cola de respuesta de la víctima sino que simplemente se descartará como un error.

Por lo tanto, es necesario que la petición contrabandeada tome más tiempo en ser procesada dentro del servidor backend. Así, para cuando la petición contrabandeada sea procesada, la comunicación con el atacante habrá terminado.

Si en esta situación específica una víctima ha enviado una petición y la respuesta a la petición contrabandeada se responde antes que la petición legítima, la respuesta contrabandeada será enviada a la víctima. Por lo tanto, el atacante estará controlando la petición "realizada" por la víctima.

Además, si el atacante luego realiza una petición y la respuesta legítima a la petición de la víctima se responde antes que la petición del atacante. La respuesta a la víctima va a ser enviada al atacante, robando la respuesta destinada a la víctima (que puede contener por ejemplo el encabezado Set-Cookie).

Inyecciones Anidadas Múltiples

Otra diferencia interesante con el HTTP Request Smuggling común es que, en un ataque de smuggling común, el objetivo es modificar el comienzo de la petición de la víctima para que realice una acción inesperada. En un ataque de HTTP Response Smuggling, como estás enviando peticiones completas, puedes inyectar en un solo payload decenas de respuestas que estarán desincronizando a decenas de usuarios que estarán recibiendo las respuestas inyectadas.

Además de poder distribuir más fácilmente decenas de exploits entre usuarios legítimos, esto también podría usarse para causar un DoS en el servidor.

Organización del Exploit

Como se explicó anteriormente, para abusar de esta técnica, es necesario que el primer mensaje contrabandeado en el servidor requiera mucho tiempo para ser procesado.

Esta petición que consume tiempo es suficiente si solo queremos intentar robar la respuesta de la víctima. Pero si quieres realizar un exploit más complejo, esta será una estructura común para el exploit.

Primero, la petición inicial abusando del HTTP Request Smuggling, luego la petición que consume tiempo y luego 1 o más peticiones de payload cuyas respuestas serán enviadas a las víctimas.

Abusando de la Desincronización de la Cola de Respuestas HTTP

Capturando las peticiones de otros usuarios

Al igual que con los payloads conocidos de HTTP Request Smuggling, puedes robar la petición de la víctima con una diferencia importante: En este caso solo necesitas enviar contenido para que se refleje en la respuesta, no se necesita almacenamiento persistente.

Primero, el atacante envía un payload que contiene una petición POST final con el parámetro reflejado al final y un Content-Length grande

Luego, una vez que la petición inicial (azul) fue procesada y mientras la somnolienta está siendo procesada (amarillo) la siguiente petición que llega de una víctima va a ser añadida en la cola justo después del parámetro reflejado:

Luego, la víctima recibirá la respuesta a la petición somnolienta y si mientras tanto el atacante envió otra petición, la respuesta del contenido reflejado será enviada a él.

Desincronización de Respuestas

Hasta este punto, hemos aprendido cómo abusar de ataques de HTTP Request Smuggling para controlar la petición cuya respuesta un cliente va a recibir y cómo puedes luego robar la respuesta que estaba destinada para la víctima.

Pero aún es posible desincronizar aún más las respuestas.

Hay peticiones interesantes como la petición HEAD que están especificadas para no tener ningún contenido dentro del cuerpo de la respuesta y que deberían (deben) contener el Content-Length de la petición como si fuera una petición GET.

Por lo tanto, si un atacante inyecta una petición HEAD, como en estas imágenes:

Entonces, una vez que la azul es respondida al atacante, la siguiente petición de la víctima va a ser introducida en la cola:

Luego, la víctima recibirá la respuesta de la petición HEAD, la cual va a contener un Content-Length pero ningún contenido en absoluto. Por lo tanto, el proxy no enviará esta respuesta a la víctima, sino que esperará por algún contenido, que en realidad va a ser respuesta a la petición amarilla (también inyectada por el atacante):

Confusión de Contenido

Siguiendo el ejemplo anterior, sabiendo que puedes controlar el cuerpo de la petición cuya respuesta va a recibir la víctima y que una respuesta HEAD usualmente contiene en sus encabezados el Content-Type y el Content-Length, puedes enviar una petición como la siguiente para causar XSS en la víctima sin que la página sea vulnerable a XSS:

Envenenamiento de Caché

Abusando del ataque de desincronización de respuesta y Confusión de Contenido comentado anteriormente, si la caché almacena la respuesta a la petición realizada por la víctima y esta respuesta es una inyectada causando un XSS, entonces la caché está envenenada.

Petición maliciosa que contiene el payload de XSS:

Respuesta maliciosa a la víctima que contiene el encabezado que indica a la caché almacenar la respuesta:

{% hint style="warning" %} Nota que en este caso si el "víctima" es el atacante ahora puede realizar envenenamiento de caché en URLs arbitrarias ya que puede controlar la URL que va a ser almacenada con la respuesta maliciosa. {% endhint %}

Engaño de Caché Web

Este ataque es similar al anterior, pero en lugar de inyectar un payload dentro de la caché, el atacante estará almacenando información de la víctima dentro de la caché:

División de Respuesta

El objetivo de este ataque es abusar nuevamente de la desincronización de respuesta para hacer que el proxy envíe una respuesta 100% generada por el atacante.

Para lograr esto, el atacante necesita encontrar un punto final de la aplicación web que esté reflejando algunos valores dentro de la respuesta y conocer la longitud del contenido de la respuesta HEAD.

Enviarán un exploit como:

Después de que la primera petición se resuelve y se envía de vuelta al atacante, la petición de la víctima se añade a la cola:

La víctima recibirá como respuesta la respuesta HEAD + el contenido de la segunda respuesta de la petición (conteniendo parte de los datos reflejados):

Sin embargo, nota cómo los datos reflejados tenían un tamaño de acuerdo con el Content-Length de la respuesta HEAD que generó una respuesta HTTP válida en la cola de respuesta.

Por lo tanto, la siguiente petición de la segunda víctima estará recibiendo como respuesta algo completamente creado por el atacante. Como la respuesta es completamente creada por el atacante, también puede hacer que el proxy almacene la respuesta en la caché.

Referencias

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks: