# Cross-site WebSocket hijacking (CSWSH)
☁️ 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**? Confira 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 do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do 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 suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
## O que são WebSockets As conexões WebSocket são iniciadas por meio do **HTTP** e geralmente são **de longa duração**. As mensagens podem ser enviadas em **ambas as direções a qualquer momento** e não são transacionais por natureza. A conexão normalmente permanecerá aberta e ociosa até que o cliente ou o servidor esteja pronto para enviar uma mensagem.\ Os WebSockets são particularmente úteis em situações em que são necessárias **mensagens de baixa latência ou iniciadas pelo servidor**, como feeds em tempo real de dados financeiros. ## Como as conexões WebSocket são estabelecidas? (Aqui você encontrará um resumo, mas um **guia mais detalhado sobre como uma conexão de web socket** é criada pode ser encontrado [**aqui**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc)).\ As conexões WebSocket são normalmente criadas usando JavaScript do lado do cliente, como o seguinte: ```javascript var ws = new WebSocket("wss://normal-website.com/chat"); ``` O protocolo **`wss`** estabelece um WebSocket sobre uma conexão **TLS** criptografada, enquanto o protocolo **`ws`** usa uma conexão **não criptografada**. Para estabelecer a conexão, o navegador e o servidor realizam um handshake WebSocket sobre HTTP. O navegador emite uma solicitação de handshake WebSocket como a seguinte: ```javascript GET /chat HTTP/1.1 Host: normal-website.com Sec-WebSocket-Version: 13 Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w== Connection: keep-alive, Upgrade Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2 Upgrade: websocket ``` Se o servidor aceita a conexão, ele retorna uma resposta de handshake do WebSocket como a seguinte: ```javascript HTTP/1.1 101 Switching Protocols Connection: Upgrade Upgrade: websocket Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk= ``` Neste ponto, a conexão de rede permanece aberta e pode ser usada para enviar mensagens WebSocket em ambas as direções. **Nota** Várias **características** das mensagens de **handshake** do WebSocket são dignas de nota: * Os cabeçalhos **`Connection`** e **`Upgrade`** na solicitação e resposta **indicam** que este é um **handshake WebSocket**. * O cabeçalho de solicitação **`Sec-WebSocket-Version`** especifica a **versão do protocolo WebSocket** que o cliente deseja usar. Isso é tipicamente `13`. * O cabeçalho de solicitação **`Sec-WebSocket-Key`** contém um **valor aleatório** codificado em Base64, que deve ser gerado aleatoriamente em cada solicitação de handshake. * O cabeçalho de resposta **`Sec-WebSocket-Accept`** contém um hash do valor enviado no cabeçalho de solicitação `Sec-WebSocket-Key`, concatenado com uma string específica definida na especificação do protocolo. Isso é feito para evitar respostas enganosas resultantes de servidores mal configurados ou proxies de cache. O cabeçalho **`Sec-WebSocket-Key`** contém um **valor aleatório** para evitar erros de proxies de cache e **não é usado para fins de autenticação ou manipulação de sessão** (_Não é um token CSRF_). ### Console Linux Você pode usar o `websocat` para estabelecer uma conexão bruta com um websocket. ```bash websocat --insecure wss://10.10.10.10:8000 -v ``` Ou para criar um servidor websocat: ```bash websocat -s 0.0.0.0:8000 #Listen in port 8000 ``` ## Conexões websocket MitM Se você descobrir que os clientes estão conectados a um **websocket HTTP** a partir da sua rede local atual, você pode tentar um [Ataque de Spoofing ARP](../generic-methodologies-and-resources/pentesting-network/#arp-spoofing) para realizar um ataque MitM entre o cliente e o servidor.\ Assim que o cliente tentar se conectar, você pode usar: ```bash websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v ``` ## Enumeração de WebSockets Você pode usar a **ferramenta** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) **para descobrir, identificar e procurar por** **vulnerabilidades** **conhecidas** em websockets automaticamente. ## Hijacking de WebSocket entre sites (CSWSH) Também conhecido como _hijacking de WebSocket entre origens cruzadas_.\ **É um** [**Cross-Site Request Forgery (CSRF)**](csrf-cross-site-request-forgery.md) **em um handshake de WebSocket.** Isso ocorre quando a solicitação de **handshake de WebSocket** depende exclusivamente de **cookies HTTP** para o tratamento de sessões e **não contém nenhum token CSRF** ou outros valores imprevisíveis.\ Um atacante pode criar uma **página da web maliciosa** em seu próprio domínio que **estabelece uma conexão de WebSocket entre sites** com o aplicativo vulnerável. O aplicativo lidará com a conexão no **contexto da sessão do usuário vítima** com o aplicativo. ### Ataque Simples Observe que ao **estabelecer** uma conexão **websocket**, o **cookie** é **enviado** para o servidor. O **servidor** pode estar usando-o para **relacionar** cada **usuário específico** com sua **sessão de websocket com base no cookie enviado**. Então, se, por **exemplo**, o **servidor websocket** **enviar de volta o histórico da conversa** de um usuário se uma mensagem com "**READY**" for enviada, então um **simples XSS** estabelecendo a conexão (o **cookie** será **enviado automaticamente** para autorizar o usuário vítima) **enviando** "**READY**" será capaz de **recuperar** o histórico da **conversa**: ```markup ``` ### Cross Origin + Cookie com um subdomínio diferente Neste post de blog [https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/](https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/), o atacante conseguiu **executar Javascript arbitrário em um subdomínio** do domínio onde a comunicação do websocket estava ocorrendo. Como era um **subdomínio**, o **cookie** estava sendo **enviado**, e como o **Websocket não verificava a Origem corretamente**, era possível se comunicar com ele e **roubar tokens dele**. ### Roubo de dados do usuário Copie a aplicação web que você deseja se passar (os arquivos .html, por exemplo) e dentro do script onde a comunicação do websocket está ocorrendo, adicione este código: ```javascript //This is the script tag to load the websocket hooker //These are the functions that are gonig to be executed before a message //is sent by the client or received from the server //These code must be between some