Exploiting OAuth authentication vulnerabilities Part II
Today I will show some techniques that can be used to exploit OAuth 2.0 and possibly allow an attacker to take over the victim's account completely.
ATTACK 1: Flawed CSRF Validation Leads To Account Takeover:
Whenever an OAuth process is started the client application should generate a token that is tied to the user’s session for authorization purposes. This token is mostly passed by a parameter named state. But if the authorization does not send the state parameter that here is where things get interesting. That means there aren’t any means to check if the authorization process started by one user is in fact being completed by himself.
The attacker could start the OAuth process on his end and trick the user to complete it on their end and thus performing this takeover of their account.
Like a basic CSRF Attack.
To demonstrate this attack we can use the lab environment provided by portswiggers.
Exploitation: Forced OAuth profile linking
This lab gives you the option to attach a social media profile to your account so that you can log in via OAuth instead of using the normal username and password. Due to the insecure implementation of the OAuth flow by the client application, an attacker can manipulate this functionality to obtain access to other users’ accounts.
To solve the lab, use a CSRF attack to attach your own social media profile to the admin user’s account on the blog website, then access the admin panel and delete Carlos.
The admin user will open anything you send from the exploit server and they always have an active session on the blog website.
You can log in to your own accounts using the following credentials:
- Blog website account:
wiener:peter - Social media profile:
peter.wiener:hotdog
Let's access the lab environment and log in with the credentials that are provided
Attach your social media profile and notice the traffic you will see a request name GET /oauth-linking?code={code} Now make a note of this request.
After the account is successfully linked again start the linking process but this time intercept all the traffic forward all the requests except the above one and copy the URL. You must make sure that you drop this request.
Now We need to craft a csrf attack and trick the admin to complete the OAuth dance.
Open the exploit server and craft a manual HTML page.
Payload
<html>
<body>
<img src="https://0a720008043105e7c1c1140000bb0078.web-security-academy.net/oauth-linking?code=hjNnTLwdBZ8OfwCrIvFSZUhBtC4raT6-2sJ1Cwhi8Lv"> ===> change the link...
</body>
</html>Now log out of the previous session.
Now store and deliver the exploit to the victim.
Open the access logs and you will see one different IP address accessing the form.
Now Log back in with the social profile.
Now just go to the admin panel and delete Carlos.
Our Lab Is Solved.❤
MITIGATION:
Now let's Talk about how this attack can be mitigated.
If the application uses a state parameter and passes a hash through it which is tied to the user's session and properly validated then we would not be able to get the admin to link their social profile to our account because the state parameter would not be validated and approved.
If you see an OAUTH client does not use a state parameter to validate the current user’s session that it is very likely that the application is vulnerable to this attack.
Hope You Enjoy Reading about OAuth.
If you want to learn more about OAuth exploitation and Penetration testing consider following me.
Till the next time! Happy Hacking ❤
