tl;dr
- Capturing the flag id through redos attack in /search endpoint
- XSS in /uuid/noteid/raw and HTML injection in /uuid/noteid
- CSP frame-src bypass through server side redirect
Challenge Points: 1000
No. of solves: 1
Challenge Author: Luc1f3r,Lu513n
Challenge Description
So many notes challenges these days… Hope this one brings some variety into the mix.
Analysis
The important endpoints are:
- /create - This will create a note with content as given and save it in a text file with title-noteid as the name of the file.
- /search - This will search for the note with the title from the directory. But this will only work for admin.
- uuid/noteid/ - This will show the dom purified note.
- uuid/noteid/raw - This will show the raw note.
- uuid/noteid/share - This will create a shared note and redirect to /shared/sharednoteid which can be visible by anyone.
The initial finds from the source code:
- /raw has XSS vulnerability.
- uuid/noteid/ has html injection which also allows iframe(iframe is among the extra allowed tags).
- default-src will only allow requests to url/session-id.
Exploitation
The challenge can be exploited in 2 parts.
1 - XSS in Admin bot
In this challenge the admin bot functions a bit differently. In the report endpoint you can give title and content of a note which will be created by the bot. After that the bot will visit this note.
Here the content of the note is sanitized using Dom purify. But iframe is given as one of the allowed tags. So using iframe we can possibly get XSS. If we load a note which has XSS payload in the iframe as the admin’s note
<iframe src="./../uuid/noteid/raw"></iframe>
Then we can get XSS. But this won’t work as the CSP is set as
1 | app.use((req, res, next) => { |
So uuid other than the admin itself is not allowed and you can’t get the /raw of an admin note.
There is an exception in CSP.
The matching algorithm ignores the path component of a source expression if the resource being loaded is the result of a redirect
^ w3.org
That is if an allowed path has a server side redirect to an unallowed path the CSP will not be violated as long as the domain is allowed by the CSP.
Here is where the /share endpoint comes into play. uuid/noteid/share will look for a note with the given noteid and add it to the shared object and redirect to shared/sharednoteid where anyone can see the shared note.
In this endpoint the sharednoteid will be the noteid we give and the endpoint redirects whether the note exists or not.
If we give the path as uuid/..%2fanotheruuid%2fnoteid%2fraw/share
then it will be like shared/../anotheruuid/noteid/raw
and will load anotheruuid/noteid/raw
.
So now we can get XSS in admin side. But how do we get the flag which is in a different note.
2 - Flag noteid through ReDos
/search endpoint searched for notes from admin’s directory but it only allows admin to search. Or does it?
1 | try { |
Here whether admin or not the searching will happen because it is in finally block. It will return whatever is given in try and catch but the connection will only close after the finally block is executed. So we can get the flag noteid using time difference by doing ReDos.
Final Exploit
Now we have the flag noteid and XSS in admin bot. So the flag can be acquired by reporting the note content as:
1 | <iframe src="./flagid"></iframe> |
The full exploit is:
1 | import requests |