HTTP Response Smuggling / Desync
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 eso:
La principal diferencia entre esta técnica y una desincronización común de solicitudes HTTP 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 sea enviada 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 respuesta de la víctima, sino que se descartará como un error.
Por lo tanto, es necesario que la solicitud solicitada tome más tiempo en ser procesada dentro del servidor backend. Por lo tanto, cuando la solicitud solicitada se procese, la comunicación con el atacante habrá terminado.
En esta situación específica, si una víctima ha enviado una solicitud y la solicitud solicitada se responde antes de la solicitud legítima, la respuesta solicitada 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 de 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).
Inyecciones Anidadas Múltiples
Otra diferencia interesante con el ataque común de Desincronización de Solicitudes HTTP es que, en un ataque común de desincronizació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 recibirán 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 un DoS en el servidor.
Organización de Exploits
Como se explicó anteriormente, para abusar de esta técnica, es necesario que el primer mensaje solicitado en el servidor tome mucho tiempo en ser procesado.
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 Content-Length grande
Luego, una vez que la solicitud inicial (azul) fue procesada y mientras la 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 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 por desincronización de respuesta previamente comentado, 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é queda envenenada.
Solicitud maliciosa que contiene el payload XSS:
Respuesta maliciosa a la víctima que contiene el encabezado que indica a la caché que almacene la respuesta:
Ten en cuenta que en este caso si el "atacante" es la víctima ahora puede realizar envenenamiento de caché en URLs arbitrarias ya que puede controlar la URL que va a ser almacenada en caché con la respuesta maliciosa.
Engaño de Caché Web
Este ataque es similar al anterior, pero en lugar de inyectar un payload dentro de la caché, el atacante almacenará información de la víctima dentro de la caché:
División de Respuesta
El objetivo de este ataque es abusar nuevamente de la desincronización de respuesta para hacer que el proxy envíe una respuesta generada al 100% por el atacante.
Para lograr esto, el atacante necesita encontrar un punto final de la aplicación web que esté reflejando algunos valores dentro de la respuesta y conocer la longitud del contenido de la respuesta HEAD.
Enviaría un exploit como:
Después de que se resuelva y envíe la primera solicitud al atacante, la solicitud de la víctima se agrega a la cola:
La víctima recibirá como respuesta el HEAD response + 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 de la segunda víctima recibirá como respuesta algo completamente creado por el atacante. Como la respuesta está completamente creada por el atacante, también puede hacer que la caché del proxy almacene la respuesta.
Última actualización
