# HTTP Response Smuggling / Desync
{% hint style="success" %}
Learn & practice AWS Hacking:
[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Learn & practice GCP Hacking: 
[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}
**La técnica de este post fue tomada del video:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)
## Desincronización de la Cola de Solicitudes HTTP
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**.
### Desync de Pipeline HTTP
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**.
.png>)
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**).
.png>)
.png>)
### Inyecciones Múltiples Anidadas
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.
### Organización del Exploit
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.
## Abusando de la Desincronización de la Cola de Respuestas HTTP
### Capturando las solicitudes de otros usuarios
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.
.png>)
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**:
.png>)
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**.
## Desincronización de Respuestas
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:
.png>)
Luego, **una vez que la azul es respondida al atacante**, la siguiente solicitud de la víctima se va a introducir en la cola:
.png>)
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):
.png>)
### Confusión de Contenido
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:
.png>)
### Envenenamiento de Caché
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:
.png>)
Respuesta maliciosa a la víctima que contiene el encabezado que indica a la caché que almacene la respuesta:
.png>)
{% hint style="warning" %}
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.
{% 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é:**
.png>)
### División de Respuestas
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:
.png>)
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**:
.png>)
La víctima recibirá como respuesta la **respuesta HEAD + el contenido de la respuesta de la segunda solicitud (contiene parte de los datos reflejados):**
.png>)
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**.
{% hint style="success" %}
Learn & practice AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Learn & practice GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}