mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
84 lines
5.6 KiB
Markdown
84 lines
5.6 KiB
Markdown
# HTTP Connection Request Smuggling
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|
||
|
||
**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.
|
||
|
||
## Connection-State Attacks <a href="#state" id="state"></a>
|
||
|
||
### First-request Validation
|
||
|
||
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.example
|
||
|
||
GET /admin HTTP/1.1
|
||
Host: internal-only.example
|
||
```
|
||
### Roteamento do Primeiro Pedido
|
||
|
||
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: public.example
|
||
|
||
POST /pwreset HTTP/1.1
|
||
Host: private.internal
|
||
```
|
||
> [!TIP]
|
||
> No Burp Suite Professional ≥2022.10 você pode habilitar **HTTP Request Smuggler → Connection-state probe** para detectar automaticamente essas fraquezas.
|
||
|
||
---
|
||
|
||
## 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 `<img src="https://internal.company/…">` 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}}
|