mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-23 13:13:41 +00:00
159 lines
12 KiB
Markdown
159 lines
12 KiB
Markdown
# HTTP Response Smuggling / Desync
|
|
|
|
<details>
|
|
|
|
<summary><strong>Aprende hacking en AWS de cero a héroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Otras formas de apoyar a HackTricks:
|
|
|
|
* Si quieres ver a tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** revisa los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
|
|
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
|
|
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
|
* **Comparte tus trucos de hacking enviando PRs a los repositorios de GitHub de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
|
|
|
</details>
|
|
|
|
## 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**.
|
|
|
|
 (1) (1) (1).png>)
|
|
|
|
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**).
|
|
|
|
 (1).png>)
|
|
|
|
 (1) (1) (1).png>)
|
|
|
|
### 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 <a href="#capturando-las-peticiones-de-otros-usuarios" id="capturando-las-peticiones-de-otros-usuarios"></a>
|
|
|
|
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
|
|
|
|
.png>)
|
|
|
|
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**:
|
|
|
|
 (1).png>)
|
|
|
|
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:
|
|
|
|
.png>)
|
|
|
|
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:
|
|
|
|
 (1) (1) (1) (1) (1) (1).png>)
|
|
|
|
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):
|
|
|
|
 (1).png>)
|
|
|
|
### 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:
|
|
|
|
 (1) (1) (1) (1).png>)
|
|
|
|
### 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:
|
|
|
|
 (1).png>)
|
|
|
|
Respuesta maliciosa a la víctima que contiene el encabezado que indica a la caché almacenar la respuesta:
|
|
|
|
 (1).png>)
|
|
|
|
{% 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é:**
|
|
|
|
 (1) (1).png>)
|
|
|
|
### 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:
|
|
|
|
 (1) (1) (1).png>)
|
|
|
|
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**:
|
|
|
|
 (1) (1) (1).png>)
|
|
|
|
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):**
|
|
|
|
 (1).png>)
|
|
|
|
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
|
|
|
|
* No olvides revisar este video que explica todas estas técnicas muy bien: [https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)
|
|
|
|
<details>
|
|
|
|
<summary><strong>Aprende hacking en AWS de cero a héroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Otras formas de apoyar a HackTricks:
|
|
|
|
* Si quieres ver a tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** revisa los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
|
|
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
|
|
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
|
* **Comparte tus trucos de hacking enviando PRs a los repositorios de GitHub de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
|
|
|
</details>
|