Multi-Step Process with No Access Control on One Step
Cybersec Café #29 - 8/20/24
Welcome back to the Methodology Walkthrough at the Cybersec Cafe. Today, we’ll be exploring an Access Control vulnerability to exploit a design flaw in an application.
Objective
Log in using default credentials and exploit the flawed access controls to promote yourself to administrator.
What is an Access Control Vulnerability?
An access control vulnerability occurs when an application fails to properly enforce who can access or perform actions on certain resources, allows malicious users to gain unauthorized access to sensitive data or perform restricted actions, potentially compromising the security and integrity of the system.
Methodology
The Recon
We have a shopping application in front of us, which we’ve seen many times during this series.
But, the lab informs us that we have access to the administrator console and can explore it via the admin credentials.
We can navigate to the account page and login to see that the admin has access to an email change feature.
The real point of interest will be the Admin panel though. Let’s navigate over.
We can see we have the option here to upgrade or downgrade a user’s permissions.
Let’s play around with the feature to see what we can do.
Testing
Let’s take the carlos user and test the upgrading and downgrading process.
After upgrading, we get a confirmation request from the application to ensure we’re taking an intended step. After confirming, we can see it works and the user now has administrative privileges.
The same process occurs when we downgrade the user back down to a standard user.
Let’s inspect the request:
We don’t see anything particularly out of the ordinary in the first request. But, there is a session cookie, which gives me an idea.
Send the request over to the Burp Repeater.
Exploitation
Let’s copy the URL for the lab to either a separate browser or an incognito window.
Login with the default credentials.
Now, right click and inspect the page, Head to the Application tag and find our session cookie.
Copy and Paste the session cookie into the request in Repeater and click send.
It looks like we’re unauthorized to perform the step unfortunately…
But wait!
Remember the confirmation step in the workflow? What if we take that request and try the exact same thing.
That has a higher liklihood of being overlooked by a developer than the actual function itself.
We can see we get a 302, and the lab is solved!
What We’ve Learned
The application implements access controls on the initial request, but not the confirmation request, meaning we were able to exploit the logic by replaying the confirmation with our own username and granting ourselves administrative privileges.
We saw that it’s important to look at a workflow from all angles. Generally, the function that is performing the action will get a majority of attention from developers and testers. Use your recon skills to gain a holistic view of the application and to find holes that might have been missed.
Want to give the lab a try yourself? You can check it out on PortSwigger’s website here.
Securely Yours,
The Cybersec Cafe
Just a heads up, The Cybersec Cafe's got a pretty cool weekly cadence.
Every week, expect to dive into the hacker’s mindset in our Methodology Walkthroughs or explore Deep Dive articles on various cybersecurity topics.
. . .
Oh, and if you want even more content and updates, hop over to Ryan G. Cox on Twitter/X or my Website. Can't wait to keep sharing and learning together!