Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!
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!
- Adquira o swag oficial PEASS & HackTricks
- Descubra A Família PEASS, nossa coleção exclusiva de NFTs
- Junte-se ao 💬 grupo Discord ou ao grupo telegram ou siga-nos no Twitter 🐦 @carlospolopm.
- Compartilhe seus truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.
Grupo de Segurança Try Hard
{% embed url="https://discord.gg/tryhardsecurity" %}
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.
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
É 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 e h2csmuggler by assetnote 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.
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.
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:
- 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çalhoSec-WebSocket-Version
, considera a solicitação de Upgrade válida e a encaminha para o backend. - O backend responde com um código de status
426
, indicando a versão de protocolo incorreta no cabeçalhoSec-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. - 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.
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:
- 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çalhoUpgrade
, ignorando os outros aspectos da solicitação, e a encaminha para o backend. - 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.
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.
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.
Verifique os laboratórios para testar ambos os cenários em https://github.com/0ang3el/websocket-smuggle.git
- https://blog.assetnote.io/2021/03/18/h2c-smuggling/
- https://bishopfox.com/blog/h2c-smuggling-request
- https://github.com/0ang3el/websocket-smuggle.git
Try Hard Security Group
{% embed url="https://discord.gg/tryhardsecurity" %}
Aprenda hacking AWS do zero ao avançado com htARTE (HackTricks AWS Red Team Expert)!
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!
- Adquira o swag oficial PEASS & HackTricks
- Descubra The PEASS Family, nossa coleção exclusiva de NFTs
- Junte-se ao 💬 grupo Discord ou ao grupo telegram ou siga-nos no Twitter 🐦 @carlospolopm.
- Compartilhe suas dicas de hacking enviando PRs para o HackTricks e HackTricks Cloud github repos.