My Music
Writeup for My Music (Web) - Intigriti 1337UP Live CTF (2023) ๐
Video Walkthrough
Description
Checkout my new platform for sharing the tunes of your life! ๐ถ
Enumeration
Register an account, notice we are given a login hash to save, e.g. 25d6a4cec174932f1effd56e2273be5198c3be06ddf03ab380a7ffc4cf3ef4e8.
We can generate profile card which creates a PDF but [by default] the request/response doesn't show in burp, let's make some adjustments:
Set burp scope to
https://mymusic.ctf.intigriti.ioand tick theonly show in-scope itemsoption in HTTP history tab (reduces noise, especially from spotify requests).Tick
imagesandother binaryin the thefilter by MIME typesection of the HTTP history options (ensuring our PDF generation is shown).
We can update three sections of our profile; First name, Last name and Spotify track code. For each element we add some HTML tags, e.g. <b>crypto</b> and try to generate a new profile card. All three elements are reflected in the PDF document, but only the Spotify track code is in bold.
Now we have found HTML injection, we can try and server-side XSS to identify the file structure.
<script>document.body.append(location.href)</script>Returns file:///app/tmp/3c433348-60e3-4a48-b989-2a168954147f.html
Since we confirmed the file location as /app, we can enumerate common files, either manually or by brute-forcing a wordlist.
app/app.js
We'll quickly recover the source code for app.js.
This introduces some new paths to investigate (/routes/index and /routes/api) so we repeat the previous technique.
app/routes/index.js
index.js confirms our target is the /admin endpoint. Currently, when we try to access the page we get Only admins can view this page.
It also revealed some new paths (/middleware/auth, /middleware/check_admin, /utils/recommendedSongs and /utils/generateProfileCard), which we'll return to shortly.
app/routes/api.js
api.js deals with the register/login/update functionality, nothing particularly interesting.
However, it does give us a new file to check out (/controllers/user).
app/controllers/user.js
This file is responsible for adding, updating and verifying users.
We find a /services/user endpoint, which might be interesting since the getUser(loginHash) function is imported from there.
app/controllers/user.js
Now we learn more about how users are stored!
First of all we see the ./data folder, useful knowledge as we already have a method of reading (maybe writing) files.
Secondly, we discover how user files are formatted.
Since our login hash is displayed on the page, we know exactly where our user object is located.
app/middleware/check_admin.js
Returning back to the four new endpoints we found in app/routes/index.js. The most interesting is likely to be check_admin.js. Why is this most interesting to us? Because we want to be admin, of course!
OK, so the userData JSON object will be parsed, and if the isAdmin property isn't true, we won't be granted access.
At this point we might think about how we could inject isAdmin: true into our user object ๐ค
Another question we may consider; what happens if the JSON object cannot be parsed? ๐
Let's revisit the code from /app/routes/index.js. Specifically, the generate-profile-card POST request.
We already knew that our userData would be inserted to the PDF (that's how we were able to inject code), but what's this userOptions parameter? Let's go find out!
app/utils/generateProfileCard.js
We found this endpoint earlier when checking /app/routes/index.js.
This part is notable; our userOptions are passed as options to the pdf function in puppeteer.
Time to RTFM ๐คทโโ๏ธ
path
optional
string
The path to save the file to
undefined, which means the PDF will not be written to disk
Exploitation
OK, enough with the recon. exploit time!
When we try to access the
/adminendpoint, it will parse ouruserDataJSON object and return a 403 error if it does not containisAdmin: true.However, if the JSON object cannot be parsed (as hinted earlier), then the code following the if statement (that returns a 403 response) will not be reached.
Does this mean we won't be rejected from viewing the admin page? Let's find out!
Attack Plan
We know we can control the
userOptionswhich is passed to the puppeteerpdffunction.We identified the
pathproperty that allows us to control the location where the generated PDF will be stored.We found that user objects are stored in
/app/data/<login_hash>.json
Putting all this together, we create a payload that will overwrite our user object with a generated PDF.
We send this payload in the POST request used to generate a PDF (make sure to set content-type to application/json). When we login with the hash and return to /admin, we get the flag.
Flag:INTIGRITI{0verr1d1ng_4nd_n0_r3turn_w4s_n3ed3d_for_th15_fl4g_to_b3_e4rn3d}
Note: I used this technique to overwrite our existing user object with a PDF (invalid JSON), but you could pick a filename of your choice, e.g.
Then just login with the hash cat and visit the admin page to receive the flag ๐
Last updated
