Os sistemas web onde o frontend aceita conexões via HTTP / 2 e os passa para o back-end via HTTP / 1.1 hforam expostos a uma nova versão do ataque de "contrabando de solicitação HTTP", Permite, por meio do envio de solicitações de clientes especialmente projetadas, dividir o conteúdo das solicitações de outros usuários processadas no mesmo fluxo entre o frontend e o backend.
Ataque pode ser usado para injetar código JavaScript malicioso em uma sessão com um site legítimo, contorne os sistemas de restrição de acesso e intercepte os parâmetros de autenticação.
O autor do estudo demonstrou a possibilidade de atacar os sistemas Netflix, Verizon, Bitbucket, Netlify CDN e Atlassiane recebeu US $ 56.000 em programas de recompensa pela identificação de vulnerabilidades. O problema também foi confirmado nos produtos da F5 Networks.
O problema afeta parcialmente o mod_proxy no servidor Apache http (CVE-2021-33193), correções esperadas na versão 2.4.49 (os desenvolvedores foram notificados do problema no início de maio e tiveram 3 meses para corrigi-lo). No nginx, a capacidade de especificar simultaneamente os cabeçalhos "Content-Length" e "Transfer-Encoding" foi bloqueada na versão anterior (1.21.1).
O princípio de operação do novo método de solicitações correspondentes no tráfego é semelhante à vulnerabilidade descoberta pelo mesmo pesquisador há dois anos, mas é limitado a interfaces que aceitam solicitações sobre HTTP / 1.1.
O clássico ataque de "contrabando de solicitação HTTP" foi baseado no fato de que front-ends e back-ends interpretam o uso de cabeçalhos HTTP "Content-Length" de maneira diferente (determina o tamanho total dos dados na solicitação) e "Transfer-Encoding: chunked" ( permite que você transfira dados em blocos) ...
Por exemplo, se a interface suporta apenas "Content-Length", mas ignora "Transfer-Encoding: Fragmented", um invasor pode enviar uma solicitação que contém os cabeçalhos "Content-Length" e "Transfer-Encoding: Fragmented", mas o tamanho pt O "Comprimento do conteúdo" não corresponde ao tamanho da string fragmentada. Nesse caso, o frontend processará e redirecionará a solicitação de acordo com o "Comprimento do conteúdo", e o backend aguardará a conclusão do bloqueio com base na "Codificação de transferência: fragmentado".
Ao contrário do protocolo HTTP / 1.1 textual, que é analisado no nível da linha, HTTP / 2 é um protocolo binário e manipula blocos dados de um tamanho predeterminado. No entanto, HTTP / 2 usar pseudo-cabeçalhos que correspondem aos cabeçalhos HTTP normais. Ao interagir com o backend usando o protocolo HTTP / 1.1, o frontend traduz esses pseudo-cabeçalhos em cabeçalhos HTTP / 1.1 HTTP semelhantes. O problema é que o back-end toma decisões sobre a análise da transmissão com base nos cabeçalhos HTTP definidos pelo front-end, sem saber os parâmetros da solicitação original.
Mesmo na forma de pseudo-cabeçalhos, os valores "Content-length" e "transfer-encoding" eles podem ser transmitidos, embora não sejam usados em HTTP / 2, uma vez que o tamanho de todos os dados é determinado em um campo separado. No entanto, ao converter uma solicitação HTTP / 2 para HTTP / 1.1, esses cabeçalhos passam e podem ser confusos para o back-end.
Existem duas opções principais de ataque: H2.TE e H2.CL, em que o back-end é enganado por uma codificação de transferência incorreta ou um valor de comprimento de conteúdo que não corresponde ao tamanho real do corpo da solicitação recebido pelo front-end por meio do protocolo HTTP / 2.
Como exemplo do ataque H2.CL, um tamanho incorreto é especificado no pseudo-cabeçalho comprimento do conteúdo ao enviar uma solicitação HTTP / 2 para Netflix. Esta solicitação leva à adição de um cabeçalho Comprimento do conteúdo HTTP semelhante ao acessar o back-end via HTTP / 1.1, mas desde o tamanho em Comprimento do conteúdo for menor que o real, uma parte dos dados na fila será processada como o início da próxima solicitação.
As ferramentas de ataque já foram adicionadas ao kit de ferramentas do Burp e estão disponíveis como uma extensão do Turbo Intruder. Proxies da Web, balanceadores de carga, aceleradores da Web, sistemas de entrega de conteúdo e outras configurações em que as solicitações são redirecionadas em um esquema frontend-backend são suscetíveis ao problema.
fonte: https://portswigger.net