Exploiting Cloud Provider Vulnerabilities for Initial Access

Exploiting Cloud Provider Vulnerabilities for Initial Access

Speakers: Nick Frichette, Security Researcher, DataDog

Conference: DEF CON 32

YouTube: https://www.youtube.com/watch?v=oAriLYN-5HA

Overview

In his DEF CON 32 talk, Nick Frichette, a security researcher at DataDog specializing in AWS offensive security, unveiled a novel approach to gaining initial access to AWS accounts: exploiting vulnerabilities within AWS services themselves. Moving beyond the "boring" and prevalent attack vectors like leaked access keys, exposed S3 buckets, or compromised EC2 instances—which Frichette estimates account for 95% of real-world AWS breaches—this presentation focused on a more sophisticated strategy. The core idea is to abuse the pre-existing trust relationships that AWS Identity and Access Management (IAM) roles establish with various AWS services, effectively "kicking in the door to the cloud" by weaponizing a cloud provider's own infrastructure against its customers.

Frichette's research delves into the fundamental mechanisms of trust in AWS, particularly how services are granted permissions to operate within user accounts. By identifying flaws in the implementation of these trust boundaries, specifically the PassRole mechanism, an adversary could potentially hijack a service's legitimate actions to assume roles in victim accounts across different AWS tenants. This enables initial access, which can then be leveraged for privilege escalation, lateral movement, and resource access. While the specific vulnerabilities discussed have largely been remediated by AWS, the talk serves as a critical educational piece, offering invaluable insights into advanced cloud attack techniques and the underlying security principles that defenders can apply to future threats.

This article will explore the intricate details of how trust is established in AWS, delve into a specific vulnerability (a confused deputy in AWS AppSync) that allowed for cross-account role assumption, and discuss the broader implications for both offensive and defensive security in cloud environments. The aim is to understand not just what happened, but why it was possible, and what lessons can be drawn to enhance cloud security posture.

Background

▶ Watch: Introduction and speaker background (0:00)

The foundation of secure operations in AWS relies heavily on its Identity and Access Management (IAM) service. At its core, IAM allows administrators to securely control who is authenticated and authorized to use AWS resources. A critical component of IAM is the IAM role, which is an identity with specific permissions that can be assumed by trusted entities. Unlike an IAM user, a role does not have standard long-term credentials (like a password or access keys) associated with a single person; instead, it provides temporary security credentials when assumed.

A key design pattern in AWS involves services assuming IAM roles within a customer's account to perform delegated actions. For instance, an AWS Lambda function needs permission to read from an S3 bucket or write to a DynamoDB table. Instead of granting these permissions directly to the Lambda service, a specific IAM role is created in the customer's account. This role is configured with a trust policy that specifies who or what is permitted to assume it. In the case of Lambda, the trust policy would typically allow the lambda.amazonaws.com service principal to perform the sts:AssumeRole action. This allows the Lambda service to temporarily assume the role and execute the function with its defined permissions.

The PassRole mechanism is another crucial security control. When a user or service provides an IAM role to another AWS service for it to assume, this action is governed by PassRole permissions. A fundamental rule of PassRole is that a role can only be passed within the same AWS account. This prevents an attacker from creating a malicious resource in their account (e.g., a Lambda function) and instructing an AWS service to assume a highly privileged role in a different, victim AWS account. Without this boundary, an attacker could theoretically leverage an AWS service as a proxy to arbitrarily assume roles and access resources across various customer accounts, provided the victim role trusts that service. The PassRole check is designed to ensure that if you are passing a role for a service to assume, you also have the permission to pass that specific role, and critically, that the role being passed resides in your own account. This makes cross-account PassRole a significant security barrier, and any bypass of this mechanism represents a severe vulnerability.

Key Findings

▶ Watch: Exploiting AWS service vulnerabilities for initial access (1:41)

The central finding of Nick Frichette's research is the discovery of vulnerabilities within core AWS services that enabled a bypass of the critical PassRole security boundary. These vulnerabilities allowed an attacker to achieve cross-account initial access to victim AWS environments by weaponizing AWS's own services. Instead of traditional attack vectors, the method involved exploiting a confused deputy scenario, where a privileged AWS service, acting on behalf of an attacker, was tricked into assuming an IAM role in a different, unsuspecting victim account.

Specifically, the talk highlighted:

• Bypass of the PassRole cross-account restriction: The primary achievement was demonstrating how certain service implementations failed to properly enforce the same-account restriction for PassRole, enabling an attacker to reference and cause a service to assume a role in a victim's account.
• Confused Deputy in AWS AppSync: A detailed example of this type of vulnerability was presented using AWS AppSync, a managed GraphQL service. This specific flaw allowed an attacker to configure their AppSync API to use a data source role belonging to a victim account.
• Abuse of pre-existing service trust: The attack capitalizes on the common and default practice of IAM roles trusting AWS service principals (e.g., lambda.amazonaws.com, appsync.amazonaws.com). When a vulnerability allows a service to be directed to a cross-account role, this pre-existing trust becomes the gateway for unauthorized access.
• Initial access to victim accounts: The successful exploitation of these vulnerabilities granted adversaries initial access to victim accounts, bypassing standard authentication and authorization checks. From this foothold, an attacker could then proceed with further actions like privilege escalation, lateral movement, and data exfiltration, depending on the permissions of the assumed role.

It is important to note that while the talk mentioned two example vulnerabilities and a more general misconfiguration, the transcript primarily elaborated on the AppSync confused deputy. The speaker also confirmed that the majority of these vulnerabilities have since been remediated by AWS, underscoring AWS's commitment to addressing such critical security findings. The enduring value of this research lies in the principles and attack patterns it reveals, which remain relevant for understanding and defending against sophisticated cloud threats.

Technical Deep Dive

▶ Watch: Mechanism of IAM role trust policies (2:58)

The core of Frichette's presentation revolves around the confused deputy problem within the context of AWS services. A confused deputy is a type of privilege escalation vulnerability where a legitimate, highly privileged entity (the "deputy") is tricked into performing an action that benefits an attacker, often against an unsuspecting third party. In AWS, this typically occurs when a service, acting on behalf of a user, performs an action that the user themselves wouldn't be authorized to do, or performs it in an unintended context (like a different account).

Let's break down the AppSync vulnerability:

AWS AppSync Overview:

AWS AppSync is a managed service that allows developers to build scalable GraphQL APIs. It acts as a gateway, routing GraphQL requests to various data sources like AWS Lambda functions, Amazon DynamoDB tables, or other HTTP endpoints. When configuring an AppSync API, you define a schema and then connect it to data sources. For AppSync to interact with these data sources, it requires permissions, which are typically granted via an IAM role. By default, when you set up a data source for AppSync, a role is created that has a trust policy allowing the appsync.amazonaws.com service principal to perform sts:AssumeRole. This means the AppSync service itself can assume this role to fetch or modify data as defined by your GraphQL API.

The Confused Deputy Vulnerability in AppSync:

The vulnerability stemmed from an improper enforcement of the PassRole security boundary within the AppSync service's internal logic. As previously explained, the PassRole mechanism dictates that you can only pass a role that exists within your own AWS account. This is a critical cross-account isolation control.

1. Attacker Setup: An attacker, operating from their own AWS account, would create an AppSync API.
2. Referencing a Victim Role: Instead of configuring their AppSync data source with a role from their own account, the attacker would craft a request that, due to the vulnerability, allowed them to specify the Amazon Resource Name (ARN) of an **IAM role residing in a victim's AWS account**. This victim role would, crucially, have a default trust policy allowing appsync.amazonaws.com to assume it. Many standard service roles automatically have such trust policies.
3. AppSync as the Confused Deputy: When the attacker's AppSync API was invoked (or simply configured in a way that triggered the service to validate or interact with the data source), the AWS AppSync service itself would attempt to assume the role. Because the victim role's trust policy explicitly permitted appsync.amazonaws.com to assume it, and because the AppSync service's internal PassRole check was flawed for this specific scenario, the service successfully assumed the victim's cross-account role.
4. Initial Access Gained: Once the AppSync service assumed the victim's role, the attacker, through their control of the AppSync API, could effectively leverage the permissions of that victim role. This granted the attacker initial access to the victim's AWS account, completely bypassing traditional authentication and authorization for that account. The attacker effectively weaponized a legitimate AWS service to act as their proxy.

This attack vector is particularly insidious because it subverts the very trust model AWS uses to enable service functionality. The AppSync service, a trusted entity, became the "confused deputy," performing an action (assuming a cross-account role) that directly benefited an unauthorized party (the attacker) without explicit authorization from the victim account owner. The success of this attack hinged on two factors: the victim role's trust policy allowing the AppSync service to assume it, and the AppSync service's internal failure to correctly enforce the PassRole same-account restriction when processing the attacker's crafted request.

While the transcript mentions the intention to discuss "two example vulnerabilities as well as a more general misconfiguration," the detailed technical explanation provided focuses exclusively on the AWS AppSync confused deputy. The Lambda example was used to illustrate the general concept of service trust policies and PassRole, not as a separate vulnerability exploit. This highlights the complexity and subtlety required to identify such flaws within cloud provider infrastructure.

Demo / Proof of Concept

▶ Watch: Explanation of the 'pass role' security boundary (4:15)

While the transcript does not provide a step-by-step account or visual description of a live demonstration, the nature of Frichette's talk strongly implies that a Proof of Concept (PoC) was developed and likely demonstrated to AWS for remediation, and potentially shown during the conference. The speaker's confident assertion that "we're going to look at some vulnerabilities that would allow us to hijack that trust relationship and gain access to victim accounts" suggests a practical, actionable exploit was at hand.

The conceptual demonstration would involve an attacker's AWS account and a simulated victim AWS account. The attacker would configure an AppSync API in their own account, but instead of specifying an IAM role from their account for the data source, they would provide the ARN of a pre-existing, vulnerable IAM role within the victim's account (one with a trust policy allowing appsync.amazonaws.com to assume it). Upon activation or interaction with the attacker's AppSync API, the underlying AWS AppSync service would then, in essence, "assume" the role in the victim's account. The successful outcome of such a demonstration would be the attacker gaining temporary credentials for the victim's role, enabling them to perform actions within the victim account according to that role's permissions. This would effectively showcase the bypass of the PassRole cross-account boundary and achieve initial access.

Defensive Implications

▶ Watch: Goal: Bypass pass role for cross-account access (5:20)

Although the specific vulnerabilities discussed in the talk have been remediated by AWS, the principles behind these attacks offer crucial lessons for cloud defenders. Understanding how these sophisticated attacks work is vital for building resilient cloud security architectures, especially in a landscape where new attack vectors are constantly emerging.

Here are key defensive implications:

1. Principle of Least Privilege for Service Roles: This attack underscores the importance of applying the Principle of Least Privilege not just to human users but also to roles assumed by AWS services. While default trust policies are convenient, examine the permissions granted to roles that trust AWS service principals. If an AppSync role only needs to read from a specific DynamoDB table, its permissions should be restricted to that granular level, rather than broad * access. This limits the blast radius if the role is ever compromised.

1. Restrict Trust Policies with Condition Keys: Even if a service principal like appsync.amazonaws.com needs to assume a role, you can add condition keys to the trust policy to further restrict when and from where it can be assumed.

• aws:SourceAccount: This condition key can restrict the service to only assume the role if the requesting principal originates from a specific AWS account ID. For instance, {"StringEquals": {"aws:SourceAccount": "YOUR_ACCOUNT_ID"}} in the trust policy would prevent a cross-account assumption even if the service itself is compromised.
• aws:SourceArn: Even more granular, aws:SourceArn can restrict the service to assume the role only if the request originates from a specific resource (e.g., a particular AppSync API ARN or Lambda function ARN). This ensures that only your specific AppSync API can leverage the role, not an attacker's.

1. Regular Auditing of IAM Trust Policies: Trust policies are often overlooked in security audits, yet they are the gateway for services and other accounts. Regularly review the trust policies of all IAM roles, especially those that grant trust to AWS service principals. Look for overly permissive Principal statements (e.g., * or broad service principals without conditions) or unintended cross-account trust relationships. Tools like AWS Config rules, CloudFormation hooks, or custom scripts can help automate this auditing.

1. Understanding the Shared Responsibility Model: This research highlights the nuances of the AWS Shared Responsibility Model. AWS is responsible for the security of the cloud (the underlying infrastructure, services, and global network), while customers are responsible for security in the cloud (their data, configuration, IAM, network configuration, etc.). Service vulnerabilities fall under AWS's responsibility. However, a customer's configuration (e.g., overly permissive trust policies or roles with excessive permissions) can amplify the impact of such a vulnerability. Defenders should always operate under the assumption that even AWS services could theoretically be leveraged maliciously if a vulnerability exists, and configure their resources defensively.

1. Proactive Threat Intelligence and Patching: Staying informed about newly discovered vulnerabilities, even those that are quickly patched, is crucial. While these specific issues are remediated, the underlying attack patterns (like confused deputy) can reappear in other services or contexts. Regularly reviewing security advisories and understanding how cloud providers address these issues contributes to a more mature defensive posture.

In summary, while the immediate threat from these specific vulnerabilities has passed, the talk serves as a powerful reminder that robust cloud security requires a deep understanding of IAM, meticulous configuration of trust policies, and a proactive approach to auditing and threat intelligence.

Key Takeaways

• Move Beyond Traditional Attack Vectors: Cloud breaches aren't limited to leaked keys or exposed buckets. Sophisticated adversaries are exploiting vulnerabilities in the underlying cloud provider services themselves.
• IAM Trust Policies are Critical: The sts:AssumeRole action and the associated trust policies are fundamental to AWS security. Misconfigurations or vulnerabilities in their implementation can lead to severe compromise.
• PassRole is a Crucial Security Boundary: The PassRole mechanism, designed to prevent cross-account role assumption by services, is a vital control. Any bypass of this boundary is a significant security flaw.
• Confused Deputy is a Potent Attack Pattern: Understanding the confused deputy problem is essential for both attackers and defenders in the cloud. It highlights how a legitimate, privileged service can be tricked into acting maliciously.
• Layered Defense is Paramount: Even with cloud provider vulnerabilities, a strong defensive posture—including least privilege, granular condition keys in trust policies, and continuous auditing—can significantly mitigate the impact.
• Learn from Past Vulnerabilities: While specific vulnerabilities are remediated, the underlying attack techniques and defensive lessons remain highly relevant for future cloud security efforts.

About the Speaker(s)

Nick Frichette is a security researcher at DataDog, where his work focuses on AWS offensive security. His specialization involves identifying effective methods to attack AWS environments, with a subsequent emphasis on developing detection and prevention strategies for such behaviors. In his free time, Nick is also the creator and maintainer of Hacking the Cloud, an open-source encyclopedia dedicated to offensive security techniques applicable in cloud hacking scenarios. He is passionate about uncovering vulnerabilities in underlying AWS services, some of which were the subject of his DEF CON 32 talk.