11 KiB
HTTP Response Smuggling / Desync
Aprende a hackear AWS desde cero hasta convertirte en un experto con htARTE (Experto en Equipos Rojos de AWS de HackTricks)!
Otras formas de apoyar a HackTricks:
- Si deseas ver tu empresa anunciada en HackTricks o descargar HackTricks en PDF, ¡Consulta los PLANES DE SUSCRIPCIÓN!
- Obtén la merchandising oficial de PEASS & HackTricks
- Descubre La Familia PEASS, nuestra colección exclusiva de NFTs
- Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦 @carlospolopm.
- Comparte tus trucos de hacking enviando PRs a los repositorios de HackTricks y HackTricks Cloud.
La técnica de este post fue tomada del video: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
Desincronización de la Cola de Solicitudes HTTP
En primer lugar, esta técnica abusa de una vulnerabilidad de Desincronización de Solicitudes HTTP, por lo que necesitas saber qué es:
La principal diferencia entre esta técnica y una Desincronización de Solicitudes HTTP común es que en lugar de atacar la solicitud de la víctima agregando un prefijo a la misma, vamos a filtrar o modificar la respuesta que recibe la víctima. Esto se logra enviando 2 solicitudes completas para desincronizar la cola de respuestas de los proxies, en lugar de enviar 1 solicitud y media para abusar de la Desincronización de Solicitudes HTTP.
Esto se debe a que vamos a poder desincronizar la cola de respuestas para que la respuesta de la solicitud legítima de la víctima se envíe al atacante, o inyectando contenido controlado por el atacante en la respuesta a la víctima.
Desincronización de Pipelining HTTP
HTTP/1.1 permite solicitar diferentes recursos sin necesidad de esperar los anteriores. Por lo tanto, si hay un proxy en el medio, es tarea de los proxies mantener una coincidencia sincronizada de las solicitudes enviadas al backend y las respuestas que provienen de él.
Sin embargo, hay un problema al desincronizar la cola de respuestas. Si un atacante envía un ataque de Desincronización de Respuestas HTTP y las respuestas a la solicitud inicial y la solicitada se responden inmediatamente, la respuesta solicitada no se insertará en la cola de respuestas de la víctima, sino que se descartará como un error.
Por lo tanto, es necesario que la solicitud filtrada tome más tiempo en procesarse dentro del servidor backend. Por lo tanto, cuando la solicitud filtrada se procese, la comunicación con el atacante habrá terminado.
Si en esta situación específica un atacante envía una solicitud y la solicitud filtrada se responde antes que la solicitud legítima, la respuesta filtrada se enviará a la víctima. Por lo tanto, el atacante estará controlando la solicitud "realizada" por la víctima.
Además, si el atacante luego realiza una solicitud y la respuesta legítima a la solicitud de la víctima se responde antes que la solicitud del atacante. La respuesta a la víctima se enviará al atacante, robando la respuesta a la víctima (que puede contener, por ejemplo, el encabezado Set-Cookie).
Múltiples Inyecciones Anidadas
Otra diferencia interesante con la Desincronización de Solicitudes HTTP común es que, en un ataque de desincronización común, el objetivo es modificar el inicio de la solicitud de la víctima para que realice una acción inesperada. En un ataque de desincronización de respuestas HTTP, al enviar solicitudes completas, puedes inyectar en una carga útil decenas de respuestas que desincronizarán a decenas de usuarios que estarán recibiendo las respuestas inyectadas.
Además de poder distribuir más fácilmente decenas de exploits entre usuarios legítimos, esto también podría usarse para causar una denegación de servicio en el servidor.
Organización de Exploits
Como se explicó anteriormente, para abusar de esta técnica, es necesario que el primer mensaje filtrado en el servidor requiera mucho tiempo para procesarse.
Esta solicitud que consume tiempo es suficiente si solo queremos intentar robar la respuesta de las víctimas. Pero si deseas realizar un exploit más complejo, esta será una estructura común para el exploit.
Primero la solicitud inicial abusando de la Desincronización de Solicitudes HTTP, luego la solicitud que consume tiempo y luego 1 o más solicitudes de carga útil cuyas respuestas se enviarán a las víctimas.
Abusando de la Desincronización de la Cola de Respuestas HTTP
Capturando las solicitudes de otros usuarios
Al igual que con las cargas útiles conocidas de Desincronización de Solicitudes HTTP, puedes robar la solicitud de las víctimas con una diferencia importante: En este caso, solo necesitas que el contenido enviado se refleje en la respuesta, no se necesita almacenamiento persistente.
Primero, el atacante envía una carga útil que contiene una solicitud POST final con el parámetro reflejado al final y un largo Content-Length
Luego, una vez que la solicitud inicial (azul) fue procesada y mientras la solicitud lenta se está procesando (amarilla), la próxima solicitud que llega de una víctima se va a agregar en la cola justo después del parámetro reflejado:
Entonces, la víctima recibirá la respuesta a la solicitud lenta y si en ese momento el atacante envía otra solicitud, la respuesta de la solicitud de contenido reflejado se le enviará.
Desincronización de Respuestas
Hasta este punto, hemos aprendido cómo abusar de los ataques de Desincronización de Solicitudes HTTP para controlar la solicitud cuya respuesta un cliente va a recibir y cómo luego puedes robar la respuesta que estaba destinada a la víctima.
Pero aún es posible desincronizar aún más las respuestas.
Existen solicitudes interesantes como la solicitud HEAD que se especifican para no tener ningún contenido dentro del cuerpo de las respuestas y que deben (deben) contener el Content-Length de la solicitud como si fuera una solicitud GET.
Por lo tanto, si un atacante inyecta una solicitud HEAD, como en estas imágenes:
Entonces, una vez que la azul es respondida al atacante, la próxima solicitud de la víctima se introducirá en la cola:
Entonces, la víctima recibirá la respuesta de la solicitud HEAD, que va a contener un Content-Length pero sin contenido alguno. Por lo tanto, el proxy no enviará esta respuesta a la víctima, sino que esperará algún contenido, que en realidad será la respuesta a la solicitud amarilla (también inyectada por el atacante):
Confusión de Contenido
Siguiendo el ejemplo anterior, sabiendo que puedes controlar el cuerpo de la solicitud cuya respuesta va a recibir la víctima y que una respuesta HEAD generalmente contiene en sus encabezados el Content-Type y el Content-Length, puedes enviar una solicitud como la siguiente para causar XSS en la víctima sin que la página sea vulnerable a XSS:
Envenenamiento de Caché
Abusando del ataque de Confusión de Contenido de desincronización de respuestas comentado anteriormente, si la caché almacena la respuesta a la solicitud realizada por la víctima y esta respuesta es una inyectada que causa un XSS, entonces la caché está envenenada.
Solicitud maliciosa que contiene la carga útil de XSS:
Respuesta maliciosa a la víctima que contiene el encabezado que indica a la caché que almacene la respuesta:
{% hint style="warning" %} Ten en cuenta que en este caso, si el "víctima" es el atacante, ahora puede realizar envenenamiento de caché en URLs arbitrarias ya que puede controlar la URL que se va a cachear con la respuesta maliciosa. {% endhint %}
Decepción de Caché Web
Este ataque es similar al anterior, pero en lugar de inyectar una carga útil dentro de la caché, el atacante almacenará información de la víctima dentro de la caché:
División de Respuestas
El objetivo de este ataque es abusar nuevamente de la desincronización de respuestas para hacer que el proxy envíe una respuesta 100% generada por el atacante.
Para lograr esto, el atacante necesita encontrar un punto final de la aplicación web que refleje algunos valores dentro de la respuesta y conocer la longitud del contenido de la respuesta HEAD.
Enviar un exploit como:
Después de que la primera solicitud se resuelva y se envíe de vuelta al atacante, la solicitud de la víctima se agrega a la cola:
La víctima recibirá como respuesta la respuesta HEAD + el contenido de la respuesta de la segunda solicitud (que contiene parte de los datos reflejados):
Sin embargo, observa cómo los datos reflejados tenían un tamaño de acuerdo con el Content-Length de la respuesta HEAD que generó una respuesta HTTP válida en la cola de respuestas.
Por lo tanto, la próxima solicitud del segundo usuario recibirá como respuesta algo completamente creado por el atacante. Como la respuesta está completamente creada por el atacante, también puede hacer que el proxy almacene en caché la respuesta.