Universal Cross-app Attacks: Exploiting and Securing OAuth 2.0 in Integration Platforms

Universal Cross-app Attacks: Exploiting and Securing OAuth 2.0 in Integration Platforms

Speakers: Kaixuan Luo, PhD Candidate, Chinese University of Hong Kong (Joint work with Simb Wong, Professor Winshin Law from M University, and Adon's Phone and Julian Lcom from Samsung Research America)

Conference: USENIX Security

YouTube: https://www.youtube.com/watch?v=Mq2nYuqAbQk

Overview

This talk, presented by Kaixuan Luo, a PhD candidate at the Chinese University of Hong Kong, delves into a critical security vulnerability within the rapidly expanding ecosystem of integration platforms. These platforms, ranging from virtual voice assistants like Alexa and Google Assistant to smart home hubs and modern large language model (LLM) platforms with plugin support (e.g., ChatGPT plugins), are designed to connect and aggregate functionalities of diverse internet applications and IoT devices. The core mechanism enabling this interconnectedness is account linking, predominantly powered by the OAuth 2.0 protocol. Luo and his team uncover pervasive design flaws in how these platforms implement OAuth 2.0, leading to novel "cross-app" attack vectors.

The research highlights a significant paradigm shift in OAuth 2.0 usage within these integration platforms compared to its traditional application. Unlike the conventional model where a large provider (like Google) offers resources to numerous third-party applications, integration platforms themselves act as OAuth clients, integrating with a multitude of third-party applications that function as authorization servers. This inverted architecture, combined with the prevalent open marketplace model where untrusted or even malicious apps can be easily integrated, creates fertile ground for new and practical attacks. The presentation details two primary attack types: Cross-App Account Takeover (CAT) and Cross-App Request Forgery (CARF), demonstrating how these can lead to severe consequences such as financial fraud, privacy leakage, and unauthorized control over user accounts.

The significance of this work is underscored by its widespread impact. The researchers found that an alarming 16 out of 18 mainstream integration platforms with open marketplaces, including offerings from industry giants like Google, Microsoft, Amazon, and Samsung, are susceptible to these vulnerabilities. One particular vulnerability discovered in Microsoft Power Automate, a workflow automation platform, received a CVE with a CVSS score of 9.6, indicating critical severity and ease of exploitation. Beyond identifying the problems, the team proposes a robust, tailored defense mechanism based on an "app ID" concept and has published an IETF draft to advocate for these necessary changes in OAuth 2.0 security best practices, aiming to fortify the security posture of this crucial and growing digital infrastructure.

Background

▶ Watch: Introduction to integration platforms and account linking (0:00)

The proliferation of digital services has driven the need for seamless interaction between disparate applications. This demand is met by integration platforms, which act as central hubs to orchestrate workflows and consolidate functionalities. These platforms encompass a broad spectrum, from workflow automation tools like Microsoft Power Automate and IFTTT (If This Then That) to virtual assistants such as Alexa and Google Assistant, smart home ecosystems like Google Home, and even the latest generation of large language model platforms offering plugin support, exemplified by ChatGPT plugins. Academics often refer to these as "trigger-action platforms" or "low-code/no-code platforms," reflecting their design philosophy of simplifying complex integrations.

At the heart of these platforms lies account linking, a fundamental feature that allows an end-user to connect their account from an integrated app (e.g., Lyft, Spotify) to their platform account (e.g., Google Assistant, Alexa). This linkage empowers the platform to act on the user's behalf, calling APIs of the integrated app to perform actions like ordering a ride or playing music. The de facto standard protocol for establishing this account linking is OAuth 2.0.

OAuth 2.0 is a three-legged protocol, involving an OAuth client (operated by the integration platform backend), a user agent (the integration platform frontend), and an authorization server (operated by the integrated app). The process unfolds in two main phases:

1. Authorization Phase:

• The end-user initiates account linking via the platform's frontend.
• The platform backend starts the OAuth flow, redirecting the user to the integrated app's authorization server.
• The user logs into the app's website and, if necessary, grants consent for account linking. (Often, if prior consent exists, this step can be automated, issuing an authorization code without explicit user interaction).
• The authorization server issues a short-lived authorization code, which is then passed back to the platform backend via the user agent, specifically to a pre-registered redirect URI.

1. Code Exchange Phase:

• The platform backend redeems the authorization code at the app's token endpoint, exchanging it for an access token.
• This access token, representing access to the user's app account, is then associated with the user's platform account.
• From this point, the platform can use the access token to call the app's APIs and control it on behalf of the user.

A critical distinction, and the genesis of the vulnerabilities, lies in the paradigm shift of OAuth 2.0 usage. Traditionally, OAuth 2.0 was designed for a scenario where a few "big name" providers (like Google or Facebook) offered resources or identity services to many third-party applications. In this model, the big provider acts as the authorization server, and third-party apps are the OAuth clients. However, in the context of integration platforms, this is reversed. The integration platform itself acts as the OAuth client, and the third-party apps (which are numerous and diverse) play the role of authorization servers, sharing their resources with the platform.

This inverted architecture introduces a significant security challenge: integration platforms often feature an open marketplace. Any third party can register and publish an app in this marketplace. This means the ecosystem is inherently open to potentially untrusted or even malicious apps that can act as authorization servers. This ease of introducing malicious authorization servers fundamentally changes the threat model and creates opportunities for sophisticated cross-app attacks that were less feasible in the traditional OAuth paradigm.

Key Findings

▶ Watch: Detailed explanation of OAuth 2.0 protocol (2:00)

The research uncovers two primary categories of "cross-app" attacks that exploit the unique architecture and common implementation flaws within integration platforms:

1. Cross-App Account Takeover (CAT/CoA-T): This attack allows an attacker to steal a victim's app account and bind it to the attacker's platform account. For instance, an attacker could link the victim's Lyft account to their own Google Assistant, enabling them to request rides at the victim's expense. This constitutes a direct financial or service takeover.
2. Cross-App Request Forgery (CARF/CoA-RF): This attack involves an attacker unknowingly binding their own app account to the victim's platform account. This can lead to privacy leakage, as the attacker could then track the victim's activities (e.g., tracking ride requests made via Google Assistant if the attacker's Lyft account is linked to the victim's Google Assistant).

Both CAT and CARF attacks stem from a shared root cause: the integration platform's flawed reliance on insufficient mechanisms for active app tracking. To correctly complete the two-phase OAuth flow, the platform must consistently identify which integrated app is involved throughout the entire process. If this tracking mechanism can be manipulated, the platform can be tricked into misattributing an authorization code, leading to the aforementioned attacks.

The investigation, employing a novel decision tree-based testing approach and a semi-automated tool called Cove Scan, revealed a pervasive impact across the industry. Out of 18 integration platforms with open marketplaces that were examined, a staggering 16 were found to be vulnerable. This list includes major players such as Google, Microsoft, Amazon, and Samsung, highlighting the systemic nature of these vulnerabilities. Furthermore, the researchers found that 9 of these platforms supported attacks that could be completed in a single click, often by combining these cross-app flaws with other vulnerabilities like CSRF.

A concrete example of the severity is the Cross-App Account Takeover (CAT) vulnerability identified in Microsoft Power Automate. This flaw was assigned a CVE with a CVSS score of 9.6, indicating its critical nature and ease of exploitation, allowing an attacker to hijack user accounts with minimal interaction. These findings underscore that the theoretical concerns about malicious authorization servers in open ecosystems have materialized into practical, high-impact threats.

Technical Deep Dive

▶ Watch: Open marketplace and OAuth paradigm shift (4:00)

The core challenge for integration platforms is active app tracking. With hundreds or thousands of diverse integrated apps, each with its own authorization server, the platform must accurately remember which app initiated an OAuth flow and ensure that the subsequent code exchange phase interacts with the same app. This is crucial because the authorization code issued by a specific app's authorization server must be redeemed at that same app's token endpoint. Flaws in this tracking process are the bedrock of the discovered cross-app vulnerabilities.

The research identifies two common, yet flawed, patterns for active app tracking:

1. Tracking via the state parameter:

• Mechanism: When an OAuth flow begins, the platform embeds an app ID (e.g., as a JWT claim) within the state parameter. This state parameter is passed along during the authorization phase and is returned to the platform's redirection endpoint along with the authorization code. The platform then extracts the app ID from the state to determine the active app for the code exchange.
• Vulnerability (Cross-App Account Takeover - CAT): The critical flaw here is that the state parameter is opaque to the authorization server. While it reflects how the OAuth flow started, it doesn't guarantee how it ended. A malicious app can exploit this:
• Attack Flow:

1. The victim initiates account linking with a malicious app.
2. The platform embeds the malicious app's ID in the state parameter and redirects the victim to the malicious app's authorization server.
3. Instead of authorizing the user, the malicious app's server issues a crafted redirect to a benign app's authorization server. Crucially, this redirect preserves the original malicious app's state parameter.
4. From the benign app's perspective, this is a legitimate authorization request. It processes the request, issues an authorization code, and redirects the user back to the platform's redirection endpoint, including the original malicious app's state parameter and the newly issued authorization code from the benign app.
5. The platform, upon receiving the response, retrieves the app ID from the state parameter. Since the state parameter still contains the malicious app's ID, the platform mistakenly believes it has been interacting with the malicious app throughout the entire process.
6. Consequently, the platform leaks the authorization code (issued by the benign app) to the malicious app's token endpoint.
7. The attacker, now possessing a valid authorization code for the victim's benign app account, performs an authorization code injection attack. They redeem the code and bind the victim's benign app account to their own platform account, achieving a complete account takeover.

1. Tracking via the redirect_uri:

• Mechanism: Some platforms embed the app ID directly into the redirect_uri, often as a path segment (e.g., https://platform.com/oauth/callback/APP_ID). When the user agent hits this endpoint, the platform extracts the app ID from the URL path.
• Vulnerability (Cross-App Request Forgery - CARF): The redirect_uri itself has weak integrity. An attacker with a malicious app can easily alter this parameter.
• Attack Flow:

1. The victim starts account linking with a malicious app.
2. The attacker, leveraging the lack of integrity protection for the redirect_uri, manipulates the request to change the active app context from the malicious app to a benign app. This means the redirect_uri now contains the benign app's ID.
3. The platform, receiving this manipulated redirect_uri, is tricked into believing it should contact the benign app for the code exchange.
4. The attacker then injects a still-valid authorization code of their own (obtained previously from the benign app).
5. The platform, now expecting to link with the benign app, proceeds to link the attacker's app account (associated with the injected code) with the victim's platform account. This results in the attacker's app account being forcefully linked to the victim, enabling privacy leakage or other malicious actions. This attack resembles traditional Login CSRF.

Proposed Defense:

The root cause of both CAT and CARF is the platform's singular reliance on either state or redirect_uri for active app tracking. The robust solution proposed by the researchers is to **embed a unique app ID in both the state parameter and the redirect_uri. Crucially, the platform must then extract the app ID from both parameters and ensure their consistency** before proceeding with the code exchange. If a mismatch is detected, the OAuth flow should be aborted, preventing the attack. This "two-factor" app ID verification ensures that the app that started the OAuth flow is indeed the same app that concludes it.

Why PKCE is Insufficient:

Some might wonder if PKCE (Proof Key for Code Exchange), an OAuth 2.0 extension designed to mitigate authorization code interception attacks, could solve these problems. The answer is no. While PKCE is effective against certain types of code injection, a malicious app in this context can bypass PKCE's protection at the protocol level. It's not about exploiting implementation flaws or downgrade attacks; rather, the malicious app simply follows a specific sequence of steps that invalidate PKCE's protection in this cross-app scenario.

Relation to Mix-up Attacks:

The cross-app attacks presented can be considered practical variants of mix-up attacks, first theorized around 2016. Traditional mix-up attacks, primarily discussed in the context of single sign-on (SSO) with multiple Identity Providers (IDPs), rely on the existence of a malicious authorization server. This precondition is difficult to satisfy in traditional OAuth paradigms, as it would require a trusted entity (like Google) to be compromised or a website to suddenly trust an attacker-controlled IDP.

However, the integration platform scenario fundamentally changes this. Because integration platforms operate with an open marketplace design, untrusted or malicious apps can easily be integrated, effectively acting as malicious authorization servers. This architectural shift transforms mix-up attacks from theoretical concerns into practical, high-impact threats.

Why Existing Mix-up Defenses Are Impractical:

Existing mix-up defenses, detailed in RFCs, often rely on the concept of an authorization server issuer (or issuer). This is a unique identifier for each authorization server. However, in the open marketplace setting of integration platforms, issuers are no longer unique to the platform's context. For example, multiple different apps (e.g., an "official Dropbox app" and a "custom Dropbox integration" by a third-party developer) might both leverage the same official Dropbox APIs and thus share the same authorization server issuer. From the platform's perspective, these are two distinct entities requiring independent handling of OAuth flows, even though their issuer might be identical. This makes issuer-based defenses ineffective for disambiguating between different apps that happen to use the same underlying authorization server.

Tailored Defense: App ID-based Security Boundary:

To address these limitations, the researchers propose a tailored specification change for integration platforms, built upon the concept of an app ID. This app ID is a unique, app-specific identifier that should be embedded in the redirect_uri during both the app's pre-registration and throughout the OAuth flows. This app ID serves as a more suitable security boundary for multi-app integrations than the authorization server-specific issuer. This robust app ID-based consistent tracking mechanism, checking for consistency between state and redirect_uri as described earlier, is a "two-birds-with-one-stone" solution, mitigating both CAT and CARF attacks effectively. The team has published an IETF draft to propose these changes to the OAuth security best current practices, aiming to integrate these crucial defenses into the broader community standards.

Demo / Proof of Concept

▶ Watch: High-level overview of COAT and CORF attacks (5:30)

The researchers developed Cove Scan, a semi-automated dynamic testing tool, to efficiently identify vulnerabilities in integration platforms. The tool is designed to address the challenge of scalably and precisely determining a platform's susceptibility to cross-app vulnerabilities without requiring internal knowledge of the platform's implementation or the integration of actual malicious apps.

Cove Scan's Methodology:

1. OAuth Flow Capture: The tool observes and captures the OAuth flows for two different, benign integrated applications on the target platform.
2. Traffic Inspection: It inspects the traffic generated during these flows, particularly focusing on the parameters involved in active app tracking, such as the state parameter and the redirect_uri.
3. Parameter Swapping: At the crucial redirection endpoint, Cove Scan proactively introduces "app ID confusion" by swapping or manipulating OAuth parameters (e.g., state values or redirect_uri components) between the two observed flows. This mimics the conditions an attacker would create.
4. Outcome Inspection: The tool then monitors the subsequent code exchange phase. If an authorization code from one app can be successfully redeemed by the platform while it's "confused" about the active app context (i.e., believing it's interacting with the other app), then a vulnerability is confirmed.

Key Benefits of Cove Scan:

• Concrete Conclusions: It can derive definitive conclusions about a platform's security or insecurity.
• Reduced Reliance on Malicious Apps: It avoids the need to actually integrate a malicious app or launch full-blown attacks, making testing safer and more ethical.
• Accessibility: Even end-users could potentially use this approach to test the security of platforms they use daily, without needing deep technical expertise or platform internals.
• Efficiency: Cove Scan can typically derive a conclusive assessment for a platform by analyzing at most three OAuth flows.

The efficacy of Cove Scan was demonstrated through its successful identification of vulnerabilities across 16 out of 18 tested platforms. A particularly notable finding was the Cross-App Account Takeover (CAT) vulnerability discovered in Microsoft Power Automate, which was confirmed with a CVE (CVSS 9.6). This high-severity rating and the ability to complete the attack in "one click" highlight the tool's precision in uncovering critical, exploitable flaws. The tool effectively serves as a proof-of-concept for the attack vectors discussed and a practical aid for vulnerability discovery.

Defensive Implications

▶ Watch: Deeper dive into COAT/CORF and platform challenges (6:30)

The research by Kaixuan Luo and his team provides critical insights for various stakeholders involved in the integration platform ecosystem. Understanding these cross-app vulnerabilities is paramount for enhancing the security posture of these widely used services.

For Integration Platform Developers and Vendors (e.g., Google, Microsoft, Amazon, Samsung):

• Implement Consistent App ID Tracking: This is the most crucial takeaway. Platforms must cease relying solely on either the state parameter or the redirect_uri for active app tracking. Instead, a unique app-specific identifier (app ID) should be embedded in both parameters. Critically, the platform's backend must then extract the app ID from both the state and redirect_uri and perform a consistency check before processing any authorization codes. If there's a mismatch, the OAuth flow should be immediately aborted.
• Adopt the IETF Draft Proposal: Review and integrate the proposed changes detailed in the IETF draft, which advocates for app ID-based security boundaries. This involves rethinking how app context is maintained and validated throughout the OAuth 2.0 flow, especially in multi-app, open marketplace environments.
• Rethink OAuth Client Implementations: Conduct thorough security audits of existing OAuth 2.0 client implementations, specifically focusing on how active app context is tracked and validated. Pay close attention to redirection logic and authorization code redemption processes.
• Educate Third-Party Developers: Provide clear guidelines and SDKs to integrated app developers on how to properly implement their authorization servers to be compatible with these enhanced security measures, even though the primary burden of defense lies with the platform.
• Secure Open Marketplaces: Acknowledge that the open marketplace model inherently allows for malicious authorization servers. Design security controls (e.g., app vetting, reputation systems, stricter validation) to minimize the risk, but assume that malicious entities will attempt to exploit flaws.

For Integrated App Developers (those building apps for these platforms):

• Be Aware of Platform Vulnerabilities: While the primary defense is on the platform side, app developers should be cognizant that the platforms they integrate with might be vulnerable.
• Implement OAuth 2.0 Best Practices: Ensure their authorization servers adhere strictly to OAuth 2.0 security best practices, including robust redirect_uri validation, proper state parameter usage (though this research points out its limitations for app tracking), and secure token handling.
• Do Not Rely Solely on state for Security: App authorization servers should not make security decisions based on the state parameter, as it is opaque to them and can be manipulated by attackers via the platform context.

For Security Researchers and Auditors:

• Utilize Cove Scan: The Cove Scan tool provides a valuable resource for identifying these specific cross-app vulnerabilities. It allows for systematic, semi-automated testing without requiring deep platform internals or deploying malicious apps.
• Expand Research: Investigate other potential cross-app attack vectors or variations within different types of integration platforms (e.g., IoT specific platforms, blockchain integrations).

For End Users:

• Exercise Caution: Be mindful when linking accounts on integration platforms, especially with lesser-known or new apps.
• Monitor Account Activity: Regularly check activity logs for both your platform accounts and your integrated app accounts for any suspicious or unauthorized actions (e.g., unexpected ride requests, data access).
• Advocate for Stronger Security: Support platforms that demonstrate a commitment to robust security practices and quickly address reported vulnerabilities.

By implementing the proposed app ID-based consistent tracking and validating consistency between state and redirect_uri, integration platforms can significantly bolster their defenses against these practical and pervasive cross-app attacks, protecting user accounts and privacy across the interconnected digital landscape.

Key Takeaways

• Practical Cross-App Attacks: The open ecosystem and paradigm shift in OAuth 2.0 usage within integration platforms enable practical Cross-App Account Takeover (CAT) and Cross-App Request Forgery (CARF) attacks, leading to account takeovers and privacy leakage.
• Flawed Active App Tracking: The root cause of these vulnerabilities is the platform's insufficient and inconsistent mechanisms for tracking the active app throughout the two-phase OAuth 2.0 flow, often relying solely on the state parameter or the redirect_uri.
• Widespread Vulnerability: A significant majority (16 out of 18) of mainstream integration platforms with open marketplaces, including offerings from major vendors like Google, Microsoft, Amazon, and Samsung, were found to be susceptible, demonstrating pervasive impact across the internet.
• Ineffectiveness of Existing Defenses: Traditional OAuth 2.0 defenses, such as PKCE, do not prevent these attacks, and existing issuer-based mix-up attack mitigations are impractical for integration platforms due to multiple apps potentially sharing the same authorization server issuer.
• Proposed App ID-Based Defense: The researchers propose a robust, tailored defense mechanism that involves embedding a unique app ID in both the state parameter and the redirect_uri, with the platform rigorously validating the consistency of these app IDs before code exchange.
• Cove Scan Tool & IETF Draft: The development of Cove Scan, a semi-automated dynamic testing tool, aids in discovering these vulnerabilities, and the publication of an IETF draft aims to raise awareness and integrate the proposed app ID-based defense into OAuth 2.0 security best practices.

About the Speaker(s)

The primary speaker for this presentation was Kaixuan Luo, a PhD candidate at the Chinese University of Hong Kong. His research focuses on the intersection of security and emerging technologies, with a particular emphasis on the vulnerabilities inherent in complex, interconnected digital ecosystems like integration platforms.

This work was a collaborative effort, with significant contributions from Simb Wong and Professor Winshin Law from M University, as well as Adon's Phone and Julian Lcom from Samsung Research America. This collaboration across academic and industry institutions underscores the interdisciplinary nature of addressing such critical security challenges in widely deployed technologies.