TryHackMe - Fools Mate, Revenge
Challenge Summary: Hack Javascript to successfully get checkmate and receive the flag
Platform: TryHackMe Category: Web Difficulty: Medium OS/Target: Web
Objective
Successfully checkmate the enemy king to receive the flag.
Attack Flow
|
|
Setup
Environment
- Attacker: Kali
- Target: 10.145.178.182:3000
- VPN/Tunnel: VPN
- Tools: Burp Suite, Chrome
Notes
The Fools Mate series have been a couple of fun CTF’s so far. I was fine with this room up until doing prototype pollution which I haven’t done before. Here’s a good read about this type of attack Port Swigger Prototype Pollution
Reconnaissance
Launch the webpage and see what happens
We can immediately see two functions on the page, reset and save preferences. Also when checkmating blacks king with white’s rook, we get a denial message.
Burp Suite
Lets take a look at the functions in Burp Suite to see what’s going on. I proxied the web traffic through Burp Suite and sent these three things over to repeater: the reset function, save preferences function, and checkmating the king. Having all three in repeater helped me send different values to the API, reset, test again. Rinse and repeat.
Checkmate Request
This is what’s sent when I move the white rook to checkmate the king.
|
|
Checkmate Response
We find a helpful clue provided in the response to checkmating the king.
"reason":"reward gate closed: session.config.unlocked is not set"
|
|
Reset Request
|
|
Reset Response
|
|
Settings Request
It looks like we can modify settings in the API here. Successfully tested changing the value for theme.
|
|
Settings Response
|
|
Initial Findings
- In the checkmate response we’re provided a clue,
"reason":"reward gate closed: session.config.unlocked is not set"- Make an extra note of the part where it says “not set”
- We can send different values to /api/settings
Vulnerability Identification
Attacking /api/settings
We found that we’re able to send different values to /api/settings, so per the clue I start sending a whole bunch of custom values, such as {"unlocked":"true"}, {"locked":"false"}, and {"config":{"unlocked":"true"}} added onto the normal preferences payload.
Every attempt just echoed straight back in the response, unchanged and with no effect on the reward gate, for example:
|
|
|
|
|
|
None of the values I could think of or find in my research would stick. Eventually this led me to prototype pollution, which I hadn’t heard of before.
Exploitation
Vulnerability
- Issue: Prototype Pollution
- Affected service: Javascript
Exploit Steps
In Burp Suite Repeater, on the settings request, change the body to:
{"theme":"dark","pieceSet":"classic","animationMs":180,"constructor":{"prototype":{"unlocked":true}}}
|
|
After sending the settings payload, we replay the checkmate move and get the flag.
Flags
| # | Flag |
|---|---|
| 1 | THM{pr0t0_*****__*******} <–obfuscated |
Lessons Learned
- Where the initial clue said “not set” was the biggest tell. Knowing about prototype pollution, if I were to see that again it would be more easily noticeable.
- The API was more secure than the first version of this room, but exposing the settings to the user introduced a weakness. Then using a variable in the code that was never set is an additional weakness that could lead to even greater issues, since “polluting” that variable isn’t just limited to the user session. If another app uses it, that could cause huge unintended issues.