Obsidian Security’s security research team has uncovered a significant OAuth 2.0 implementation flaw in several unified API integration platforms, such as Merge.dev. This flaw allows threat actors to impersonate these platforms’ verified OAuth applications, enabling them to conduct OAuth consent phishing attacks on various SaaS applications. This discovery highlights a critical vulnerability in the API integration ecosystem, with potentially widespread consequences for SaaS security.
Why it matters:
This vulnerability poses several risks:
- Unauthorized Data Access: Attackers can exploit OAuth tokens to access sensitive data across multiple SaaS applications without proper authorization.
- Increased Phishing Success: Using verified OAuth applications, attackers can gain the trust of end-users, increasing the success rate of phishing attempts.
- Multi-platform Vulnerability: The flaw is not limited to one platform, resembling a systemic issue.
What are API integration platforms and why are they valuable?
Unified API Integration Platforms (UAIPs) are tools designed to streamline the integration process of multiple SaaS applications. They act as centralized hubs that allow developers to connect various applications, such as HRIS, ATS, accounting systems, CRMs, and more, through a single interface. By offering pre-registered OAuth applications with assigned permissions, UAIPs simplify the often complex task of managing multiple APIs. API Integration Platforms are valuable for several reasons:
- Simplification of API Management: These platforms allow developers to manage API keys, service account credentials, and OAuth integrations from a single location. This reduces the time and effort needed to set up and maintain connections between different applications.
- Unified API Operations: By abstracting common API operations into a standardized format, UAIPs eliminate the need for developers to learn multiple APIs and protocols. This uniformity simplifies development and speeds up integration processes.
So, what’s the issue?
The risk of exploitation stems from inadequate CSRF (Cross-Site Request Forgery) protection in many UAIPs. To understand this issue, let’s explore a typical integration process and identify where vulnerabilities occur.
Typical integration process:
- Authorization Request: The UAIP creates an authorization link for the target application’s OAuth server, requesting access to the user’s data through its pre-registered OAuth application.
- User Action: The end user clicks the authorization link, authenticates, and grants access on the target application’s OAuth server.
- Authorization Code: The OAuth server issues an authorization code and redirects it back to the UAIP via the user’s browser.
- Token Exchange: The UAIP exchanges this authorization code for an access token and associates it with the user’s account.
- Data Access: The user uses the UAIP’s unified API to retrieve data from integrated applications, with the UAIP pulling data using the user’s access token.
The vulnerability:
The issue arises when User 1 sends the authorization link to User 2, who then completes the authorization. In this case, the integration still functions, but User 2’s access token may be improperly bound to User 1’s UAIP account. Consequently, User 1 can access User 2’s data via the UAIP’s unified API.
Technical breakdown:
The core problem is that the UAIP does not verify that the user initiating the authorization is the same as the one completing it. Vulnerable UAIPs misinterpret the “state” parameter in the authorization link.
OAuth 2.0 Specification: The “state” parameter should link to the user’s session data on the backend, tied to the session cookie, not just be a standalone value. According to the OAuth 2.0 specification:
“The client MUST implement CSRF protection for its redirection URI. This is typically done by including a value that binds the request to the user-agent’s authenticated state (e.g., a hash of the session cookie). The client SHOULD use the ‘state’ parameter to send this value to the authorization server. Once authorization is granted, the authorization server redirects the user-agent back to the client with the binding value in the ‘state’ parameter. This allows the client to verify the request’s validity by matching the ‘state’ parameter to the authenticated state. The binding value used for CSRF protection MUST be non-guessable and stored securely.”
In short, the lack of proper CSRF protection in UAIPs can lead to unauthorized data access, highlighting the importance of correctly implementing and verifying the “state” parameter to protect against such vulnerabilities.
Proof of concept
In the demo, we used Merge.dev as an example to conduct a Google Drive phishing attack. Typically, this is difficult to achieve because Google enforces strict verification for OAuth applications requesting sensitive permissions before they can be used by the general public. However, using Merge.dev’s verified OAuth application, we managed to bypass these restrictions:
The bigger picture:
Verified OAuth applications with high permissions are prime targets for OAuth phishing attacks. UAIPs offer pre-registered OAuth applications, many of which are already verified by OAuth authorization servers like Azure AD and Google. These verified applications gain users’ trust easily, significantly increasing the success rate of phishing attacks.
UAIPs also expose a unified API that allows malicious OAuth applications to perform a wide range of operations. Once integrated, these platforms can automatically help attackers maintain and refresh access tokens. Some UAIP OAuth applications may have already been consented to by developers, allowing for stealthy, one-click compromises without user interaction.
Since November 9, 2020, Azure AD has blocked end-user consent for newly registered and unverified multi-tenant OAuth applications. However, UAIPs that do not offer verified OAuth applications may still be exploited for phishing attacks using Azure applications registered before this regulation.
With their broad support for applications and trusted attributes, vulnerable UAIPs can be weaponized to create more effective Phishing-as-a-Service platforms compared to existing tools like the o365-attack-toolkit.
How do I prevent this type of attack?
To prevent this type of attack, when initiating the authorization request API, the state value should be stored in the current user’s session. Here is a common practice using pseudo-code:
When receiving the authorization response, verify the user by matching the state value in the request URI with the state value stored in the user session:
Final thoughts
We’ve found that, in addition to the demo platform, three other unified API integration platforms are also vulnerable to the same issue we’ve covered. This highlights how common and often overlooked integration CSRF vulnerabilities are. We hope this blog brings these risks to light and prompts the technical community to address these threats more proactively.
Appendix
Vulnerability report timeline:
- July 8, 2024: Reported the security issue to four vulnerable vendors.
- July 8, 2024: Merge.dev responded promptly, acknowledging the issue.
- August 13, 2024: Merge.dev confirmed that the bug was fixed.
- September 3, 2024: Due to a lack of response from the other three vendors, we disclosed the issue publicly.
.avif)
.avif)
