HTTP Response Smuggling / Desync
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
La técnica de este post fue tomada del video: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
Primero que nada, esta técnica abusa de una vulnerabilidad de HTTP Request Smuggling, así que necesitas saber qué es:
La principal diferencia entre esta técnica y un común HTTP Request smuggling es que en lugar de atacar la solicitud de la víctima agregando un prefijo a ella, vamos a filtrar o modificar la respuesta que recibe la víctima. Esto se hace al enviar, en lugar de 1 solicitud y media para abusar del HTTP Request smuggling, 2 solicitudes 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 solicitud legítima de la víctima sea enviada al atacante, o inyectando contenido controlado por el atacante en la respuesta a la víctima.
HTTP/1.1 permite solicitar diferentes recursos sin necesidad de esperar por los anteriores. Por lo tanto, si hay un proxy en el medio, es tarea de los proxies mantener un emparejamiento sincronizado de solicitudes enviadas al backend y respuestas que provienen de él.
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 solicitud inicial y la smuggled son respondidas inmediatamente, la respuesta smuggled no será insertada dentro de la cola de respuestas de la víctima, sino que simplemente será descartada como un error.
Por lo tanto, es necesario que la solicitud smuggled tome más tiempo para ser procesada dentro del servidor backend. Por lo tanto, para cuando la solicitud smuggled sea procesada, la comunicación con el atacante habrá terminado.
Si en esta situación específica una víctima ha enviado una solicitud y la solicitud smuggled es respondida antes que la solicitud legítima, la respuesta smuggled será enviada a la víctima. Por lo tanto, el atacante estará controlando la solicitud "realizada" por la víctima.
Además, si el atacante luego realiza una solicitud y la respuesta legítima a la solicitud de la víctima es respondida antes que la solicitud del atacante. La respuesta a la víctima será enviada al atacante, robando la respuesta a la víctima (que puede contener, por ejemplo, el encabezado Set-Cookie).
Otra diferencia interesante con el común HTTP Request Smuggling es que, en un ataque de smuggling común, el objetivo es modificar el inicio de la solicitud de la víctima para que realice una acción inesperada. En un ataque de HTTP Response smuggling, como estás enviando solicitudes completas, puedes inyectar en un payload decenas de respuestas que estarán desincronizando decenas de usuarios que estarán recibiendo las respuestas inyectadas.
Aparte de poder distribuir más fácilmente decenas de exploits entre usuarios legítimos, esto también podría ser utilizado para causar un DoS en el servidor.
Como se explicó anteriormente, para abusar de esta técnica, es necesario que el primer mensaje smuggled en el servidor requiera mucho tiempo para ser procesado.
Esta solicitud que consume tiempo es suficiente si solo queremos intentar robar la respuesta de la víctima. Pero si deseas realizar un exploit más complejo, esta será una estructura común para el exploit.
Primero la solicitud inicial abusando de HTTP Request smuggling, luego la solicitud que consume tiempo y luego 1 o más solicitudes de payload cuyas respuestas serán enviadas a las víctimas.
Al igual que con los payloads conocidos de HTTP Request Smuggling, puedes robar la solicitud de la víctima con una diferencia importante: En este caso solo necesitas que el contenido enviado sea reflejado en la respuesta, no se necesita almacenamiento persistente.
Primero, el atacante envía un payload que contiene una solicitud POST final con el parámetro reflejado al final y un gran Content-Length.
Luego, una vez que la solicitud inicial (azul) fue procesada y mientras la solicitud lenta está siendo procesada (amarillo), la siguiente solicitud que llega de una víctima se va a agregar en la cola justo después del parámetro reflejado:
Luego, la víctima recibirá la respuesta a la solicitud lenta y si mientras tanto el atacante envió otra solicitud, la respuesta de la solicitud de contenido reflejado será enviada a él.
Hasta este punto, hemos aprendido cómo abusar de los ataques de HTTP Request Smuggling para controlar la solicitud cuyo respuesta un cliente va a recibir y cómo puedes luego robar la respuesta que estaba destinada a la víctima.
Pero aún es posible desincronizar aún más las respuestas.
Hay solicitudes interesantes como la solicitud HEAD que están especificadas para no tener ningún contenido dentro del cuerpo de las respuestas y que deben (deben) contener el Content-Length de la solicitud como si fuera una solicitud GET.
Por lo tanto, si un atacante inyecta una solicitud HEAD, como en estas imágenes:
Luego, una vez que la azul es respondida al atacante, la siguiente solicitud de la víctima se va a introducir en la cola:
Luego, la víctima recibirá la respuesta de la solicitud HEAD, que 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 será la respuesta a la solicitud amarilla (también inyectada por el atacante):
Siguiendo el ejemplo anterior, sabiendo que puedes controlar el cuerpo de la solicitud cuya respuesta va a recibir la víctima y que una respuesta HEAD generalmente contiene en sus encabezados el Content-Type y el Content-Length, puedes enviar una solicitud como la siguiente para causar XSS en la víctima sin que la página sea vulnerable a XSS:
Abusando del ataque de desincronización de respuesta comentado anteriormente, si la caché almacena la respuesta a la solicitud realizada por la víctima y esta respuesta es una inyectada que causa un XSS, entonces la caché está envenenada.
Solicitud maliciosa que contiene el payload de XSS:
Respuesta maliciosa a la víctima que contiene el encabezado que indica a la caché que almacene la respuesta:
Ten en cuenta que en este caso si la "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.
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é:
El objetivo de este ataque es abusar nuevamente de la desincronización de respuestas para hacer que el proxy envíe una respuesta 100% generada por el atacante.
Para lograr esto, el atacante necesita encontrar un endpoint de la aplicación web que esté reflejando algunos valores dentro de la respuesta y conocer el Content-Length de la respuesta HEAD.
Él enviará un exploit como:
Después de que la primera solicitud sea resuelta y enviada de vuelta al atacante, la solicitud de la víctima se agrega a la cola:
La víctima recibirá como respuesta la respuesta HEAD + el contenido de la respuesta de la segunda solicitud (contiene parte de los datos reflejados):
Sin embargo, nota cómo los datos reflejados tenían un tamaño de acuerdo al Content-Length de la respuesta HEAD que generó una respuesta HTTP válida en la cola de respuestas.
Por lo tanto, la siguiente solicitud de la segunda víctima estará recibiendo como respuesta algo completamente elaborado por el atacante. Como la respuesta es completamente elaborada por el atacante, también puede hacer que el proxy almacene la respuesta.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
