Introdução — Uma nova fronteira na pesquisa de vulnerabilidades HTTP

James Kettle, diretor de pesquisa da PortSwigger, é um nome que já é sinônimo de HTTP Request Smuggling. Foi ele quem, em 2019, colocou o tema de volta no radar da indústria com uma pesquisa que reabriu uma classe de vulnerabilidade que muitos consideravam resolvida. Agora ele está de volta com o HTTP Terminator, um sistema de pesquisa assistido por IA construído para caçar novas variantes de desync em escala.

O resultado inclui técnicas inéditas de exploração e, como cereja no topo, um zero-day identificado no Apache Traffic Server — um proxy maduro, amplamente utilizado e, presumivelmente, já bem escrutinado.

Neste post vamos explicar o que é HTTP desync para quem não trabalha com o tema no dia a dia, detalhar o que o HTTP Terminator faz de diferente, e discutir o que essa descoberta significa para quem defende infraestrutura HTTP em produção — sem promessas exageradas sobre o que a IA “resolve” nesse processo.

O que é HTTP Request Smuggling (Desync)?

HTTP Request Smuggling — também chamado de HTTP Desync Attack — explora uma ambiguidade fundamental: em uma cadeia de proxies, CDNs, load balancers e servidores de origem, cada componente pode interpretar os limites de uma requisição HTTP de forma diferente. Quando o front-end (proxy/CDN) e o back-end (servidor de origem) discordam sobre onde uma requisição termina e a próxima começa, um atacante consegue “contrabandear” uma requisição inteira escondida dentro de outra.

O exemplo clássico é a ambiguidade entre os cabeçalhos Content-Length e Transfer-Encoding: chunked. Se o front-end usa um cabeçalho para determinar o tamanho do corpo da requisição e o back-end usa o outro, um atacante pode construir uma requisição que os dois sistemas interpretam de formas incompatíveis. O que sobra “sobrando” na interpretação de um dos componentes é injetado como o início da próxima requisição de outro usuário na mesma conexão.

As consequências práticas incluem:

• Bypass de controles de segurança implementados no front-end (WAF, autenticação, restrições de acesso)
• Sequestro de sessão, quando a requisição contrabandeada é anexada à sessão de outro usuário
• Cache poisoning, envenenando respostas cacheadas com conteúdo controlado pelo atacante
• Exfiltração de dados, capturando respostas destinadas a outros usuários da mesma conexão reaproveitada

???? Vale conectar esse risco a outro ponto do nosso blog: quando uma sessão é sequestrada via desync, as defesas client-side tradicionais não ajudam muito — é um cenário que discutimos em Browser Isolation: A Defesa Final Contra Ameaças Web Modernas.

Por que essa técnica ainda é relevante 6 anos depois

A pesquisa de Kettle em 2019 (“HTTP Desync Attacks: Request Smuggling Reborn”) demonstrou que, apesar de HTTP Request Smuggling ser conhecido desde os anos 2000, a proliferação de arquiteturas com múltiplas camadas de proxy — CDNs, API gateways, service meshes — recriou constantemente novas superfícies de ambiguidade. Cada nova combinação de tecnologias front-end/back-end é, potencialmente, um novo vetor.

Seis anos depois, desync continua sendo uma categoria “viva” de vulnerabilidade, não um capítulo fechado. Novas implementações de servidores HTTP, novos protocolos (HTTP/2, HTTP/3) e novas topologias de infraestrutura continuam gerando variantes que os pesquisadores originais nem sempre previram.

O que é o HTTP Terminator?

O HTTP Terminator é o sistema de pesquisa assistido por IA que Kettle construiu para atacar esse problema em escala. A proposta central é usar IA para gerar e validar candidatos a vetores de desync — hipóteses sobre onde a ambiguidade de parsing HTTP pode existir entre diferentes implementações — e testá-los contra sites reais.

Em vez de um pesquisador humano formular manualmente cada variante de payload e testá-la caso a caso, o sistema gera um volume muito maior de hipóteses de exploração e as valida automaticamente, permitindo escalar o processo para milhares de sites reais.

IA gerando hipóteses de exploração em massa

A diferença central em relação à descoberta manual e artesanal de vulnerabilidades HTTP — que historicamente exigia profundo conhecimento de RFCs, implementações específicas de servidores e muita tentativa e erro guiada por intuição — é a capacidade de gerar e testar um número muito maior de combinações de forma sistemática.

Isso não torna o pesquisador humano dispensável. O papel da IA aqui é o de multiplicador de pesquisa: ela amplia a superfície de exploração testada, mas a interpretação dos resultados, a triagem do que é sinal versus ruído, e a validação de que um comportamento anômalo é de fato explorável continuam dependendo de expertise humana.

???? Esse padrão — IA como multiplicador de capacidade ofensiva, não substituto do analista — é o mesmo que discutimos em AI Agents Corporativos: Como Agentes Autônomos Estão Criando Novas Superfícies de Ataque nas Empresas, onde tratamos de como a autonomia de agentes de IA está mudando o cálculo de risco em ambientes corporativos.

O Zero-Day no Apache Traffic Server — Descoberta em Cascata

Um dos resultados mais notáveis do HTTP Terminator foi a identificação de um zero-day no Apache Traffic Server, um proxy reverso e servidor de cache amplamente utilizado, com anos de auditoria e uso em produção por operações de grande escala.

O processo que levou a essa descoberta é descrito como uma “cascata guiada por humanos”: a IA gera e testa hipóteses em volume, mas achados promissores são identificados, refinados e aprofundados por intervenção humana, que direciona a investigação para os sinais mais relevantes. Isso é diferente de um cenário de IA totalmente autônoma operando sem supervisão — o pesquisador continua no centro do processo de decisão sobre o que vale a pena investigar mais a fundo.

O fato de uma falha explorável ter sido encontrada em um software com essa maturidade reforça um ponto incômodo para times de infraestrutura: “amplamente auditado” não é sinônimo de “livre de vulnerabilidades desconhecidas”. Superfícies de parsing HTTP são complexas o suficiente para esconder ambiguidades exploráveis mesmo em código revisado por anos.

Nota editorial: os detalhes técnicos completos da vulnerabilidade no Apache Traffic Server, incluindo CVE e vetor de exploração específico, ainda dependem da divulgação completa por parte dos pesquisadores e do projeto Apache. Vamos publicar uma análise técnica dedicada assim que essas informações forem tornadas públicas.

???? Esse episódio é um bom lembrete de por que testes contínuos de segurança em infraestrutura crítica não são opcionais, mesmo para componentes considerados estáveis — tema que exploramos em A Importância da Criptografia de Dados e do Pentest em Ambientes de Big Data e Cloud.

IA como Multiplicador de Pesquisa Ofensiva — Limites e Potenciais

O caso do HTTP Terminator ilustra bem onde a IA hoje agrega valor real em pesquisa de segurança ofensiva, e onde ela ainda depende fortemente de supervisão humana.

O que a IA fez sozinha, nesse contexto, foi gerar e testar um volume de hipóteses de exploração que seria impraticável para um pesquisador humano cobrir manualmente em tempo equivalente. O que exigiu intervenção humana foi a curadoria desses resultados: distinguir comportamento anômalo genuíno de ruído, aprofundar a investigação em sinais promissores, e conduzir a análise que culminou na identificação do zero-day no Apache Traffic Server.

Essa divisão de trabalho — IA para escala, humano para julgamento — é central na discussão atual sobre autonomia de agentes em segurança ofensiva. Sistemas totalmente autônomos, sem supervisão, ainda não são o padrão predominante em pesquisas sérias como essa, e o próprio HTTP Terminator é descrito como um processo guiado, não uma IA operando sem controle.

Isso tem uma implicação dupla e desconfortável para quem trabalha em defesa. Por um lado, pesquisadores éticos como Kettle ganham velocidade e escala para encontrar e reportar vulnerabilidades antes que sejam exploradas maliciosamente — o que é bom para a indústria como um todo. Por outro lado, a mesma lógica de multiplicação de capacidade ofensiva via IA está disponível, em algum grau, para atores menos bem-intencionados. A defesa precisa assumir que a superfície de ataque testável em escala só vai crescer, e que “software maduro” não é mais argumento suficiente para baixar a guarda.