mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-22 12:43:23 +00:00
159 lines
11 KiB
Markdown
159 lines
11 KiB
Markdown
# HTTP Response Smuggling / Desync
|
|
|
|
{% hint style="success" %}
|
|
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Support HackTricks</summary>
|
|
|
|
* 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.
|
|
|
|
</details>
|
|
{% 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 <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
|
|
|
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:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Support HackTricks</summary>
|
|
|
|
* 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.
|
|
|
|
</details>
|
|
{% endhint %}
|