mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/http-connection-request-smuggling.md'] t
This commit is contained in:
Translator
parent
71e37a784a
commit
12b354db54
@ -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 <a href="#state" id="state"></a>
|
||||
## Connection-State Attacks <a href="#state" id="state"></a>
|
||||
|
||||
### 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 `<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}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user