Web Security Academy: Access Control — Multi-step process with no access control on one step
Greetings and welcome to another Access Control vulnerability lab provided by Web Security Academy!
This lab focuses on exploiting a vulnerable multi-step flow for changing a user’s role. While we are given credentials for both the regular and the admin users (administrator:admin and wiener:peter), we’re tasked with exploiting that very flow in order to promote our regular user to the administrator role.
As always, the first thing we gotta do is we need to access the lab:
Now, what we could do is to go straight to My account and login as the administrator:
Now that we’re logged in as administrator, we should make our way to the Admin panel:
We can see that this page has some interface allowing us to upgrade or downgrade a user. We might find those interesting, especially the Upgrade user action, since it’s likely that we’re going to need it to complete our task. To better see what’s going on behind the scenes, let’s start Burp and set it to intercept requests, then simply click on that Upgrade user button for carlos. Burp should be able to intercept that:
It seems it’s a POST request sent to the /admin-roles endpoint. We should definitely send that to Repeater, so right-click on it and select Send to Repeater.
Now forward that and let’s see what happens:
We’re now being presented with the /admin-roles endpoint, asking us for a confirmation of our intended action. Let’s keep Burp on intercepting requests and see what happens when we do Yes:
We should definitely send that to Repeater too.
For now, though, drop that request, we’re not interested in promoting carlos, we just wanted to see what request is launched when starting such an action. We should also logout from the administrator account, we have no use for that account any longer.
If we take a closer look at the two requests we just saved, we can spot a few things.
They both share the same session cookie — the administrator session cookie;
There’s a small payload difference between the two requests. The first one only has username and action:
But the second request holds another parameter:
This confirmed parameter seems to really “seal the deal”, presumably telling the server that we’re sure that we want the upgrade to go through.
Time to see what will happen if we use the same approach, but for wiener. And since both requests hit the same /admin-roles endpoint, maybe we could go ahead and only use the second, already confirmed request?
Let’s login as that user:
Now, let’s adapt our saved request (the one with the confirmation parameter being set) by setting the username parameter to wiener and, of course, we also need to update the session cookie to that of our wiener user. In other words, the server needs to know that wiener wants to promote itself.
We can grab the session cookie for wiener by setting Burp up for intercepting requests and refreshing the My Account page after logging in as wiener:
Now that we have the session cookie for wiener, our final request should look very similar to the following:
Now, if we click on Send, we should see a proper response:
And, as expected, the lab is now solved:
Refreshing the page only confirms what we already know: wiener is now an administrator (it now has access to the Admin panel):
Hope it was fun and, most importantly, educational. I know it was for me!
Thank you and I’ll see you at the next! Cheers, stay safe and, as always, happy hacking!
Deck is a software engineer, mentor, writer, cybersecurity enthusiast and sometimes even a teacher. One of his hobbies is doing CTF challenges; there’s always something to learn from them and he very much enjoys sharing the knowledge to people who look forward to sharpening their cybersecurity skills. You can reach Deck on Linkedin, Facebook, Twitter, and Discord: Deck451#6188, as well as follow his writing here on Medium.
