November 2, 2024
Account Takeover Via Google Auth Misconfiguration
Hello fellow researchers, my name is Abdul Rehman Parkar, and I work at IZYITS.
By Abdul Rehman Parkar
5 min read
In today's write-up, we will explore the Account Takeover vulnerability, which occurs due to OAuth misconfiguration. I discovered this vulnerability on the domain of a cloud-based company's website as well as on a popular e-commerce website. So, let's get started!
First, let's understand what OAuth is.
OAuth (Open Authorization) is an open standard protocol that allows secure access to resources without sharing the user's credentials. It enables third-party applications to access specific data or perform certain actions on behalf of the user without needing their password. OAuth is commonly used for authorization rather than authentication.
Here's a quick overview of how OAuth works:
1. User Consent: When a user wants to give an app access to their information (e.g., on social media), they are redirected to the platform (e.g., Google, Facebook) to grant permission.
2. Access Token: After granting permission, the authorization server provides an access token to the app. This token allows the app to request only the permitted resources without needing the user's credentials.
3. Restricted Access: The app uses this token to access specific data or functions authorized by the user, such as viewing contacts, posting on their behalf, etc.
4. Token Expiry and Revocation: Access tokens are typically short-lived for security. The user or the authorization server can revoke the token at any time to restrict access.
Since the domain and bug bounty program are private, I'll refer to it as "domain.com." Let's go over the process.
I received an invitation to participate in a private bug bounty program, which I accepted.
After joining, I navigated to the login page of the application and noticed that they had an option to log in using OAuth (e.g. via Google).
Out of curiosity, I hovered my mouse over the "Login with Google" OAuth icon and observed the following URL:
Breakdown of the URL Parameters
- Callback URL: The
callbackUrlparameter here is meant to specify the URL where the user should be redirected once they successfully authenticate with Google. It's set to redirect to[https://dash.domain.com/auth/login?returnFromSSO=true](https://dash.domain.com/auth/login?returnFromSSO=true.). - Error URL: The
errorUrlparameter is likely intended to handle cases where authentication fails, redirecting users to the specified URL (https://dash.domain.com/auth/login?returnFromSSO=truein this case).
First Attempts: Hitting a Wall
My first thought was simple: replace the callbackUrl parameter with my own webhook URL and see if the application would send the access token there after the OAuth process. But when I tried this, the application returned an error, refusing to complete the OAuth flow. It seemed to have some restrictions in place.
Not deterred, I turned to the errorUrl parameter, wondering if it might offer an alternate way in. I modified the errorUrl to my webhook URL, hoping that if an error occurred, the application would still redirect to my domain. But again, this attempt was unsuccessful; the application blocked any unauthorized domain in errorUrl.
A New Approach: Step-by-Step Testing
With direct manipulation proving unfruitful, I decided to try a more methodical approach. What if I tested each parameter individually to see exactly how the application responded? I started by removing errorUrl altogether, leaving only the callbackUrl in the URL, and set callbackUrl to my webhook URL
I sent the modified request. This time, the application didn't throw an error; instead, it proceeded to the Google login page as though nothing was amiss.
The Breakthrough: Capturing the Access Token
Excited, I logged in with a test Google account to complete the OAuth flow. After selecting my account, the OAuth process finished, and the application redirected me — not to its legitimate domain, but to my webhook URL, now loaded with the access token in the URL parameters.
It had worked! The application had redirected the access token to my injected URL, successfully exposing the token to me. With this token, I could now access the account with all the permissions the user had granted.
This vulnerability is known as an "OAuth Misconfiguration ( Open Redirect on Callback URL ) Vulnerability", and it occurs when an application doesn't properly validate or restrict the callback URL (redirect URL) during the OAuth authorization process. Let's break down how this can lead to an account takeover:
1. OAuth Flow with Redirect URLs: In the OAuth authorization flow, a web application often asks the user to authorize a third-party app by redirecting them to an OAuth provider (like Google, Facebook, etc.). Once the user grants access, the OAuth provider generates an access token and sends it back to the app through the "callback URL" (also known as the redirect URL).
2. Vulnerability with Unrestricted Callback URLs: Ideally, the web application should strictly validate the callback URL to ensure it points only to trusted domains (such as its own domain). However, if the callback URL parameter is vulnerable and allows an attacker to specify any domain, this creates a security gap. In this case, the attacker can inject their own URL as the callback.
3. Exploiting the Vulnerability: Here's how the attacker can exploit this:
The attacker crafts a malicious URL that includes their own domain in the callback (redirect) parameter. When the victim clicks this URL and completes the OAuth authorization, the OAuth provider generates the access token and, due to the vulnerable redirect, sends this token to the attacker's domain instead of the legitimate application's callback URL. The attacker now captures the victim's access token.
4. Impact: With the victim's access token, the attacker can perform actions and access data within the victim's account as though they are the legitimate user. This can lead to account takeover, unauthorized access to personal information, and other critical security breaches.
5. Prevention: To prevent this vulnerability, developers should implement strict validation on the callback URL:
Only allow pre-defined, whitelisted URLs as callbacks. Reject or sanitize any unauthorized URLs. Use techniques like parameterized redirects to prevent attackers from injecting their own domains.
By enforcing these controls, web applications can significantly reduce the risk of open redirect vulnerabilities in OAuth and prevent unauthorized access to users' accounts.
— — — — — — — — — — — — — — — — — END — — — — — — — — — — — — — — — — — —
Thanks for reading, and I hope you found my write-up informative.
Happy hunting, and remember to test responsibly!
Abdul Rehman Parkar :
LinkedIn: https://www.linkedin.com/in/abdulrehmanparkar/
Instagram: https://www.instagram.com/abdulprkr/
X ( Twitter ): https://twitter.com/abdulrehmanprkr