Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md

10 KiB
Raw Blame History

Request Smuggling en Downgrades de HTTP/2

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

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.

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.

Ejemplos

Desincronización H2.CL

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:

Secuestro de Token de URL H2.TE Desync

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.

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.

Secuestro de Encabezado H2.TE Desync

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:

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.

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:

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:

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:

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:

Inyección de Línea de Solicitud vía espacios

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).

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:

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.

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:

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.

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

Referencias

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks: