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

14 KiB
Raw Blame History

Upgrade de Header Smuggling

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

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 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.

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 e 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.

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:

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

Referências

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 hoje.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥