Un ataque a sistemas front-end-back-end que nos permite encaixar en solicitudes de terceiros

Revelado detalles dun novo ataque a sitios que usan un modelo front-end-back-end, como os que se executan a través de redes de entrega de contido, equilibradores de carga ou proxies. O ataque permite, mediante o envío de determinadas solicitudes, meterse no contido doutras solicitudes procesadas no mesmo fío entre o frontend e o backend. O método proposto utilizouse con éxito para organizar un ataque que permitiu interceptar os parámetros de autenticación dos usuarios do servizo PayPal, que pagou aos investigadores uns 40 mil dólares como parte dun programa para informar sobre a presenza de vulnerabilidades sen parches. O ataque tamén é aplicable aos sitios que utilizan a rede de entrega de contidos de Akamai.

O meollo do problema é que as interfaces e os backends adoitan ofrecer diferentes niveis de compatibilidade para o protocolo HTTP, pero ao mesmo tempo encapsulan as solicitudes de diferentes usuarios nunha canle común. Para conectar as solicitudes de recepción frontend e as solicitudes de procesamento backend, establécese unha conexión TCP de longa duración, a través da cal se transmiten as solicitudes dos usuarios, transmitidas ao longo da cadea unha tras outra, separadas mediante o protocolo HTTP. Para separar as solicitudes, os encabezados "Lonxitude do contido" (determina o tamaño total dos datos da solicitude) e "Codificación de transferencia: fragmentada"(permítelle transferir datos por partes, especificando bloques de diferentes tamaños no formato "{tamaño}\r\n{bloque}\r\n{tamaño}\r\n{bloque}\r\n0").

O problema xorde se a interface só admite "Lonxitude de contido" pero ignora "Codificación de transferencia: fragmentada" (por exemplo, Akamai CDN fixo isto) ou viceversa. Se se admite Transfer-Encoding: chunked en ambos os dous lados, as funcións de implementación dos analizadores de cabeceira HTTP pódense usar para un ataque (por exemplo, cando a interface ignora liñas como "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked". ”, “Codificación de transferencia” :[pestana] fragmentada", "X: X[\n]Codificación de transferencia: fragmentada", "Codificación de transferencia[\n]: fragmentada" ou "Codificación de transferencia: fragmentada", e o backend procesaos con éxito).

Neste caso, un atacante pode enviar unha solicitude que conteña tanto as cabeceiras "Content-Length" como "Transfer-Encoding: chunked", pero o tamaño en "Content-Length" non se corresponde co tamaño da cadea fragmentada, que é menor que o valor real. Se o frontend procesa e reenvía a solicitude segundo "Content-Length" e o backend espera a que o bloque se complete baseándose en "Transfer-Encoding: chunked", entón o final dos datos baseado en "Transfer-Encoding: chunked" determinarse antes e a cola restante da solicitude o atacante estará ao comezo da seguinte solicitude, é dicir. o atacante poderá achegar datos arbitrarios ao comezo da solicitude doutra persoa transmitida a continuación.

Un ataque a sistemas front-end-back-end que nos permite encaixar en solicitudes de terceiros

Para determinar o problema na combinación frontend-backend usada, pode enviar unha solicitude como esta a través do frontend:

POST /sobre HTTP/1.1
Anfitrión: exemplo.com
Codificación de transferencia: fragmentada
Lonxitude do contido: 4

1
Z
Q

O problema está presente se o backend non procesa inmediatamente a solicitude e espera a chegada do bloque final cero de datos fragmentados. Para unha comprobación máis completa preparado unha utilidade especial que tamén proba posibles métodos para ocultar a cabeceira "Transfer-Encoding: chunked" do frontend.

Realizar un ataque real depende das capacidades do sitio atacado, por exemplo, ao atacar a aplicación web de Trello, pode substituír o inicio da solicitude (substituír datos como “PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) e envíe unha mensaxe incluíndo a solicitude orixinal dun usuario de terceiros e a cookie de autenticación especificada nela. Para un ataque a saas-app.com, resultou posible substituír o código JavaScript na resposta substituíndoo nun dos parámetros da solicitude. Para o ataque a redhat.com, utilizouse un controlador interno para redirixir ao sitio web do atacante (unha solicitude do formulario "POST /search?dest=../assets/idx?redir=//[protexido por correo electrónico]/ HTTP/1.1").

O uso do método para as redes de entrega de contido permitiu substituír simplemente o sitio solicitado substituíndo a cabeceira "Host:". O ataque tamén se pode usar para envelenar o contido dos sistemas de almacenamento en caché de contido e extraer datos confidenciais almacenados na caché. O cumio do método foi a organización dun ataque a PayPal, que permitiu interceptar os contrasinais enviados polos usuarios durante a autenticación (modificouse a solicitude iframe para executar JavaScript no contexto da páxina paypal.com/us/gifts, para que non se aplicou CSP (Política de seguridade de contido).

Curiosamente, en 2005 houbo proposto unha técnica de suplantación de solicitudes esencialmente similar que che permite falsificar datos en proxies de caché (Tomcat, squid, mod_proxy) ou evitar o bloqueo do firewall especificando varias solicitudes "GET" ou "POST" nunha sesión HTTP.

Fonte: opennet.ru

Engadir un comentario