From 12b354db544b2ff744abdec283c552da2fbe0754 Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 12 Jul 2025 22:07:55 +0000 Subject: [PATCH] Translated ['src/pentesting-web/http-connection-request-smuggling.md'] t --- .../http-connection-request-smuggling.md | 79 +++++++++++++++---- 1 file changed, 64 insertions(+), 15 deletions(-) diff --git a/src/pentesting-web/http-connection-request-smuggling.md b/src/pentesting-web/http-connection-request-smuggling.md index a111f7343..a7933058b 100644 --- a/src/pentesting-web/http-connection-request-smuggling.md +++ b/src/pentesting-web/http-connection-request-smuggling.md @@ -2,33 +2,82 @@ {{#include ../banners/hacktricks-training.md}} -**Este é um resumo do post** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks) +**Esta página resume, estende e atualiza** a pesquisa seminal da PortSwigger sobre [Browser-Powered Desync Attacks](https://portswigger.net/research/browser-powered-desync-attacks) e trabalhos subsequentes sobre abuso de estado de conexão HTTP/2. Foca em vulnerabilidades onde **uma origem é determinada apenas uma vez por conexão TCP/TLS**, permitindo que um atacante “contrabandeie” solicitações para um host interno diferente uma vez que o canal esteja estabelecido. -## Ataques de Estado de Conexão +## Connection-State Attacks -### Validação do Primeiro Pedido +### First-request Validation -Ao roteirizar solicitações, proxies reversos podem depender do **cabeçalho Host** para determinar o servidor back-end de destino, muitas vezes confiando em uma lista de permissões de hosts que têm acesso permitido. No entanto, uma vulnerabilidade existe em alguns proxies onde a lista de permissões é aplicada apenas na solicitação inicial em uma conexão. Consequentemente, atacantes poderiam explorar isso fazendo primeiro uma solicitação a um host permitido e, em seguida, solicitando um site interno através da mesma conexão: -``` +Ao roteirizar solicitações, proxies reversos podem depender do cabeçalho **Host** (ou **:authority** no HTTP/2) para determinar o servidor de back-end de destino, muitas vezes confiando em uma lista de permissões de hosts que têm acesso permitido. No entanto, existe uma vulnerabilidade em vários proxies onde a lista de permissões é **apenas aplicada na primeira solicitação em uma conexão**. Consequentemente, os atacantes podem acessar hosts virtuais internos enviando primeiro uma solicitação permitida e, em seguida, reutilizando a mesma conexão subjacente: +```http GET / HTTP/1.1 -Host: [allowed-external-host] +Host: allowed-external-host.example -GET / HTTP/1.1 -Host: [internal-host] +GET /admin HTTP/1.1 +Host: internal-only.example ``` ### Roteamento do Primeiro Pedido -Em algumas configurações, um servidor front-end pode usar o **cabeçalho Host do primeiro pedido** para determinar o roteamento de back-end para esse pedido e, em seguida, rotear persistentemente todos os pedidos subsequentes da mesma conexão de cliente para a mesma conexão de back-end. Isso pode ser demonstrado como: -``` +Muitos proxies reversos HTTP/1.1 mapeiam uma conexão de saída para um pool de back-end **baseando-se exclusivamente no primeiro pedido que eles encaminham**. Todos os pedidos subsequentes enviados através do mesmo socket de front-end são reutilizados silenciosamente, independentemente do cabeçalho Host. Isso pode ser combinado com ataques clássicos de [cabeçalho Host](https://portswigger.net/web-security/host-header) como envenenamento de redefinição de senha ou [envenenamento de cache web](https://portswigger.net/web-security/web-cache-poisoning) para obter acesso semelhante ao SSRF a outros hosts virtuais: +```http GET / HTTP/1.1 -Host: example.com +Host: public.example POST /pwreset HTTP/1.1 -Host: psres.net +Host: private.internal ``` -Esse problema pode potencialmente ser combinado com [Host header attacks](https://portswigger.net/web-security/host-header), como envenenamento de redefinição de senha ou [web cache poisoning](https://portswigger.net/web-security/web-cache-poisoning), para explorar outras vulnerabilidades ou obter acesso não autorizado a hosts virtuais adicionais. +> [!TIP] +> No Burp Suite Professional ≥2022.10 você pode habilitar **HTTP Request Smuggler → Connection-state probe** para detectar automaticamente essas fraquezas. -> [!NOTE] -> Para identificar essas vulnerabilidades, o recurso 'connection-state probe' no HTTP Request Smuggler pode ser utilizado. +--- + +## NOVO em 2023-2025 – Abuso de Coalescência de Conexão HTTP/2/3 + +Navegadores modernos frequentemente **coalescem** requisições HTTP/2 e HTTP/3 em uma única conexão TLS quando o certificado, protocolo ALPN e endereço IP coincidem. Se um front-end autoriza apenas a primeira requisição, cada requisição coalescida subsequente herda essa autorização – **mesmo que o Host/:authority mude**. + +### Cenário de Exploração +1. O atacante controla `evil.com`, que resolve para o mesmo nó de borda CDN que o alvo `internal.company`. +2. O navegador da vítima já possui uma conexão HTTP/2 aberta para `evil.com`. +3. O atacante incorpora uma `` oculta em sua página. +4. Como os parâmetros de conexão coincidem, o navegador reutiliza a conexão TLS **existente** e multiplexa a requisição para `internal.company`. +5. Se o CDN/roteador apenas validou a primeira requisição, o host interno é exposto. + +PoCs para Chrome/Edge/Firefox estão disponíveis na palestra de James Kettle *“HTTP/2: The Sequel is Always Worse”* (Black Hat USA 2023). + +### Ferramentas +* **Burp Suite 2023.12** introduziu um ponto de inserção experimental **HTTP/2 Smuggler** que tenta automaticamente coalescência e técnicas TE/CL. +* **smuggleFuzz** (https://github.com/microsoft/smugglefuzz) – Um framework Python lançado em 2024 para forçar vetores de desincronização front-end/back-end sobre HTTP/2 e HTTP/3, incluindo permutações de estado de conexão. + +### Mitigações +* Sempre **revalide Host/:authority em cada requisição**, não apenas na criação da conexão. +* Desative ou restrinja estritamente a **coalescência de origem** em camadas de CDN/balancer (por exemplo, `http2_origin_cn` desligado no NGINX). +* Implemente certificados ou endereços IP separados para nomes de host internos e externos para que o navegador não possa coalescê-los legalmente. +* Prefira **connection: close** ou `proxy_next_upstream` após cada requisição, quando prático. + +--- + +## Casos do Mundo Real (2022-2025) + +| Ano | Componente | CVE | Notas | +|------|-----------|-----|-------| +| 2022 | AWS Application Load Balancer | – | Cabeçalho Host validado apenas na primeira requisição; corrigido por meio de patch no mecanismo de regras (divulgado pela SecurityLabs). | +| 2023 | Apache Traffic Server < 9.2.2 | CVE-2023-39852 | Permitido o request smuggling via reutilização de conexão HTTP/2 quando `CONFIG proxy.config.http.parent_proxy_routing_enable` estava ativado. | +| 2024 | Envoy Proxy < 1.29.0 | CVE-2024-2470 | Validação inadequada de :authority após o primeiro stream permitiu request smuggling entre inquilinos em malhas compartilhadas. | + +--- + +## Cheat-Sheet de Detecção + +1. Envie duas requisições na **mesma** conexão TCP/TLS com cabeçalhos Host ou :authority diferentes. +2. Observe se a segunda resposta se origina do primeiro host (seguro) ou do segundo host (vulnerável). +3. No Burp: `Repeat → keep-alive → Send → Follow`. +4. Ao testar HTTP/2, abra um stream **dedicado** (ID 1) para um host benigno, depois multiplexe um segundo stream (ID 3) para um host interno e procure uma resposta. + +--- + +## Referências + +* PortSwigger Research – *HTTP/2: The Sequel is Always Worse* (Black Hat USA 2023) +* Aviso de Segurança do Envoy CVE-2024-2470 – Validação inadequada de autoridade {{#include ../banners/hacktricks-training.md}}