OAuth: A Backdoor in Disguise — a $7500 Study Case

In a recent security assessment, I uncovered two critical vulnerabilities in an application’s authentication system, both related to weak OAuth implementation. The application, used for planning and social media management, had serious flaws in its use of Oauth ID for authentication, leading to a payout of $7,500. Here’s the breakdown of the vulnerabilities I discovered and how they could potentially lead to full account takeover.

OAuth is an open standard for access delegation, commonly used for token-based authentication and authorization. It allows third-party services to exchange information without sharing credentials directly, making it convenient for users. However, if improperly implemented, OAuth can become an attractive attack vector. Attackers can exploit vulnerabilities in the implementation to gain unauthorized access, manipulate tokens, or impersonate other users.

Source : wallarm

OAuth’s complexity, combined with frequent misconfigurations, makes it a popular target for attackers, especially when there is a lack of proper token validation and integrity checks.

A secure OAuth implementation requires:
1. Proper Token Validation: Every token, such as JWT, must be validated to ensure its integrity. This includes verifying the signature and ensuring that claims like `sub` (subject) match expected values.
2. One-Time Usage Codes: Authentication codes should be used only once to prevent replay attacks. Tokens should also be tied to a specific session and device to avoid reuse.
3. Secure Claims Handling: Sensitive claims such as user identifiers should be validated thoroughly against expected values, and the system should implement mechanisms to ensure tokens are issued and used correctly.
4. Minimal Data Exposure: Only necessary information should be exposed in API endpoints to avoid providing attackers with excess data that could aid in attacks.

The first vulnerability I identified was a broken authentication mechanism involving OAuth. Specifically, the application’s OAuth implementation allowed for reuse of authentication tokens and manipulation of the user identifier contained in the JWT (JSON Web Token).

How It Happened

The process began when I logged into the target application via Oauth ID. Using a proxy tool like Burp Suite, I monitored the traffic and found the POST request to `/api/v4/authorize`. Inside the request body, there were parameters like .

POST /api/v4/authorize HTTP/2
Host: vuln.com

{ "password": "…", "is_nude": "…", "code": "…", "id_token": "…" }

Upon further analysis, I realized that:
- The code and password fields were reusable.
- The id_token (a JWT token) contained a payload with a `sub` key, which is Oauth ID and used as user identifier.

JWT consists of three parts:

Header: Contains information about the type of token and the algorithm used.Payload: Contains the claims (information about the user or token).Signature: Verifies the sender and ensures the integrity of the token.

Interestingly, developers sometimes do not need all the information contained in the payload and often just fetch the relevant information from it without verifying the signature. This lack of validation allows attackers to tamper with the payload. That is how this vulnerability arise.

The most concerning issue was that the `sub` value in the JWT token could be altered to a different ID value, allowing me to re-encode the token and log in as any user of my choice.

Since the user ID (`sub` claim in the JWT) is a hard-to-guess identifier, the lack of proper validation made it possible to manipulate the token to gain unauthorized access. Thus we need other vulnerability that can leak the identifier that take us to vulnerability number two : User Enumeration

User Enumeration alone is P5 (Informational) Severity, depends on the information it hold. But it will be powerful gadget to chain to leveraging a vulnerability.

The second critical vulnerability I discovered was a user enumeration issue in the `/api/v4/users` endpoint. By sending a specially crafted request to this endpoint, I was able to gather information about other users, including their ID, IP address, device information and even an AI platform token.

Exploitation Steps

1. Logged in to the application to obtain a valid bearer token
2. Sent a POST request to the `/api/v4/users` endpoint with a body containing the target user’s email.
3. Observed the server’s response, which contained the following sensitive details:
— Oauth ID of the user (stored in the `id` field).
— IP address and device information of the last login.
— User configuration details and a special AI platform token for generating content.

Using that Oauth ID we can chain with first vulnerability to take over any account that who have logged in using Oauth.

This highlights the importance of validating all components of a token and not assuming identifiers are secure simply because they are difficult to guess. By exploiting these vulnerabilities, an attacker could impersonate any user, effectively bypassing the entire authentication process.

The vulnerabilities discovered show how fragile OAuth implementations can be without the proper integrity checks and validation mechanisms. By reusing tokens and exposing sensitive endpoints, this application had inadvertently created a serious security hole that could have led to widespread account compromises.

For developers and organizations, it’s crucial to:
- Ensure that JWT tokens are validated on every request, especially verifying claims like ID against expected values.
- Implement proper checks to avoid token reuse and guarantee one-time usage of authentication codes.
- Restrict the amount of sensitive information exposed through public API endpoints to reduce attack vectors.

Timeline

First Vulnerability Discovered : 19 Aug 2024Full Vulnerability Chain Discovered : 21 Aug 2024Reported to the program : 21 Aug 2024Triaged : 22 Aug 2024Bounty Paid : 27 Aug 2024Resolved : 4 September 2024

This case study illustrates how small oversights in OAuth implementation can have critical consequences. It emphasizes the importance of robust security practices in authentication systems to protect user accounts and sensitive information.