Los sistemas web en los que el frontend acepta conexiones a través de HTTP/2 y las pasa al backend a través de HTTP/1.1 han sido expuestos a una nueva versión del ataque «HTTP Request Smuggling», que permite mediante el envío de solicitudes de cliente especialmente diseñadas, dividir en el contenido de las solicitudes de otros usuarios procesadas en el mismo flujo entre el frontend y el backend.
El ataque se puede utilizar para inyectar código JavaScript malicioso en una sesión con un sitio legítimo, eludir los sistemas de restricción de acceso e interceptar los parámetros de autenticación.
El autor del estudio demostró la posibilidad de atacar sistemas de Netflix, Verizon, Bitbucket, Netlify CDN y Atlassian, y recibió 56.000 dólares en programas de recompensa por identificar vulnerabilidades. El problema también se ha confirmado en los productos de F5 Networks.
El problema afecta parcialmente a mod_proxy en el servidor http Apache (CVE-2021-33193), se esperan correcciones en la versión 2.4.49 (los desarrolladores fueron notificados del problema a principios de mayo y recibieron 3 meses para solucionarlo). En nginx, la capacidad de especificar simultáneamente los encabezados «Content-Length» y «Transfer-Encoding» se bloqueó en la versión anterior (1.21.1).
El principio de funcionamiento del nuevo método de encajar solicitudes en el tráfico es similar a la vulnerabilidad descubierta por el mismo investigador hace dos años, pero se limita a las interfaces que aceptan solicitudes a través de HTTP/1.1.
El clásico ataque de «Contrabando de solicitudes HTTP» se basó en el hecho de que los frontends y los backends interpretan de manera diferente el uso de los encabezados HTTP «Content-Length» (determina el tamaño total de los datos en la solicitud) y «Transfer-Encoding: chunked» ( le permite transferir datos en trozos) …
Por ejemplo, si la interfaz solo admite «Content-Length» pero ignora «Transfer-Encoding: fragmentado», un atacante puede enviar una solicitud que contenga los encabezados «Content-Length» y «Transfer-Encoding: fragmentado», pero el tamaño es El «Longitud del contenido» no coincide con el tamaño de la cadena fragmentada. En este caso, el frontend procesará y redirigirá la solicitud de acuerdo con la «Longitud del contenido», y el backend esperará a que el bloque se complete en función de la «Codificación de transferencia: fragmentada».
A diferencia del protocolo textual HTTP/1.1, que se analiza a nivel de línea, HTTP/2 es un protocolo binario y manipula bloques de datos de un tamaño predeterminado. Sin embargo, HTTP/2 usa pseudo-encabezados que corresponden a los encabezados HTTP normales. Al interactuar con el backend mediante el protocolo HTTP/1.1, el frontend traduce estos pseudo-encabezados en encabezados HTTP/1.1 HTTP similares. El problema es que el backend toma decisiones sobre el análisis de la transmisión basándose en los encabezados HTTP establecidos por el frontend, sin conocer los parámetros de la solicitud original.
Incluso en forma de pseudo-encabezados, los valores «content-length» y «transfer-encoding» se pueden transmitir, a pesar de que no se utilizan en HTTP/2, ya que el tamaño de todos los datos se determina en un campo separado. Sin embargo, al convertir una solicitud HTTP/2 a HTTP/1.1, estos encabezados se transfieren y pueden resultar confusos para el backend.
Hay dos opciones de ataque principales: H2.TE y H2.CL, en las que el backend es engañado por una codificación de transferencia incorrecta o un valor de longitud de contenido que no corresponde al tamaño real del cuerpo de la solicitud recibido por el frontend a través del Protocolo HTTP/2.
Como ejemplo del ataque H2.CL, se especifica un tamaño incorrecto en el pseudo-encabezado de longitud del contenido al enviar una solicitud HTTP/2 a Netflix. Esta solicitud conduce a la adición de un encabezado HTTP Content-Length similar al acceder al backend a través de HTTP/1.1, pero dado que el tamaño en Content-Length es menor que el real, una parte de los datos en la cola se procesa como el comienzo de la siguiente solicitud.
Las herramientas de ataque ya se han agregado al kit de herramientas de Burp y están disponibles como una extensión de Turbo Intruder. Los proxies web, equilibradores de carga, aceleradores web, sistemas de entrega de contenido y otras configuraciones en las que las solicitudes se redirigen en un esquema frontend-backend son susceptibles al problema.
Fuente: https://portswigger.net