mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-24 13:43:24 +00:00
132 lines
11 KiB
Markdown
132 lines
11 KiB
Markdown
# Atualização de Smuggling de Cabeçalho
|
|
|
|
<details>
|
|
|
|
<summary><strong>Aprenda hacking AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Outras maneiras de apoiar o HackTricks:
|
|
|
|
* Se você quiser ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
|
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Compartilhe seus truques de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
|
|
|
|
</details>
|
|
|
|
**Grupo de Segurança Try Hard**
|
|
|
|
<figure><img src="/.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
|
|
|
|
{% embed url="https://discord.gg/tryhardsecurity" %}
|
|
|
|
***
|
|
|
|
### Smuggling H2C <a href="#http2-over-cleartext-h2c" id="http2-over-cleartext-h2c"></a>
|
|
|
|
#### HTTP2 Sobre Texto Puro (H2C) <a href="#http2-over-cleartext-h2c" id="http2-over-cleartext-h2c"></a>
|
|
|
|
H2C, ou **http2 sobre texto puro**, se desvia da norma de conexões HTTP transitórias ao atualizar uma conexão HTTP padrão para uma persistente. Essa conexão atualizada utiliza o protocolo binário http2 para comunicação contínua, em oposição à natureza de única solicitação do HTTP em texto simples.
|
|
|
|
A essência do problema de smuggling surge com o uso de um **proxy reverso**. Normalmente, o proxy reverso processa e encaminha solicitações HTTP para o backend, retornando a resposta do backend depois disso. No entanto, quando o cabeçalho `Connection: Upgrade` está presente em uma solicitação HTTP (comumente visto com conexões websocket), o **proxy reverso mantém uma conexão persistente** entre cliente e servidor, facilitando a troca contínua necessária por certos protocolos. Para conexões H2C, a conformidade com o RFC exige a presença de três cabeçalhos específicos:
|
|
```
|
|
Upgrade: h2c
|
|
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
|
|
Connection: Upgrade, HTTP2-Settings
|
|
```
|
|
A vulnerabilidade surge quando, após a atualização de uma conexão, o proxy reverso deixa de gerenciar solicitações individuais, assumindo que seu trabalho de roteamento está completo após o estabelecimento da conexão. A exploração do H2C Smuggling permite contornar as regras do proxy reverso aplicadas durante o processamento da solicitação, como roteamento baseado em caminho, autenticação e processamento de WAF, assumindo que uma conexão H2C seja iniciada com sucesso.
|
|
|
|
#### Proxies Vulneráveis <a href="#exploitation" id="exploitation"></a>
|
|
|
|
A vulnerabilidade depende do tratamento pelo proxy reverso dos cabeçalhos `Upgrade` e, às vezes, `Connection`. Os seguintes proxies encaminham esses cabeçalhos durante o proxy-pass, permitindo assim o H2C smuggling:
|
|
|
|
* HAProxy
|
|
* Traefik
|
|
* Nuster
|
|
|
|
Por outro lado, esses serviços não encaminham esses cabeçalhos durante o proxy-pass. No entanto, eles podem ser configurados de forma insegura, permitindo o encaminhamento não filtrado dos cabeçalhos `Upgrade` e `Connection`:
|
|
|
|
* AWS ALB/CLB
|
|
* NGINX
|
|
* Apache
|
|
* Squid
|
|
* Varnish
|
|
* Kong
|
|
* Envoy
|
|
* Apache Traffic Server
|
|
|
|
#### Exploração <a href="#exploitation" id="exploitation"></a>
|
|
|
|
É crucial observar que nem todos os servidores encaminham os cabeçalhos necessários para uma atualização de conexão H2C compatível. Portanto, servidores como AWS ALB/CLB, NGINX e Apache Traffic Server, entre outros, naturalmente bloqueiam conexões H2C. No entanto, vale a pena testar com a variante não compatível `Connection: Upgrade`, que exclui o valor `HTTP2-Settings` do cabeçalho `Connection`, pois alguns backends podem não estar em conformidade com os padrões.
|
|
|
|
{% hint style="danger" %}
|
|
Independentemente do **caminho** específico designado na URL `proxy_pass` (por exemplo, `http://backend:9999/socket.io`), a conexão estabelecida é padrão para `http://backend:9999`. Isso permite interagir com qualquer caminho dentro desse endpoint interno, aproveitando essa técnica. Portanto, a especificação de um caminho na URL `proxy_pass` não restringe o acesso.
|
|
{% endhint %}
|
|
|
|
As ferramentas [**h2csmuggler by BishopFox**](https://github.com/BishopFox/h2csmuggler) e [**h2csmuggler by assetnote**](https://github.com/assetnote/h2csmuggler) facilitam as tentativas de **contornar as proteções impostas pelo proxy** ao estabelecer uma conexão H2C, permitindo assim o acesso a recursos protegidos pelo proxy.
|
|
|
|
Para obter informações adicionais sobre essa vulnerabilidade, especialmente em relação ao NGINX, consulte [**este recurso detalhado**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection).
|
|
|
|
## Websocket Smuggling
|
|
|
|
O Websocket smuggling, ao contrário da criação de um túnel HTTP2 para um endpoint acessível por meio de um proxy, estabelece um túnel Websocket para contornar possíveis limitações do proxy e facilitar a comunicação direta com o endpoint.
|
|
|
|
### Cenário 1
|
|
|
|
Neste cenário, um backend que oferece uma API Websocket pública ao lado de uma API REST interna inacessível é alvo de um cliente malicioso em busca de acesso à API REST interna. O ataque se desenrola em várias etapas:
|
|
|
|
1. O cliente inicia enviando uma solicitação de Upgrade para o proxy reverso com uma versão de protocolo `Sec-WebSocket-Version` incorreta no cabeçalho. O proxy, falhando em validar o cabeçalho `Sec-WebSocket-Version`, considera a solicitação de Upgrade válida e a encaminha para o backend.
|
|
2. O backend responde com um código de status `426`, indicando a versão de protocolo incorreta no cabeçalho `Sec-WebSocket-Version`. O proxy reverso, ignorando o status de resposta do backend, assume prontidão para a comunicação Websocket e repassa a resposta ao cliente.
|
|
3. Consequentemente, o proxy reverso é enganado a acreditar que uma conexão Websocket foi estabelecida entre o cliente e o backend, enquanto, na realidade, o backend rejeitou a solicitação de Upgrade. Apesar disso, o proxy mantém uma conexão TCP ou TLS aberta entre o cliente e o backend, permitindo ao cliente acesso irrestrito à API REST privada por meio dessa conexão.
|
|
|
|
Os proxies reversos afetados incluem o Varnish, que se recusou a abordar o problema, e o proxy Envoy na versão 1.8.0 ou mais antiga, com versões posteriores tendo alterado o mecanismo de atualização. Outros proxies também podem ser suscetíveis.
|
|
|
|
![https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png)
|
|
|
|
### Cenário 2
|
|
|
|
Este cenário envolve um backend com uma API Websocket pública e uma API REST pública para verificação de saúde, juntamente com uma API REST interna inacessível. O ataque, mais complexo, envolve as seguintes etapas:
|
|
|
|
1. O cliente envia uma solicitação POST para acionar a API de verificação de saúde, incluindo um cabeçalho HTTP adicional `Upgrade: websocket`. O NGINX, atuando como proxy reverso, interpreta isso como uma solicitação de Upgrade padrão baseada apenas no cabeçalho `Upgrade`, ignorando os outros aspectos da solicitação, e a encaminha para o backend.
|
|
2. O backend executa a API de verificação de saúde, alcançando um recurso externo controlado pelo atacante que retorna uma resposta HTTP com o código de status `101`. Essa resposta, uma vez recebida pelo backend e encaminhada para o NGINX, engana o proxy a pensar que uma conexão Websocket foi estabelecida devido à validação apenas do código de status.
|
|
|
|
![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png)
|
|
|
|
> **Aviso:** A complexidade dessa técnica aumenta, pois requer a capacidade de interagir com um endpoint capaz de retornar um código de status 101.
|
|
|
|
Por fim, o NGINX é enganado a acreditar que uma conexão Websocket existe entre o cliente e o backend. Na realidade, essa conexão não existe; a API REST de verificação de saúde era o alvo. No entanto, o proxy reverso mantém a conexão aberta, permitindo ao cliente acessar a API REST privada por meio dela.
|
|
|
|
![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png)
|
|
|
|
A maioria dos proxies reversos é vulnerável a esse cenário, mas a exploração depende da presença de uma vulnerabilidade externa de SSRF, geralmente considerada um problema de baixa gravidade.
|
|
|
|
#### Laboratórios
|
|
|
|
Verifique os laboratórios para testar ambos os cenários em [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git)
|
|
|
|
### Referências
|
|
|
|
* [https://blog.assetnote.io/2021/03/18/h2c-smuggling/](https://blog.assetnote.io/2021/03/18/h2c-smuggling/)
|
|
* [https://bishopfox.com/blog/h2c-smuggling-request](https://bishopfox.com/blog/h2c-smuggling-request)
|
|
* [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git)
|
|
|
|
|
|
**Try Hard Security Group**
|
|
|
|
<figure><img src="/.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
|
|
|
|
{% embed url="https://discord.gg/tryhardsecurity" %}
|
|
|
|
<details>
|
|
|
|
<summary><strong>Aprenda hacking AWS do zero ao avançado com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Outras formas de apoiar o HackTricks:
|
|
|
|
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
|
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* Descubra [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Compartilhe suas dicas de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
|
|
|
</details>
|