LeakyJar (June Bonus Challenge)
A CTF challenge involving leaking the admin's recipe box via CSRF.
Solution
The challenge presents a platform with public cookie recipes, along with the option of signing up and creating our own recipes, sharing them with specific users and, most importantly (for us), reporting malicious recipes.
In the Bakers section, we can also confirm that there is a "Master Baker" with username admin. This information will be of use to us later.
On registering, it can be seen that a session cookie is created with HttpOnly flag set. This rules out cookie exfiltration attacks via XSS. But, the SameSite attribute is None and no anti-CSRF tokens are in use anywhere. This implies that there is potential for CSRF here.
Out of habit, I began by performing HTML injection in all input fields starting from registration to adding my own recipe. We could also add reviews to the existing public recipes but seeing the amount of payloads others had tried here, I knew this would definitely not work 😆
None of the above injections worked. Time to turn our attention to the Report a recipe feature.
The URL entered here will be looked at by the Master Baker. From the previous investigation of the Bakers section, we know that this is the admin.
To begin my investigation, I entered a webhook URL and saw that the admin bot visited it immediately. The only check being performed seemed to be that it must be an HTTPS URL.
We now know we can deliver URLs to the admin. Because the site lacks same-site protection, any cross-site request performed via those URLs will automatically include the admin's session cookie. With the above knowledge, the most effective strategy is to perform a CSRF attack. This cheat-sheet shared by Intigriti in a blog recently is very useful in visualising why this target is vulnerable to CSRF and exactly how we're going to exploit it.
Next, we need to figure out what action we must perform through this CSRF in order to get the flag.
There is a feature to share our entire recipe box with another user. Below this section, we can also view recipe boxes of users who have shared it with us. Isn't this helpful?
If the admin shares their recipe box with us, we will be able to view all their recipes, and this is likely where we'll find the flag. This is how this particular request looks:
Observe how the request body is sent URL-form-encoded, which is a "simple request", and thus, it doesn't trigger a pre-flight request. This checks off all the 4 conditions mentioned in the cheat-sheet above. We can now proceed to build the exploit.
One of the conditions required for a valid solution is that the exploit should be single-click. We can do this with the help of auto-submitted forms. The following HTML page can get the job done:
This is a typical exploit used to silently perform a POST request to the vulnerable API, keeping the input hidden and providing default values that we want submitted on behalf of the victim.
I used Loophole to expose this page publicly:
Next, we can go report the path to the HTML file:
Once the report is successful, we can confirm the attack succeeded by returning to our recipe box, where we should see that we now have access to the admin's recipe box!
On viewing it, we will find the flag:
This concludes the challenge!
Impact
Account Integrity Compromise: An attacker can perform state-changing actions on behalf of any user, leading to unauthorised modifications of account settings.
Unauthorised Data Access: Attackers can gain full access to private data and sensitive information stored in other accounts.
Remediation
Update SameSite Cookie Attribute: Change the session cookie’s SameSite attribute to Lax or Strict. This prevents the browser from sending the cookie during cross-site POST requests.
Implement Anti-CSRF Tokens: Introduce unique, cryptographically strong, and unpredictable tokens for every request. The server should validate this token before processing the request.
Last updated