detalles de un nuevo ataque a sitios que utilizan un modelo de frontend-backend, como aquellos que operan a través de redes de entrega de contenido, balanceadores o proxies. El ataque permite inyectar contenido en otras solicitudes procesadas en el mismo flujo entre el frontend y el backend a través del envío de solicitudes específicas. El método propuesto ha sido aplicado con éxito para llevar a cabo un ataque que permite interceptar los parámetros de autenticación de los usuarios del servicio PayPal, que pagó a los investigadores alrededor de 40 mil dólares como parte de su programa de recompensas por hallar vulnerabilidades no corregidas. El ataque también es aplicable a sitios que usan la red de entrega de contenido Akamai.
La esencia del problema radica en que los frontends y backends a menudo proporcionan diferentes niveles de soporte del protocolo HTTP, pero encapsulan las solicitudes de distintos usuarios en un canal común. Para la conexión entre el frontend que recibe solicitudes y el backend que las procesa, se establece una conexión TCP de larga duración, a través de la cual se transmiten las solicitudes de los usuarios, enviadas en cadena una tras otra con separación mediante el protocolo HTTP. Para dividir las solicitudes, se pueden usar los encabezados "Content-Length" (que determina el tamaño total de los datos en la solicitud) y "" (que permite enviar datos en partes, especificando bloques de diferentes tamaños en el formato "{tamaño}\r\n{bloque}\r\n{tamaño}\r\n{bloque}\r\n0").
El problema surge si el frontend solo admite "Content-Length" pero ignora "Transfer-Encoding: chunked" (por ejemplo, así actuaba el CDN Akamai) o viceversa. En el caso de que ambas partes admitan "Transfer-Encoding: chunked", se pueden aprovechar características de la implementación de los analizadores de encabezados HTTP para el ataque (por ejemplo, cuando el frontend ignora líneas como "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked", "Transfer-Encoding:[tab]chunked", "X: X[\n]Transfer-Encoding: chunked", "Transfer-Encoding[\n]: chunked" o "Transfer-Encoding : chunked", mientras que el backend las procesa correctamente).
En este caso, un atacante puede enviar una solicitud en la que se indican simultáneamente los encabezados «Content-Length» y «Transfer-Encoding: chunked», pero el tamaño en «Content-Length» no coincide con el tamaño de la cadena chunked, que es menor que el valor real. Si el front-end procesa y redirige la solicitud de acuerdo con «Content-Length», y el back-end espera que el bloque final se base en «Transfer-Encoding: chunked», entonces el final de los datos basado en «Transfer-Encoding: chunked» se determinará antes y el resto de la cola de la solicitud del atacante se encontrará al principio de la siguiente solicitud, es decir, el atacante podrá anexar datos arbitrarios al comienzo de la solicitud de otro usuario que se envía a continuación.
Para identificar el problema en la combinación de front-end y back-end, se puede enviar una solicitud del siguiente tipo desde el front-end:
POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 4
1
Z
Q
El problema existe si el back-end no procesa inmediatamente la solicitud y espera la llegada del bloque delimitador nulo final de los datos chunked. Para una verificación más completa una herramienta especial que también prueba los posibles métodos para ocultar el encabezado «Transfer-Encoding: chunked» del front-end.
La realización de un ataque real depende de las capacidades del sitio atacado; por ejemplo, al atacar la aplicación web Trello, se puede alterar el inicio de la solicitud (incluir datos como «PUT /1/members/1234… x=x&csrf=1234&username=testzzz&bio=cake») y enviar un mensaje que incluya la solicitud original de otro usuario y las cookies de autenticación que contiene. Para el ataque a saas-app.com, fue posible insertar código JavaScript en la respuesta, al inyectarlo en uno de los parámetros de la solicitud. Para el ataque a redhat.com, se utilizó un manejador interno para redirigir al sitio del atacante (se sustituyó una solicitud del tipo «POST /search?dest=..assetsidx?redir=//redhat.com@evil.net/ HTTP/1.1»).
La aplicación de este método para redes de entrega de contenido permitía simplemente reemplazar el sitio solicitado mediante la sustitución del encabezado "Host:". El ataque también es aplicable para la contaminación del contenido en sistemas de almacenamiento en caché y la extracción de datos sensibles en caché. El punto culminante de la aplicación del método fue la organización de un ataque a PayPal, que permitía interceptar las contraseñas enviadas por los usuarios durante la autenticación (se realizó una modificación en la solicitud del iframe para ejecutar JavaScript en el contexto de la página paypal.com/us/gifts, para la cual no se aplicaba CSP (Content Security Policy)).
Curiosamente, en 2005 se propuso , que permite modificar datos en proxies de almacenamiento en caché (Tomcat, squid, mod_proxy) o eludir bloqueos de cortafuegos al indicar múltiples solicitudes "GET" o "POST" dentro de una misma sesión HTTP.
Fuente: opennet.ru
