How OAuth Account Linking Flaws Enable One-Click Takeovers

TLDR: Researchers at Black Hat 2024 identified two critical vulnerabilities, COAT and CORF, that allow attackers to hijack user accounts on major integration platforms like Microsoft Power Automate. By manipulating the OAuth 2.0 authorization flow, an attacker can force a victim to link their account to a malicious service with a single click. This flaw leads to full unauthorized access to sensitive services, including Microsoft 365 and Azure Key Vault, as demonstrated by CVE-2023-36019.

Integration platforms are the glue of the modern enterprise, connecting disparate services like Slack, GitHub, and Microsoft 365 to automate workflows. While these platforms promise efficiency, they also create a massive, centralized attack surface. The core issue lies in how these platforms implement OAuth 2.0, specifically the account linking process. When a user connects a third-party app to an integration platform, the platform must ensure that the user is who they say they are and that the account being linked actually belongs to them. As the research presented at Black Hat 2024 proves, many platforms fail to enforce these boundaries, turning a convenience feature into a critical security vulnerability.

The Mechanics of COAT and CORF

The research highlights two primary attack vectors: Cross-app OAuth Account Takeover (COAT) and Cross-app OAuth Request Forgery (CORF). Both techniques exploit the fact that integration platforms often rely on the state parameter or the redirect_uri to track the context of an OAuth flow, but fail to cryptographically bind these parameters to the specific user session or the intended application.

In a COAT attack, the attacker registers a malicious application on the platform's marketplace. When a victim is tricked into clicking a link to "link" their account, the platform embeds the malicious app's identifier into the state parameter. Because the platform does not verify that the state parameter matches the user's actual intent, it proceeds with the authorization flow. The attacker then intercepts the authorization code and binds the victim's account to the attacker's own account on the platform.

The CORF attack is even more insidious. It targets the redirect_uri parameter. An attacker can manipulate this parameter to redirect the authorization flow from a malicious app to a legitimate, benign app. Because the platform trusts the redirect_uri without sufficient validation, it inadvertently completes the account linking process for the victim, effectively granting the attacker's malicious app access to the victim's data.

Technical Implementation and Exploitation

During the live demonstration, the researchers showed how these flaws manifest in Microsoft Power Automate. The attack flow is remarkably simple:

1. The attacker crafts a malicious link that initiates an OAuth flow.
2. The victim, believing they are performing a legitimate action, clicks the link.
3. The platform, failing to validate the state or redirect_uri, processes the request.
4. The attacker receives the authorization code and exchanges it for an access token.

The following pseudo-code illustrates the logic of the vulnerability:

GET /authorize?client_id=ATTACKER_ID&redirect_uri=https://platform.com/callback&state=MALICIOUS_STATE

In this scenario, the platform's backend fails to check if the client_id and the state parameter are consistent with the user's current session. By the time the platform performs a "User Session Integrity Check," the authorization code has already been issued and leaked to the attacker. This is exactly what occurred in CVE-2023-36019, where the lack of proper validation allowed for unauthorized access to sensitive data.

Real-World Impact for Pentesters

For a penetration tester or bug bounty hunter, these findings are a goldmine. When auditing an application that supports third-party integrations, your focus should be on the OAuth callback flow. Specifically, look for:

• Lack of State Binding: Does the state parameter change if you initiate the flow from different sessions? If not, the application is likely vulnerable to CSRF-based account linking.
• Redirect URI Manipulation: Can you change the redirect_uri to an attacker-controlled domain? If the platform allows arbitrary redirect URIs, you have a clear path to CORF.
• Inconsistent App Identifiers: Does the platform verify that the client_id in the initial request matches the client_id during the token exchange?

The impact of a successful exploit is severe. In the case of Microsoft Power Automate, the researchers demonstrated that an attacker could exfiltrate emails from Outlook or steal secrets from Azure Key Vault. Because these services are often implicitly trusted by the platform, the attacker bypasses the need for further user consent.

Defensive Strategies

Defending against these attacks requires a shift in how platforms handle OAuth. The primary defense is to enforce strict consistency checks. Platforms must ensure that the client_id and the redirect_uri are cryptographically bound to the user's session from the start of the OAuth flow until the final token exchange.

Furthermore, platforms should implement "Tenant Isolation." This ensures that an authorization code issued for one tenant cannot be used to access resources in another. By requiring that the client_id and the redirect_uri match the platform's internal registry, developers can prevent the redirection of authorization codes to unauthorized applications.

These findings serve as a stark reminder that even well-established protocols like OAuth 2.0 can be implemented insecurely. As we continue to build more interconnected systems, the responsibility lies with platform developers to treat account linking as a high-risk operation. For the security community, the lesson is clear: always audit the "glue" that holds your infrastructure together. The next time you see an "Integrate with..." button, don't just click it—inspect the request and see what's happening under the hood.