One Hack to Rule Them All: Pervasive Account Takeovers in Integration Platforms

One Hack to Rule Them All: Pervasive Account Takeovers in Integration Platforms

Speakers: K, PhD Candidate at Chinese University of Hong Kong, Former Intern at Samsung Research America

Conference: Black Hat USA

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

Overview

This talk, presented by K from the Chinese University of Hong Kong and Samsung Research America, unveils a critical new class of authorization attacks that lead to pervasive account takeovers across a wide spectrum of integration platforms. The research highlights fundamental vulnerabilities within how these platforms implement OAuth 2.0 for account linking, a feature central to their functionality. By exploiting these flaws, attackers can gain unauthorized control over victim accounts, access sensitive data, and manipulate connected services.

The significance of this research cannot be overstated, as it impacts major players in diverse categories, including workflow automation platforms, virtual voice assistants, smart home ecosystems, and even emerging large language model (LLM) platforms with plugin support. Many of these platforms boast over 100 million users, making the discovered vulnerabilities a widespread threat. The findings reveal that 24 out of 25 investigated platforms were susceptible, with many attacks requiring only a single click from the victim.

The presentation provides a deep dive into the technical specifics of these attacks, illustrating how misconfigurations in OAuth 2.0 parameter validation and timing issues in security checks enable attackers to hijack authorization codes. Concrete examples demonstrate the severe real-world implications, from stealing Microsoft Outlook emails and leaking Azure Key Vault secrets to controlling smart home devices. The researchers commend several companies, including Samsung, Microsoft, Amazon, and Google, for their responsible engagement and swift remediation efforts following disclosure.

Background

▶ Watch: Introduction to pervasive account takeovers in integration platforms (0:00)

Integration platforms are designed to create an "all-in-one solution" by connecting and aggregating functionalities from various internet services and applications. This broad category encompasses traditional workflow automation platforms like Microsoft Power Automate and IFTTT, virtual voice assistants such as Alexa, smart home ecosystems like Google Home, and more recently, large language model (LLM) platforms with plugin support, exemplified by OpenAI ChatGPT. Their core promise is seamless interoperability, allowing users to control diverse services through a single interface, like asking Alexa to call a Lift or turn off a smart light.

Central to this aggregation is account linking, a mandatory feature that connects an end-user's external app accounts (e.g., Lift, Outlook) to their platform account (e.g., Alexa, Power Automate). This mechanism grants the integration platform the necessary permissions to control linked applications on behalf of the user. The OAuth 2.0 protocol, specifically the Authorization Code Grant flow, is the most prevalent standard used to establish these account links.

Integration platforms often feature open marketplaces where third-party developers can register and publish applications. While fostering innovation, this openness also introduces the risk of malicious app infiltration. The researchers identify two primary attack scenarios stemming from vulnerabilities in account linking:

1. Cross-App Attack Scenario: In this scenario, the attacker registers and operates a malicious app within the platform's marketplace. The goal is to steal a victim's external app account (e.g., their Lift account) and bind it to the attacker's own platform account (e.g., attacker's Alexa). This grants the attacker unauthorized control over the victim's app, allowing actions like requesting free rides at the victim's expense. Alternatively, an attacker could bind their own app account to a victim's platform account, enabling them to track the victim's activities.
2. Cross-User Attack Scenario: This more insidious scenario demonstrates that even if a platform has a closed marketplace or manages to exclude all malicious apps, an attacker can still operate as a normal platform user. By directly targeting a victim, the attacker can still achieve unauthorized control over the victim's linked accounts. This highlights that the vulnerabilities are not solely dependent on the presence of malicious third-party applications but can also arise from fundamental design and implementation flaws in the account linking process itself.

The underlying problem arises from subtle yet critical misconfigurations and validation weaknesses within the OAuth 2.0 implementation, particularly concerning the handling of app IDs and the state parameter during the authorization flow. These flaws allow an attacker to trick the platform into associating a victim's authorization code with a malicious entity, leading to a full account takeover.

Key Findings

▶ Watch: Understanding cross-app and cross-user attack scenarios (2:30)

The comprehensive investigation conducted by the researchers spanned 25 major integration platforms across a diverse range of categories. These included seven workflow automation platforms, six virtual voice assistants, four smart home systems, two LLM-based plugins, and six other specialized platforms. All selected platforms are prominent players in their respective domains, with many serving over 100 million users, underscoring the broad potential impact of the discovered vulnerabilities.

The findings were stark: an overwhelming 24 out of the 25 investigated platforms were found to be vulnerable to the described authorization attacks. This nearly universal susceptibility highlights a systemic issue within the industry's implementation of account linking via OAuth 2.0.

A particularly alarming discovery was the ease with which these attacks could be executed: for 19 of the vulnerable platforms, the attacks could be completed with just a single click on an image link by the victim. This low barrier to entry significantly increases the risk, as it makes phishing and social engineering campaigns highly effective.

Breaking down the attack types, the researchers found that 16 platforms were susceptible to cross-app attacks, where a malicious app could facilitate the takeover. Separately, 16 platforms were vulnerable to cross-user attacks, demonstrating that an attacker could achieve unauthorized control even without deploying a malicious app. Notably, eight platforms exhibited vulnerabilities to both cross-app and cross-user attack scenarios, indicating multiple points of failure in their security architecture.

In line with responsible disclosure practices, the researchers informed all 24 vulnerable platforms of their findings. As of the talk, 16 platforms had confirmed the vulnerabilities. The impact of these discoveries was recognized by the industry, leading to the accumulation of four critical or P1 bugs. The most severe of these was assigned a CVSS score of 9.6, indicating a critical severity vulnerability with high impact and low complexity to exploit. The research team also received "generous bug bounties" for their efforts.

The speakers extended "kudos" to several companies for their exemplary response:

• Samsung Research America for initiating the study of these issues as early as 2019 and supporting the expanded research.
• Microsoft for maintaining close communication throughout the disclosure process.
• Amazon for responsibly fixing the identified issues and providing generous bounties.
• Google for their exceptionally swift response, fixing their vulnerabilities within just two weeks.

Technical Deep Dive

▶ Watch: Live demonstration setup: victim tricked by a link (4:00)

The core of the discovered vulnerabilities lies in the improper implementation and validation within the OAuth 2.0 Authorization Code Grant flow, which is the foundation of account linking across these integration platforms. This protocol involves three main entities: the OAuth client (typically hosted by the platform backend), the platform frontend (the user agent, usually a web browser), and the integrated app's authorization server. The process normally proceeds in two phases: an authorization phase where a code is issued, and a token exchange phase where this code is traded for an access token.

In a legitimate account linking scenario, the end-user initiates the link from the platform frontend, which then directs the request to the integration platform's backend. The user is subsequently redirected to the integrated app's authorization server to grant consent. Upon successful authorization, the authorization server issues a one-time code back to the platform.

The critical flaw identified by the researchers, exemplified by a vulnerability found at Microsoft, centers on how platforms validate the context of the authorization code. The attack unfolds as follows:

1. Victim Enticement: The victim is tricked into clicking a specially crafted malicious link. This link initiates an OAuth flow, often for a legitimate service the victim uses (e.g., Outlook).
2. Automatic Authorization Code Issuance: Due to the victim's active session with the legitimate service, an authorization code is automatically issued by the integrated app's authorization server, often without any explicit user interaction or notification. This code is then directed to a redirection endpoint.
3. The app ID Mismatch Vulnerability: The fundamental vulnerability arises at this redirection endpoint. While the user interface (UI) might display an app ID corresponding to a legitimate application, the integration platform's backend makes a crucial error. It solely determines the active app by the app ID embedded within the state parameter of the OAuth redirect, rather than cross-referencing it with the app ID displayed in the UI or other more robust identifiers.
4. Authorization Code Leakage: An attacker crafts the malicious link such that the state parameter contains the app ID of their malicious app. Despite the UI potentially showing a legitimate app, the vulnerable platform backend incorrectly associates the victim's authorization code (e.g., for their Outlook account) with the malicious app's app ID from the state parameter. Consequently, the victim's legitimate authorization code is then sent to the attacker's control server, effectively leaking it.
5. Token Exchange and Account Takeover: With the stolen authorization code, the attacker can then perform the second phase of the OAuth flow: exchanging the code for an access token. This access token grants the attacker full control over the victim's linked account (e.g., Outlook). The attacker can then bind this stolen access token to their own platform account, enabling them to operate the victim's app functionalities as if they were the victim.

The researchers also noted that Microsoft had a user session integrity check in place, intended to prevent transaction fixation issues. However, this check was performed "way too late" in the process – after the authorization code had already been exchanged for an access token and leaked to the attacker. This timing flaw rendered the integrity check ineffective, as the damage was already done.

The immediate impacts were severe: attackers could steal Outlook emails, leak API keys and secrets from Azure Key Vault (if the victim was a vault administrator), and potentially compromise over 50 Microsoft services within the Microsoft 365 and Azure ecosystems.

Microsoft's subsequent fix addressed these issues in two critical steps:

1. Ensuring that the user session integrity check is performed in a timely manner, specifically before the authorization code exchange.
2. Mandating and matching the app ID in the UI with the app ID in the state parameter, preventing the platform from being misled by a manipulated state value. This ensures consistent validation across different parts of the authorization flow.

Demo / Proof of Concept

▶ Watch: Technical analysis: OAuth 2.0 authorization code grant abuse (5:00)

The presentation included several compelling demonstrations and case studies to illustrate the practical implications of these authorization bypasses. These Proof of Concept (PoC) attacks highlighted the ease of exploitation and the severe consequences for victims.

One prominent demonstration targeted Microsoft Power Automate, showcasing how an attacker could gain unauthorized access to a victim's Microsoft Outlook emails. In this scenario, the victim was tricked into clicking a malicious link. Crucially, the attack exploited vulnerabilities related to Microsoft's own first-party applications, which are implicitly trusted by the Power Automate platform. This meant that no explicit user consent from the victim was ever requested or needed, nor did the victim even need to be an existing Microsoft Power Automate user or aware of the platform's existence. Once the attack was successful, the attacker could view all of the victim's Outlook emails, demonstrating a complete email account takeover. The attacker could then set up a workflow within their own Power Automate account to forward all of the victim's incoming emails to an attacker-controlled server.

Another critical PoC involved the leakage of sensitive data from Azure Key Vault, a key management service used to store cryptographic keys and secrets in the cloud. Assuming the victim was an Azure Vault administrator, the attacker could again lure the victim into clicking a few links, potentially embedded in an encrypted email. The successful exploitation allowed the attacker to list all the key names within the victim's Key Vault. Further exploitation then enabled the attacker to retrieve the actual secret values associated with those keys, demonstrating a severe breach of cloud security and access to highly confidential information.

A more general, but equally impactful, demonstration involved the control of smart home devices. The researchers illustrated a scenario where a victim's smart lamp, controllable via a platform like Alexa, could be hijacked. After the victim clicked a single malicious link, an attacker could bind the victim's smart lamp account to their own Alexa account. Subsequently, the attacker could issue commands through their personal Alexa device to control the victim's smart lamp, such as turning it on or off, without the victim's consent or knowledge. This example effectively highlighted the potential for real-world physical control and privacy invasion stemming from these authorization vulnerabilities.

These demonstrations underscored that the pervasive account takeovers were not theoretical but practical and achievable with minimal user interaction, leading to significant data breaches and unauthorized control over various digital and physical assets.

Defensive Implications

▶ Watch: Vulnerability enabling automatic authorization code issuance (9:50)

The findings of this research present critical defensive implications for both platform developers and end-users, demanding a re-evaluation of current security practices in the context of integration platforms and OAuth 2.0 implementations.

For Platform Developers and Security Teams:

1. Strict OAuth 2.0 Parameter Validation: The primary lesson is to implement robust and comprehensive validation of all OAuth 2.0 parameters, especially the app ID and state parameter. Platforms must mandate and consistently match the app ID presented in the user interface (UI) with the app ID specified in the state parameter. Relying solely on the state parameter, which can be manipulated by an attacker, is a critical vulnerability.
2. Timely User Session Integrity Checks: Integrate user session integrity checks at the earliest possible stage in the OAuth flow, specifically before the authorization code is exchanged for an access token. Performing these checks too late, as seen in the Microsoft example, renders them ineffective against authorization code leakage. These checks should verify that the user's current session context aligns with the authorization request.
3. Defense in Depth for First-Party Integrations: Recognize that "first-party apps" (services owned by the platform provider, like Microsoft Outlook within Power Automate) are often implicitly trusted. This implicit trust can create blind spots. Platforms must apply the same, if not stricter, security scrutiny and validation mechanisms to first-party integrations as they do for third-party apps, especially when it comes to account linking.
4. Review OAuth 2.0 Authorization Code Grant Implementation: Conduct thorough security audits and code reviews of all OAuth 2.0 Authorization Code Grant implementations. Pay close attention to redirection logic, state parameter handling, and the timing of security controls. Consider adopting PKCE (Proof Key for Code Exchange) for public clients to mitigate authorization code interception attacks, although the attacks discussed here focused on different bypasses.
5. Robust Bug Bounty Programs and Disclosure Policies: Maintain accessible and responsive bug bounty programs and clear responsible disclosure policies. The positive outcomes with Samsung, Microsoft, Amazon, and Google highlight the importance of collaborative security efforts in patching widespread vulnerabilities quickly.
6. Threat Modeling for Account Linking: Develop comprehensive threat models specifically for account linking functionalities, considering both cross-app and cross-user attack scenarios. Understand how an attacker might manipulate the flow at various stages to achieve unauthorized access.

For End-Users:

1. Exercise Extreme Caution with Links: Be highly suspicious of unsolicited links, even if they appear to come from trusted sources or relate to services you use. A single click can lead to an account takeover. Always verify the legitimacy of links before clicking, perhaps by manually navigating to the service or app.
2. Review Linked Accounts and Permissions: Regularly audit the accounts linked to your integration platforms (e.g., Alexa, Google Home, Power Automate). Understand what permissions each linked app has and revoke access for any connections that are unfamiliar, unused, or suspicious.
3. Understand OAuth Consent Screens: Pay close attention to the permissions requested on OAuth consent screens. While these attacks often bypass explicit consent, understanding what an app is asking for can be a last line of defense.
4. Enable Multi-Factor Authentication (MFA): While these OAuth bypasses can circumvent traditional MFA mechanisms by stealing the underlying access token, MFA still provides a crucial layer of defense for direct login attempts and should be enabled wherever possible.

By implementing these defensive measures, both platform providers and users can significantly enhance their resilience against pervasive account takeovers in the increasingly interconnected digital ecosystem.

Key Takeaways

• Pervasive Vulnerability: A staggering 24 out of 25 major integration platforms, including workflow automation, virtual voice assistants, smart homes, and LLM plugins, were found vulnerable to authorization attacks.
• OAuth 2.0 Account Linking is a Critical Attack Surface: The widespread use of OAuth 2.0 for account linking introduces a systemic vulnerability when implementations suffer from flaws in parameter validation and timing of security checks.
• Single-Click Account Takeovers: For 19 platforms, attackers could achieve full account takeover with just a single click on a malicious link, highlighting the low barrier to exploitation and the effectiveness of social engineering.
• Fundamental Flaws in app ID and state Parameter Validation: The core vulnerability often stems from platforms incorrectly determining the active app by solely relying on the app ID in the state parameter, rather than validating it against other UI elements or performing timely integrity checks.
• Severe Real-World Impacts: Successful attacks can lead to stealing sensitive data like Outlook emails and Azure Key Vault secrets, or gaining unauthorized control over smart home devices, compromising both digital privacy and physical security.
• First-Party Integrations Are Not Immune: Even implicitly trusted first-party integrations (e.g., Microsoft Outlook within Microsoft Power Automate) are susceptible, requiring platforms to apply rigorous security to all linked services.

About the Speaker(s)

The primary speaker for this presentation was K, a PhD candidate currently affiliated with the Chinese University of Hong Kong. K initiated this significant research work during their tenure as a former intern at Samsung Research America. The project was a collaborative effort, undertaken as joint work with a lab mate, their PhD advisor Professor Law, and colleagues and managers at Samsung and Julia.