Cross-Site WebSocket Hijacking (CSWSH)

09:24 Adriano Rocha 2 Comentarios

Websocket é um protocolo que tem como função habilitar o canal de comunicação full-duplex, persistente, entre servidores e clientes. Sendo assim, ambas as partes podem ser utilizadas para envio de dados a qualquer momento.

Utilizando o protocolo, também é possível fazer troca de mensagens de texto e binárias do servidor ao browser, e vice versa.

Como o protocolo vem sendo muito utilizado por desenvolvedores, passou a chamar a atenção dos analistas de segurança. E durante alguns experimentos e pentests dos analistas em aplicações que utilizam Websocket, foi identificado um tipo de cenário onde existe a vulnerabilidade chamada de Cross-Site Websocket Hijacking (CSWSH).

Para criar o canal de comunicação full-duplex o protocolo requer um handshake (realizado em http:// ou https://) para mudar para um protocolo WebSocket. O handshake faz um upgrade do protocolo de comunicação para ws:// (ou wss://), porém, por transferir a comunicação baseada em HTTP (S) para o WS(S), este processo de upgrade pode ser um potencial alvo de ataques e o ponto fraco da utilização deste protocolo.

O ciclo de vida da interação do Websocket entre cliente e servidor tipicamente é:

1- Cliente inicia uma conexão enviando um request de handshake HTTP (S) Websocket

2- Servidor responde com o handshake response (manipulado pelo servidor de forma transparente para a aplicação) e envia o status de 101 – troca de protocolos.

Desse ponto, tanto o servidor quando o browser se comunicam usando a API do Websocket, com uma conexão simétrica (cada lado pode enviar e recuperar mensagens de texto e binárias).

No nível do browser isso é definido pela especificação da W3´s HTML5 Websocket5 API, já no nível do protocolo via RFC 6455 “The Websocket Protocol”.

Abaixo, vamos analisar a solicitação de um handshake para fazer upgrade do protocolo para Websockets e inspecionar os headers em um cenário imaginário, que usa Websockets para mover rapidamente novas cotações de ações para usuários logados e também recuperar ordens de estoque deles.

GET /trading/ws/teste HTTP/1.1

Host: www.aplicacao.com.br

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Firefox/23.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip, deflate

DNT: 1

Sec-WebSocket-Version: 13

Origin: https://www.aplicacao.com.br

Sec-WebSocket-Key: x7nPlaiHMGDBuJeD6l7y/Q==

Cookie: JSESSIONID=1A9431CF043F851E0356F5837845B2EC

Connection: keep-alive, Upgrade

Pragma: no-cache

Cache-Control: no-cache

Upgrade: websocket

Como podemos ver, da requisição dos headers HTTP (S) handhake request, o dado de autenticação (cookie header) é enviado junto com o handshake de upgrade.

O mesmo seria verdade para os dados de autenticação HTTP. Ambos são corretamente comportados de acordo com a especificação mencionada anteriormente, RFC.

Após um handshake bem sucedido do Websocket, o servidor responde com o status 101 – Switching Protocols e a partir daí a conexão ws://(ou wss://) é estabelecida entre o browser e o servidor.

O header Sec-WebScoket-Key é uma parte do handshake interno do browser/servidor, é automaticamente criado e toma conta da iniciação do Websocket quando o browser faz o request.

Em relação do cliente durante esta fase de handshake/upgrade, o RFC 6455 diz o seguinte:

“This protocol doesn't prescribe any particular way that servers can authenticate clients during the WebSocket handshake. The WebSocket server can use any client authentication mechanism available to a generic HTTP server, such as cookies, HTTP authentication, or TLS authentication.”

Isso significa que desenvolvedores podem usar, por exemplo, cookies ou HTTP-Authenticantion para autenticar Websocket handshake request, como se fosse um request HTTP(S) de uma aplicação web.

Considerando o que acontece quando um desenvolvedor adota este estilo que utiliza sessões cookie para autenticar a requisição WebSocket handshake/upgrade dentro de uma parte logada de uma aplicação.

Como o WebSockets não são restringidos pela política same-origin, um atacante pode facilmente iniciar um request Websocket (ex: processo handshake/upgrade) de uma página maliciosa segmentando o ws:// ou wss:// na URL da aplicação atacada.

Devido ao fato que o request é um request HTTP(S) regular, os browsers enviam os cookies e os headers de autenticação HTTP juntos, mesmo de cross-site. Como no exemplo abaixo:

GET /trading/ws/teste HTTP/1.1

Host: www.aplicacao.com.br

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Firefox/23.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip, deflate

DNT: 1

Sec-WebSocket-Version: 13

Origin: https://www.aplicacao-maliciosa-do-atacante.com.br

Sec-WebSocket-Key: hP+ghc+KuZT2wQgRRikjBw==

Cookie: JSESSIONID=1A9431CF043F851E0356F5837845B2EC

Connection: keep-alive, Upgrade

Pragma: no-cache

Cache-Control: no-cache

Upgrade: websocket

O browser envia a informação de autenticação junto com o request de handshake/upgrade do Websocket. Sendo semelhante a um cenário de ataque Cross-Site Request Forgery (CSRF).

Entretanto, no cenário do Websocket este ataque pode ser estendido de um ataque write-only para uma comunicação read/write com um serviço Websocket, por estabelecer fisicamente uma nova conexão Websocket com um serviço com os mesmos dados de autenticação da vitima. Por isso, chamado de Cross-Site WebSocket Hijacing (CSWSH).

Mitigando

Tornar aplicação mais segura contra ataques CSWSH pode ser feitas seguindo estas contramedidas:

Verificar o header de Origin da solicitação de WebSocket handshake no servidor, uma vez que o header foi designado para proteger o servidor contra ataques cross-site nós browser das vítimas.