Kicking in the Door to the Cloud: Exploiting Cloud Provider Vulnerabilities for Initial Access

Kicking in the Door to the Cloud: Exploiting Cloud Provider Vulnerabilities for Initial Access

Speakers: Unknown

Conference: Black Hat USA

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

Overview

This Black Hat USA talk, titled "Kicking in the Door to the Cloud: Exploiting Cloud Provider Vulnerabilities for Initial Access," delves into novel and sophisticated methods for gaining initial access to Amazon Web Services (AWS) environments. Moving beyond the prevalent attack vectors such as leaked access keys, exposed S3 buckets, or compromised EC2 instances, the speaker explores how adversaries can directly exploit vulnerabilities within AWS services themselves. The core focus is on abusing pre-existing trust relationships that AWS services hold within customer accounts, transforming these trusted entities into tools for unauthorized access and privilege escalation.

The presentation highlights a critical, yet often overlooked, attack surface: the intricate web of trust established between IAM roles in a customer's account and various AWS services. By identifying and exploiting flaws in how these services interact with IAM roles, an attacker can hijack the service's legitimate permissions to operate within a target account. While all vulnerabilities discussed have since been remediated by AWS, the talk serves as a vital educational resource, offering deep insights into advanced cloud attack techniques and fostering a proactive approach to cloud security for both attackers and defenders.

The talk provides a detailed examination of how IAM trust policies function, particularly when tied to AWS services, and then dives into specific vulnerabilities, including a confused deputy flaw in AWS AppSync. The speaker emphasizes the importance of understanding these complex interactions to better identify and mitigate similar threats, ensuring cloud environments are resilient against emerging attack methodologies.

Background

▶ Watch: Introduction: Exploiting cloud provider vulnerabilities for initial access (0:00)

Traditional methods of breaching AWS environments typically involve common misconfigurations or leaked credentials. These include leaked access keys, which grant direct programmatic access; exposed S3 buckets, leading to data exfiltration or unauthorized uploads; and exploited EC2 instances, providing a beachhead into the network. While these remain significant risks, the talk posits that focusing solely on these "boring" vectors overlooks a more advanced class of vulnerabilities: those residing within the AWS control plane itself.

The foundation of the attacks discussed lies in understanding pre-existing trust within AWS. A common design pattern involves IAM roles configured in a customer's account that establish a trust relationship with an AWS service. This trust allows the service to assume the IAM role and perform actions on behalf of the customer, such as managing resources or executing functions. For instance, an AWS Lambda function, when invoked, relies on the Lambda service to assume an associated IAM role to perform its designated tasks. The permissions granted to this role dictate what the Lambda function can do.

Central to this trust model is the role trust policy, a JSON document attached to every IAM role. This policy specifies which principals (users, roles, or AWS services) are permitted to assume the role. For service-linked roles, the trust policy typically grants the specific AWS service (e.g., lambda.amazonaws.com or appsync.amazonaws.com) the permission to assume the role.

A critical security boundary in AWS is enforced by the PassRole permission. When a user or service provides an IAM role ARN to another AWS service for it to assume, the calling entity must have iam:PassRole permissions for that specific role. Crucially, AWS enforces that a role can only be passed within the same AWS account. Attempting a cross-account PassRole operation typically results in an "Access Denied" error. This mechanism is vital; without it, an attacker could arbitrarily instruct an AWS service in their own account to assume a role in a victim's account, thereby bypassing all traditional access controls. The PassRole restriction is a fundamental defense against confused deputy attacks, where a legitimate, privileged service is tricked into performing actions on behalf of an unauthorized principal. The talk's premise is to find ways to bypass this fundamental security control.

Key Findings

▶ Watch: The critical 'pass role' security boundary in AWS (3:58)

The primary finding presented in the talk is a sophisticated confused deputy vulnerability discovered in AWS AppSync. This vulnerability allowed an attacker to bypass the critical cross-account PassRole restriction, enabling them to force the AppSync service in their own AWS account to assume an IAM role located in a different, target AWS account. This effectively granted initial access to the victim's environment by weaponizing a trusted AWS service.

The specific mechanism for this bypass was rooted in an unexpected case-insensitivity within the AppSync API's parameter parsing. While most AWS APIs enforce strict case sensitivity for parameters, the AppSync API deviated from this standard. This anomaly created a window of opportunity to manipulate how the PassRole check was performed.

Additionally, the speaker briefly mentioned a "more general misconfiguration" that could lead roles to be vulnerable, specifically referencing assume role with web identity. However, the provided transcript excerpt concludes before detailing this second vulnerability or misconfiguration, so specific technical insights regarding it are not available. The core contribution detailed is the AppSync flaw, demonstrating how subtle API implementation differences can lead to severe security bypasses.

Technical Deep Dive

▶ Watch: First vulnerability: Confused Deputy in AWS AppSync (4:30)

The technical deep dive of the talk focuses exclusively on the AppSync confused deputy vulnerability. AWS AppSync is a managed GraphQL service that allows developers to build scalable GraphQL APIs. Similar to Lambda, AppSync data sources are often configured with an IAM role that grants the AppSync service the necessary permissions to interact with backend resources (e.g., databases, other AWS services). By default, this role's trust policy allows appsync.amazonaws.com to assume it.

The security boundary intended to prevent cross-account PassRole operations is robust for most AWS services. If an attacker in their account (Account A) attempted to create an AppSync API and configure it to use an IAM role ARN from a victim's account (Account B), the API call would normally fail with an "Access Denied" error, explicitly stating "cross account pass role is not allowed." This is the expected and desired security behavior.

However, the speaker identified a critical deviation in AppSync's API behavior. Typically, AWS APIs are case-sensitive regarding parameter names. For example, if an API expects a parameter named SecretString, providing secretstring or SECRETSTRING would result in an error (e.g., "400 Bad Request, member must not be null") because the API would not recognize the incorrectly cased parameter. This strictness ensures that all validation and security checks are applied consistently to the expected parameter.

In contrast, the AppSync API exhibited unusual case-insensitivity. The speaker demonstrated that parameters could be passed with arbitrary mixed case (e.g., ServiceRoleARN, servicerolearn, ServicEroleArn), and the API would accept them without error. Presumably, the backend normalized these values before processing. This observation was the lynchpin of the exploit.

The parameter used to specify the IAM role for AppSync was serviceRoleARN (with capital 'R' and 'A'). When an attacker provided a cross-account role ARN using this exact casing, the PassRole check correctly identified the cross-account attempt and blocked it. However, if the attacker altered the casing of the parameter name, for instance, to servicerolearn (all lowercase) or any other variation, and then provided a cross-account role ARN, the PassRole validation or filtering mechanism failed to trigger or was completely bypassed.

The precise reason for this bypass—whether it was due to a different code path being taken, a failure to apply the PassRole check when the parameter name was not an exact case match, or an issue in the parameter normalization process—remained "unknown" according to the speaker. Regardless of the underlying cause, the practical effect was that an attacker could successfully assign an arbitrary IAM role from a victim's account to an AppSync data source in their own account. Once configured, the AppSync service would then assume this cross-account role in the victim's environment, granting the attacker the permissions associated with that role. This constitutes a direct initial access vector, leveraging a trusted AWS service to breach an unsuspecting account.

Demo / Proof of Concept

▶ Watch: AppSync bypass: Case-insensitivity for cross-account pass role (6:00)

While the talk did not present a live, step-by-step demonstration in the provided transcript, the speaker meticulously explained the operational flow of the exploit, effectively outlining a proof of concept (PoC). The PoC process would unfold as follows:

1. Attacker Setup: An attacker would first set up their own AWS account.
2. Target Identification: The attacker would identify a target AWS account and, ideally, an IAM role within that account that had a trust policy allowing appsync.amazonaws.com to assume it. While the talk implies the attacker might not have legitimate access to the target account, this step assumes some prior knowledge or enumeration capability to identify a suitable role ARN.
3. AppSync API Creation (Attacker Account): The attacker would initiate the creation of an AppSync API in their own account.
4. Data Source Configuration with Malicious Role: During the configuration of an AppSync data source, the attacker would attempt to specify the IAM role that AppSync should assume. Instead of providing a role ARN from their own account, they would supply the ARN of the target IAM role from the victim's account.
5. Bypassing PassRole: Crucially, when submitting the API call to create or update the AppSync data source, the attacker would modify the casing of the serviceRoleARN parameter (e.g., to servicerolearn). This subtle change, as discovered, would bypass the cross-account PassRole validation.
6. Successful Role Assignment: If the exploit was successful, the AppSync service in the attacker's account would now be configured to assume the target IAM role in the victim's account.
7. Execution and Access: Upon any operation that causes the AppSync data source to be invoked (e.g., a GraphQL query), the AppSync service would assume the role in the victim's account. This would grant the attacker, via the AppSync service, programmatic access to resources and actions permitted by that specific IAM role in the victim's environment. From there, the attacker could perform actions like escalating privileges, accessing sensitive data, or moving laterally within the victim's cloud infrastructure.

This detailed explanation effectively serves as a blueprint for how a threat actor could have leveraged this specific vulnerability for initial access, showcasing the critical impact of such a flaw.

Defensive Implications

▶ Watch: Summary of weaponizing cloud services via confused deputy attacks (8:00)

The discovery and subsequent remediation of the AppSync confused deputy vulnerability by AWS offer crucial lessons for cloud defenders. While the immediate threat from this specific flaw has been eliminated, the underlying principles of the attack remain highly relevant for identifying and mitigating similar issues.

1. Understand Confused Deputy Attacks: Defenders must deeply understand the confused deputy problem in the context of cloud services. This attack vector exploits a service's legitimate permissions to act on behalf of an unauthorized principal. It highlights the need to scrutinize how services interact with IAM roles and how those interactions are validated.
2. Audit IAM Role Trust Policies: Regularly auditing IAM role trust policies is paramount. While AWS services require trust, these policies should be as restrictive as possible. For service-linked roles, ensure the Principal in the trust policy correctly specifies the AWS service (e.g., appsync.amazonaws.com) and not broader entities. More importantly, verify that any conditions placed on sts:AssumeRole are robust.
3. Leverage Condition Keys: The speaker briefly mentioned condition statements and condition keys as potential defenses against confused deputy attacks. These are powerful tools within IAM policies that allow for fine-grained control over when and how a role can be assumed. For example, condition keys like aws:SourceAccount or aws:SourceArn can be used in a role's trust policy to ensure that the role can only be assumed by a service acting on behalf of a specific account or resource. This would prevent a service in an attacker's account from assuming a role in a victim's account, even if other checks were bypassed.
4. Implement PassRole Best Practices: While the PassRole vulnerability was an AWS service flaw, the concept of PassRole permissions is crucial. Defenders should ensure that IAM users and roles are granted iam:PassRole permissions only for the specific roles they are genuinely authorized to pass to other services, following the principle of least privilege.
5. Stay Informed on AWS Security Advisories: The fact that AWS quickly fixed these vulnerabilities underscores the importance of staying updated with AWS security bulletins and remediating any identified issues promptly.
6. Continuous Security Monitoring and Auditing: Implement continuous monitoring for unusual IAM activities, especially sts:AssumeRole events involving roles that are typically assumed by AWS services. Unexpected cross-account role assumptions should trigger immediate alerts. Regular automated audits of IAM policies can help identify misconfigurations before they are exploited.
7. Defense in Depth Against Zero-Days: The talk highlighted the "worst-case scenario of an adversary having a cross tenant zero day in AWS." While specific to AWS's responsibility, defenders can mitigate the impact of such events by segmenting environments, enforcing strict network boundaries, and ensuring that even if initial access is gained, privilege escalation and lateral movement are severely hampered.

By learning from these sophisticated attacks, organizations can strengthen their cloud security posture, moving beyond basic misconfiguration checks to address more nuanced and impactful vulnerabilities at the cloud provider service level.

Key Takeaways

• Novel Initial Access Vectors: Traditional AWS breach methods (leaked keys, exposed S3, exploited EC2) are being augmented by more sophisticated attacks exploiting vulnerabilities in AWS services themselves.
• Confused Deputy Attacks: A significant threat model involves confused deputy attacks, where an attacker tricks a legitimate, privileged AWS service into performing actions on their behalf within a victim's account, bypassing cross-account security boundaries.
• AWS AppSync Vulnerability: A specific confused deputy vulnerability in AWS AppSync was discovered, allowing attackers to bypass the cross-account PassRole restriction.
• Case-Insensitivity Bypass: The AppSync exploit leveraged an unusual case-insensitivity in the AppSync API's parameter parsing. By altering the casing of the serviceRoleARN parameter, the critical PassRole validation was bypassed, enabling arbitrary cross-account role assumption.
• Importance of PassRole and Trust Policies: The PassRole permission is a vital security control preventing arbitrary cross-account role assumption. Understanding and correctly configuring IAM role trust policies, particularly with strong condition keys, is crucial for defense.
• Learning from Fixed Vulnerabilities: All vulnerabilities discussed have been fixed by AWS. However, studying these past exploits provides invaluable insights into advanced attack techniques and helps defenders identify similar patterns and potential weaknesses in their own cloud architectures.

About the Speaker(s)

The talk was delivered by Nick Frich, who introduced himself at the conclusion of the presentation. Nick's work is associated with Security Labs at Datadog, where he and his team conduct research into cloud security. His expertise lies in uncovering and analyzing sophisticated vulnerabilities within cloud environments, contributing to the broader understanding of cloud attack and defense strategies. More of his research can be found at securitylabs.datadoghq.com.