# Upgrade de Header Smuggling
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
- 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)
- Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
- **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Compartilhe seus truques de hacking enviando PRs para o [repositório hacktricks](https://github.com/carlospolop/hacktricks) e [repositório hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
Encontre vulnerabilidades que são mais importantes para que você possa corrigi-las mais rapidamente. O Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha de tecnologia, desde APIs até aplicativos da web e sistemas em nuvem. [**Experimente gratuitamente**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) hoje.
{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}
***
## H2C Smuggling
### HTTP2 Sobre Texto Limpo (H2C)
Uma conexão HTTP normalmente dura apenas durante a duração de uma única solicitação. No entanto, H2C ou "**http2 sobre texto limpo**" é onde uma conexão http transitória normal é atualizada para uma conexão persistente que usa o protocolo binário http2 para se comunicar continuamente em vez de uma solicitação usando o protocolo http em texto simples.
A segunda parte do smuggling ocorre quando um **proxy reverso é usado**. Normalmente, quando solicitações http são feitas a um proxy reverso, o proxy lidará com a solicitação, processará uma série de regras de roteamento e, em seguida, encaminhará a solicitação para o backend e retornará a resposta. Quando uma solicitação http inclui um cabeçalho `Connection: Upgrade`, como para uma conexão websocket, o proxy reverso manterá a conexão persistente entre o cliente e o servidor, permitindo a comunicação contínua necessária para esses protocolos. Para uma conexão H2C, o RFC requer que 3 cabeçalhos estejam presentes:
```
Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
Connection: Upgrade, HTTP2-Settings
```
Então, onde está o bug? **Ao atualizar uma conexão, o proxy reverso geralmente para de lidar com solicitações individuais**, assumindo que, uma vez estabelecida a conexão, seu trabalho de roteamento está concluído. Usando o H2C Smuggling, podemos contornar as regras que um proxy reverso usa ao processar solicitações, como roteamento baseado em caminho, autenticação ou processamento do WAF, desde que possamos estabelecer uma conexão H2C primeiro.
.png>)
### Proxies Vulneráveis
Observe na explicação da vulnerabilidade que o servidor proxy precisa **encaminhar o cabeçalho Upgrade**, e às vezes o **cabeçalho Connection** também precisa ser encaminhado com sucesso.
Por padrão, os seguintes serviços **encaminham** os cabeçalhos **Upgrade** e **Connection** durante o proxy-pass, permitindo assim o h2c smuggling "out-of-the-box":
* HAProxy
* Traefik
* Nuster
Por padrão, esses serviços **não** encaminham ambos os cabeçalhos Upgrade e Connection durante o proxy-pass, mas **podem ser configurados de maneira insegura** (passando cabeçalhos Upgrade e Connection não filtrados):
* AWS ALB/CLB
* NGINX
* Apache
* Squid
* Varnish
* Kong
* Envoy
* Apache Traffic Server
### Exploração
A postagem original do blog aponta que nem todos os servidores encaminharão os cabeçalhos necessários para uma atualização de conexão H2C compatível. Isso significa que balanceadores de carga como AWS ALB/CLB, NGINX e Apache Traffic Server, entre outros, **impedirão uma conexão H2C por padrão**. No entanto, no final da postagem do blog, ele menciona que "nem todos os backends eram compatíveis, e nós poderíamos **testar com a variante não compatível `Connection: Upgrade`, onde o valor `HTTP2-Settings` é omitido** do cabeçalho `Connection`."
{% hint style="danger" %}
Observe que, mesmo que a URL `proxy_pass` (o ponto final para o qual o proxy encaminha a conexão) esteja apontando para um **caminho** específico, como `http://backend:9999/socket.io`, a conexão será estabelecida com `http://backend:9999`, portanto, você pode **acessar qualquer outro caminho dentro desse ponto final interno abusando dessa técnica. Portanto, não importa se um caminho é especificado na URL do proxy\_pass.**
{% endhint %}
Usando as ferramentas [**https://github.com/BishopFox/h2csmuggler**](https://github.com/BishopFox/h2csmuggler) **e** [**https://github.com/assetnote/h2csmuggler**](https://github.com/assetnote/h2csmuggler), você pode tentar **burlar as proteções impostas** pelo proxy estabelecendo uma conexão H2C e acessar recursos protegidos pelo proxy.
Siga este link para [**mais informações sobre essa vulnerabilidade no Nginx**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection).
## Websocket Smuggling
Semelhante à técnica anterior, esta **em vez de criar um túnel HTTP2** para um ponto final acessível por meio de um proxy, criará um **túnel Websocket** para o mesmo propósito, **contornando as limitações potenciais dos proxies** e se comunicando diretamente com o ponto final:
 (2) (1).png>)
### Cenário 1
Temos um backend que expõe uma **API WebSocket pública** e também possui uma **API REST interna não disponível** externamente. Um cliente malicioso deseja acessar a API REST interna.
No **primeiro** passo, o cliente envia uma **solicitação de atualização** para o proxy reverso, mas com uma **versão de protocolo incorreta** no cabeçalho `Sec-WebSocket-Version`. O **proxy** não valida o cabeçalho `Sec-WebSocket-Version` e acredita que a **solicitação de atualização está correta**. Em seguida, ele traduz a solicitação para o backend.
No segundo passo, o backend envia uma **resposta com o código de status `426` porque a versão do protocolo está incorreta** no cabeçalho `Sec-WebSocket-Version`. No entanto, o **proxy reverso não verifica** suficientemente a resposta do backend (incluindo o código de status) e **acredita que o backend está pronto para a comunicação WebSocket**. Em seguida, ele traduz a solicitação para o cliente.
Por fim, o **proxy reverso acredita** que a **conexão WebSocket está estabelecida entre o cliente e o backend**. Na realidade, não há conexão WebSocket - o backend recusou a solicitação de atualização. Ao mesmo tempo, o proxy mantém a conexão TCP ou TLS entre o cliente e o backend aberta. O **cliente pode facilmente acessar a API REST privada enviando uma solicitação HTTP pela conexão**.
Foi constatado que os seguintes proxies reversos são afetados:
* Varnish - a equipe se recusou a corrigir o problema descrito.
* Envoy proxy 1.8.0 (ou anterior) - nas versões mais recentes, o mecanismo de atualização foi alterado.
* Outros - A ser anunciado.
### Cenário 2
A maioria dos proxies reversos (por exemplo, NGINX) **verifica o código de status do backend** durante a parte de handshake. Isso torna o ataque mais difícil, mas não impossível.
Vamos observar o segundo cenário. Temos um backend que expõe uma API WebSocket pública e uma API REST pública para verificação de integridade e também possui uma **API REST interna não disponível externamente**. Um cliente malicioso deseja acessar a API REST interna. O NGINX é usado como proxy reverso. A API WebSocket está disponível no caminho `/api/socket.io/` e a API de verificação de integridade no caminho `/api/health`.
A API de verificação de integridade é invocada enviando uma solicitação POST, o parâmetro com o nome `u` controla a URL. O backend alcança um recurso externo e retorna o código de status de volta para o cliente.
No **primeiro** passo, o cliente envia uma solicitação POST para invocar a **API de verificação de integridade, mas com um cabeçalho HTTP adicional `Upgrade: websocket`**. O NGINX acredita que é uma **solicitação de atualização normal**, ele verifica apenas o cabeçalho `Upgrade`, ignorando outras partes da solicitação. Em seguida, o proxy traduz a solicitação para o backend.
No **segundo** passo, o backend invoca a API de verificação de integridade. Ele alcança um recurso externo controlado por usuários maliciosos que retorna uma **resposta HTTP com o código de status `101`**. O backend traduz essa resposta para o proxy reverso. Como o NGINX valida apenas o código de status, **ele acreditará que o backend está pronto para a comunicação WebSocket**. Em seguida, ele traduz a solicitação para o cliente.
{% hint style="warning" %}
Observe como esse cenário é muito mais complexo de explorar, pois você precisa ser capaz de entrar em contato com algum ponto final que **retorne o código de status 101**.
{% endhint %}
Finalmente, o **NGINX acredita que a conexão WebSocket está estabelecida entre o cliente e o backend**. Na realidade, não há conexão WebSocket - a API REST de verificação de integridade foi invocada no backend. Ao mesmo tempo, o proxy reverso mantém a conexão TCP ou TLS entre o cliente e o backend aberta. O **cliente pode facilmente acessar a API REST privada enviando uma solicitação HTTP pela conexão**.
A maioria dos proxies reversos deve ser afetada por esse cenário. No entanto, a exploração requer a existência 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)
Encontre vulnerabilidades que são mais importantes para que você possa corrigi-las mais rapidamente. O Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha de tecnologia, desde APIs até aplicativos da web e sistemas em nuvem. [**Experimente gratuitamente**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) hoje.
{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
- 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)
- Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
- **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Compartilhe seus truques de hacking enviando PRs para o [repositório hacktricks](https://github.com/carlospolop/hacktricks) e [repositório hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
.png)