hacktricks/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md

159 lines
10 KiB
Markdown
Raw Normal View History

# Request Smuggling en Downgrades de HTTP/2
2023-06-05 18:33:24 +00:00
<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>
2023-06-05 18:33:24 +00:00
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).
2023-06-05 18:33:24 +00:00
</details>
## Orígenes
El principal origen de esta vulnerabilidad es el hecho de que el **reverse proxy** va a **comunicarse con el cliente** usando **HTTP/2** pero luego va a **transformar** esa **comunicación** con el **servidor back-end** a **HTTP/1.1**.
2023-06-05 18:33:24 +00:00
![](<../../.gitbook/assets/image (636) (1).png>)
El problema con este enfoque es que el **usuario** va a poder **inyectar** **encabezados** innecesarios en la **comunicación HTTP/2** que probablemente **no serán verificados** por el proxy. Pero luego, cuando estos son **inyectados a ciegas en la comunicación HTTP/1.1**, **se puede realizar un ataque de request smuggling**.
2023-06-05 18:33:24 +00:00
## Ejemplos
### Desincronización H2.CL
2023-06-05 18:33:24 +00:00
La especificación de HTTP/2 indica que el **encabezado Content-Length no es necesario pero puede ser indicado**. Por lo tanto, el **reverse proxy** tratará todo el contenido enviado por los usuarios como la solicitud, pero luego, al **degradar a HTTP/1.1**, este **encabezado** va a ser **inyectado** en la **solicitud** y por lo tanto, el **servidor back-end tratará la solicitud como 2 solicitudes diferentes** como puedes ver en la imagen a continuación:
2023-06-05 18:33:24 +00:00
![](<../../.gitbook/assets/image (639).png>)
### Secuestro de Token de URL H2.TE Desync
2023-06-05 18:33:24 +00:00
La especificación de HTTP/2 también indica que **cualquier mensaje que contenga campos de encabezado específicos de la conexión DEBE ser tratado como malformado... pero si no sigues esta regla, eres vulnerable**.
2023-06-05 18:33:24 +00:00
Esta técnica fue abusada en el balanceador de carga de AWS, por lo que asegurarse de que los usuarios accedan a un encabezado Host apuntando a un servidor controlado por el atacante hará que accedan a ese servidor.
2023-06-05 18:33:24 +00:00
![](<../../.gitbook/assets/image (631) (1).png>)
### Secuestro de Encabezado H2.TE Desync
2023-06-05 18:33:24 +00:00
Esta es exactamente la misma técnica que antes, pero revisando las solicitudes James notó que los clientes le pedían enviarle sus credenciales, así que simplemente modificó su servidor para permitir CORS para enviarle las credenciales de las personas:
2023-06-05 18:33:24 +00:00
![](<../../.gitbook/assets/image (662) (1) (1) (1) (1) (1).png>)
### H2.TE vía Inyección de Encabezado de Solicitud
**HTTP/2 tampoco permitirá poner caracteres no permitidos en los encabezados**, pero si el servidor **no respeta** esta regla, puedes **inyectar encabezados arbitrarios** cuando la comunicación se **degrada** a HTTP/1.1.
En este caso **se inyectó el encabezado Transfer-Encoding**.
![](<../../.gitbook/assets/image (648) (1) (1) (1) (1) (1).png>)
### H2.TE vía Inyección de Nombre de Encabezado
HTTP/2 en algunos servidores te permite poner un **dos puntos en el nombre del encabezado, y con un** puedes inyectar un nuevo encabezado dentro del nombre del encabezado como esto:
![](<../../.gitbook/assets/image (632) (1).png>)
Nota que si pones solo los caracteres de nueva línea enviando un encabezado sin contenido, la solicitud va a ser tratada como **inválida**:
![](<../../.gitbook/assets/image (647) (1) (1) (1).png>)
### H2.TE vía Inyección de Línea de Solicitud
En este caso la inyección se realizó dentro de la línea de solicitud:
![](<../../.gitbook/assets/image (640) (1).png>)
### Inyección de Prefijo de URL
Dentro del esquema de la conexión HTTP/2 podrías ser capaz de enviar una URL completa que sobrescribirá la indicada en el camino:
![](<../../.gitbook/assets/image (661) (1) (1).png>)
### Inyección de Línea de Solicitud vía espacios
![](<../../.gitbook/assets/image (641) (1).png>)
## Reutilización de conexión frontend->backend
A veces encontrarás que al realizar un ataque de HTTP Request Smuggling **solo puedes atacarte a ti mismo**. Esto podría ser porque el reverse proxy ha decidido **usar una conexión diferente con el servidor back-end** por IP.
Nota que **incluso** con esa **restricción** todavía puedes realizar ataques como **bypasses de autorización**, fuga de encabezados internos y ataques de **engaño y envenenamiento de caché**.
Usualmente esta restricción no existe por lo que puedes **introducir solicitudes en la conexión entre el reverse proxy y el back end** que otras personas están usando, pero es incluso **posible** que el **proxy** no **reutilice una conexión con conexiones de la misma IP** (restricción bastante pesada para este tipo de ataque).
![](<../../.gitbook/assets/image (646) (1) (1).png>)
En la restricción más pesada (sin reutilización de conexión) detectarás la vulnerabilidad con la técnica basada en tiempo, pero luego al probarla encontrarás que es un "falso positivo".
### Confirmación de Túnel
Una forma de **confirmar** si el **punto final es vulnerable** pero la conexión está **dentro de un "túnel"** es **introducir 2 solicitudes completas** en 1.
El **problema** con **HTTP/1.1** es que si **recibes 2 respuestas HTTP** no **sabes** si el punto final era **vulnerable** o no lo es y la **solicitud "introducida"** fue solo tratada como una solicitud regular.
Sin embargo, esta técnica se puede usar **en HTTP/2** porque si el punto final era **vulnerable** y introdujiste una solicitud, verás los **encabezados de la respuesta a la solicitud introducida en la respuesta del reverse proxy**:
![](<../../.gitbook/assets/image (652) (1) (1) (1).png>)
### Problema de Visión de Túnel
Podría haber otro problema, si la **respuesta** a la solicitud legítima **contiene** un **Content-Length**, el **reverse proxy** solo va a **leer los bytes especificados allí y no más, por lo que no podrás leer la respuesta de la solicitud introducida.**
Sin embargo, la solicitud **HEAD** **no contiene cuerpo** pero usualmente **contiene** el **Content-Length** como si la solicitud fuera un GET. Por lo tanto, enviando una solicitud **HEAD** **en lugar de una POST** puedes **leer los bytes del Content-Length de HEAD** de la respuesta de la solicitud introducida.
![](<../../.gitbook/assets/image (628) (1) (1).png>)
### Fuga de Encabezados Internos vía Túnel
Si encuentras un **parámetro POST** dentro de la aplicación cuyo **contenido** va a ser **reflejado** en la **respuesta**, entonces puedes intentar inyectar caracteres HTTP/1.1 \r\n dentro de un encabezado de solicitud HTTP/2 para que los nuevos encabezados inyectados por el proxy se añadan en el parámetro POST que será reflejado en la respuesta:
![](<../../.gitbook/assets/image (656) (1) (1).png>)
Nota que en este caso el **atacante** solo se preocupa por la **respuesta** a la **primera** **solicitud**, no necesita leer la solicitud a la segunda solicitud inválida introducida.
{% hint style="info" %}
Usar este ataque **contra diferentes partes de la web (método, camino...)** puede llevar a que se usen diferentes back-ends y **se filtre diferente información sensible**
{% endhint %}
### Envenenamiento de Caché vía Túnel
En este escenario se envía una solicitud **HEAD** a la **URL** **cuya** **caché** va a ser **envenenada** mientras se **introduce** una **solicitud** cuyo **contenido de la respuesta contendrá el payload** (quizás algún payload XSS).
Debido al hecho de que la **respuesta HEAD contiene el `Content-Type: text/html`** y porque el reverse proxy piensa que la **respuesta completa a la solicitud introducida es el cuerpo de la solicitud HEAD**, el **payload XSS** va a ser **tratado como HTML** incluso si la página no era vulnerable a XSS.
![](<../../.gitbook/assets/image (659) (1).png>)
## HTTP/2 Oculto
Normalmente los servidores anuncian el soporte a través del campo ALPN en el handshake TLS, pero algunos no lo hacen.
Se puede detectar fácilmente usando `curl --http2 --http2-prior-knowledge`
## Herramientas
* Extensión de Burp: HTTP Request Smuggler
* [https://github.com/neex/http2smugl](https://github.com/neex/http2smugl)
## Referencias
* Esta charla explica perfectamente todas las técnicas indicadas aquí: [https://www.youtube.com/watch?v=rHxVVeM9R-M](https://www.youtube.com/watch?v=rHxVVeM9R-M)
<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>