Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-28 07:31:10 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/h2c-smuggling.md

11 KiB
Raw Blame History

Atualização de Smuggling de Cabeçalho

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

Grupo de Segurança Try Hard

{% embed url="https://discord.gg/tryhardsecurity" %}

Smuggling H2C

HTTP2 Sobre Texto Puro (H2C)

H2C, ou http2 sobre texto puro, se desvia da norma de conexões HTTP transitórias, atualizando 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 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

É crucial observar que nem todos os servidores encaminham os cabeçalhos necessários para uma atualização de conexão H2C compatível. Como tal, 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. Consequentemente, 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.

Websocket Smuggling

O Websocket smuggling, ao contrário de criar 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 juntamente com 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

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

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.

No final, 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

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

Referências

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: