detalles de un nuevo ataque a sitios que utilizan un modelo front-end-back-end, como aquellos que se ejecutan a través de redes de entrega de contenido, balanceadores de carga o servidores proxy. El ataque permite, mediante el envío de determinadas solicitudes, introducirse en el contenido de otras solicitudes procesadas en el mismo hilo entre el frontend y el backend. El método propuesto se utilizó con éxito para organizar un ataque que permitió interceptar los parámetros de autenticación de los usuarios del servicio PayPal, que pagó a los investigadores unos 40 mil dólares como parte de un programa para informar sobre la presencia de vulnerabilidades no parcheadas. El ataque también es aplicable a sitios que utilizan la red de distribución de contenidos Akamai.
El quid del problema es que los frontends y backends a menudo brindan diferentes niveles de soporte para el protocolo HTTP, pero al mismo tiempo encapsulan solicitudes de diferentes usuarios en un canal común. Para conectar las solicitudes de recepción de frontend y las solicitudes de procesamiento de backend, se establece una conexión TCP de larga duración, a través de la cual se transmiten las solicitudes de los usuarios, transmitidas a lo largo de la cadena una tras otra, separadas por medio del protocolo HTTP. Para separar solicitudes, los encabezados "Content-Length" (determina el tamaño total de los datos en la solicitud) y ""(le permite transferir datos en partes, especificando bloques de diferentes tamaños en el formato "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0").
El problema surge si la interfaz solo admite "Longitud de contenido" pero ignora "Codificación de transferencia: fragmentada" (por ejemplo, Akamai CDN hizo esto) o viceversa. Si Transfer-Encoding: fragmentado se admite en ambos lados, las funciones de implementación de los analizadores de encabezados HTTP se pueden usar para un ataque (por ejemplo, cuando el front-end ignora líneas como “Transfer-Encoding: xchunked”, “Transfer-Encoding: fragmentado” ”, “Codificación de transferencia” :[tab]fragmentado", "X: X[\n]Codificación de transferencia: fragmentado”, "Codificación de transferencia[\n]: fragmentado" o "Codificación de transferencia: fragmentado", y el backend los procesa exitosamente).
En este caso, un atacante puede enviar una solicitud que contenga los encabezados "Content-Length" y "Transfer-Encoding: fragmentado", pero el tamaño en "Content-Length" no corresponde al tamaño de la cadena fragmentada, lo que es menor que el valor real. Si el frontend procesa y reenvía la solicitud de acuerdo con "Content-Length" y el backend espera a que se complete el bloque según "Transfer-Encoding: fragmentado", entonces el final de los datos según "Transfer-Encoding: fragmentado" se determinará antes y la cola restante de la solicitud del atacante estará al comienzo de la siguiente solicitud, es decir el atacante podrá adjuntar datos arbitrarios al comienzo de la solicitud de otra persona transmitida a continuación.
Para determinar el problema en la combinación frontend-backend utilizada, puede enviar una solicitud como esta a través del frontend:
ENVIAR /acerca de HTTP/1.1
Anfitrión: example.com
Transferencia-Codificación: fragmentada
Content-Length: 4
1
Z
Q
El problema está presente si el backend no procesa inmediatamente la solicitud y espera la llegada del bloque final de datos fragmentados delimitados por cero. Para un control más completo una utilidad especial que también prueba posibles métodos para ocultar el encabezado "Transfer-Encoding: fragmentado" de la interfaz.
Llevar a cabo un ataque real depende de las capacidades del sitio atacado, por ejemplo, al atacar la aplicación web Trello, se puede reemplazar el inicio de la solicitud (sustituir datos como “PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) y enviar un mensaje que incluya la solicitud original de un usuario externo y la Cookie de autenticación especificada en él. Para un ataque a saas-app.com, resultó posible sustituir el código JavaScript en la respuesta sustituyéndolo en uno de los parámetros de la solicitud. Para el ataque a redhat.com, se utilizó un controlador interno para redirigir al sitio web del atacante (una solicitud del formulario “POST /search?dest=../assets/idx?redir=//[email protected]/HTTP/1.1").
El uso del método para redes de distribución de contenido hizo posible reemplazar simplemente el sitio solicitado sustituyendo el encabezado "Host:". El ataque también se puede utilizar para envenenar el contenido de los sistemas de almacenamiento en caché y extraer datos confidenciales almacenados en caché. El pináculo del método fue la organización de un ataque a PayPal, que permitió interceptar las contraseñas enviadas por los usuarios durante la autenticación (la solicitud de iframe se modificó para ejecutar JavaScript en el contexto de la página paypal.com/us/gifts, por ejemplo cuyo CSP (Política de seguridad de contenidos) no se aplicó).
Curiosamente, en 2005 hubo una técnica de suplantación de solicitudes esencialmente similar que le permite falsificar datos en servidores proxy de almacenamiento en caché (Tomcat, squid, mod_proxy) o evitar el bloqueo del firewall especificando varias solicitudes "GET" o "POST" dentro de una sesión HTTP.
Fuente: opennet.ru