Breaching AWS Through Shadow Resources

Breaching AWS Through Shadow Resources

Speakers: Yakir Kadkoda, Michael Katchinskiy, Ofek Itach

Conference: DEF CON 32

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

Overview

This talk, presented by Yakir Kadkoda, Michael Katchinskiy, and Ofek Itach from Aqua Security, delves into a critical but often overlooked aspect of cloud security: Shadow Resources within AWS. The researchers demonstrate how automatically generated AWS resources, particularly S3 buckets, can be exploited to achieve severe compromises, including remote AWS account takeover by an external attacker assuming an admin role. A central theme throughout the presentation is the long-standing debate surrounding the security implications of AWS account IDs – whether they should be treated as secrets or not. The findings strongly suggest that attackers can leverage publicly available or semi-predictable account IDs to facilitate impactful attacks.

The core of the research uncovers several vulnerabilities related to the naming conventions and creation lifecycle of these shadow resources. By understanding how AWS services like CloudFormation generate resources on behalf of users, the team developed techniques to pre-register specific S3 bucket names or exploit information disclosure to gain a foothold. The most impactful exploit combines bucket pre-registration with resource injection in CloudFormation templates, demonstrating a practical path to full account compromise. The speakers also introduce an open-source tool developed during their research to aid in identifying such vulnerabilities and propose robust mitigations.

Background

▶ Watch: Initial hook: AWS Account ID secret? (0:00)

The journey into Shadow Resources began with an observation during routine use of the AWS Management Console. When a user uploads a template file to the CloudFormation service, AWS automatically provisions an S3 bucket in the background. This occurs without explicit user instruction, making the S3 bucket a prime example of a "shadow resource"—a resource generated automatically or semi-automatically by AWS, often without direct user intervention, and thus prone to going unnoticed by the account owner.

Understanding the nature of S3 buckets is crucial here. S3 bucket names are globally unique across all of AWS. If an S3 bucket named "cool-bucket-one" is created in one account, no other AWS account can claim that same name. This global uniqueness forms the foundation for several of the vulnerabilities discussed. CloudFormation, as an Infrastructure-as-Code (IaC) service, allows users to define AWS resources in template files (e.g., YAML or JSON). When a user deploys a CloudFormation stack based on such a template, the service provisions the specified resources.

Another fundamental topic is the AWS account ID, a 12-digit identifier unique to each AWS account. Historically, there has been a significant debate within the security community about whether this ID should be considered a secret. While AWS documentation advises sharing it carefully, it does not explicitly classify it as a secret. However, security practitioners have consistently highlighted that knowing an account ID can enable attackers to perform reconnaissance, craft targeted attacks, or facilitate cross-account interactions, making its cautious handling paramount. The research presented in this talk provides further evidence supporting the view that account IDs, even when not explicitly secret, can be critical components in an attack chain.

Key Findings

▶ Watch: Defining Shadow Resources with CloudFormation S3 example (2:15)

The research uncovered several critical findings that collectively demonstrate a powerful attack vector against AWS accounts through the exploitation of shadow resources:

1. Discovery of Shadow Resources and Semi-Predictable Naming: The initial discovery focused on CloudFormation's automatic creation of S3 buckets when a user uploads a template via the AWS GUI. These buckets follow a specific naming pattern: CF template-<hash>-<region>. While the region is predictable, and "CF template" is a constant prefix, the <hash> component, unique per account, initially appeared to introduce an element of unpredictability. This "semi-predictable" nature was the first key finding.
2. Initial Attack Vector: Bucket Pre-registration: The researchers realized that if an attacker could predict or discover this bucket name, they could pre-register the S3 bucket before the legitimate user. By claiming the bucket name first and configuring it with a highly permissive resource-based policy (e.g., allowing s3:PutObject from any AWS principal), an attacker could then intercept or modify CloudFormation templates intended for the victim's account. This pre-registration forms the basis of the attack.
3. The Challenge of Hash Randomization: A significant hurdle emerged when analyzing the <hash> component of the bucket name. Initial attempts to enumerate or reverse-engineer the hash proved unsuccessful. Further investigation into AWS's open-source code revealed that the hash is, in fact, randomized, making it impossible for an attacker to reliably predict a new account's unique hash. This initially seemed to invalidate the practical applicability of the bucket pre-registration technique.
4. Solution: Open-Source Intelligence for Existing Hashes: Undeterred, the researchers devised an ingenious workaround. They leveraged open-source intelligence (OSINT) tools like GitHub and SourceGraph to search for existing CF template-<hash>-<region> bucket names in publicly accessible code repositories, configuration files, or logs. This strategy proved highly effective, allowing them to discover over a thousand such buckets, demonstrating that while the hash might be randomized for new accounts, many existing accounts expose their hashed bucket names, making them vulnerable. This gave them the ability to "hack like a couple of big organizations."
5. Discovery of Account ID Inclusion in Other Service's Bucket Names: Expanding their research, the team found that the CloudFormation CF template-<hash>-<region> pattern was not the only instance of semi-predictable shadow resources. They identified other AWS services that generate S3 buckets whose names directly incorporate the AWS account ID (e.g., some-service-<account-id>-<region>). This constitutes a direct information disclosure scenario, as the account ID, while not a secret, can now be directly linked to a globally unique resource name, further facilitating targeted attacks.
6. Combining with Resource Injection for Admin Role Takeover: The ultimate finding was the combination of these techniques with resource injection in CloudFormation templates. Leveraging a Time-of-Check Time-of-Use (TOCTOU) vulnerability, an attacker could modify a legitimate CloudFormation template after it has been checked by the service but before it is deployed. By injecting malicious resources—specifically, an IAM role configured for assumption by an external attacker account—the attacker could achieve a full remote account takeover, gaining an admin role on the victim's AWS account. This represents the most severe impact of the discovered vulnerabilities.

Technical Deep Dive

▶ Watch: First vulnerability: CloudFormation S3 bucket naming (4:45)

The technical foundation of these vulnerabilities lies in the intricate process of how AWS CloudFormation handles template uploads and the naming conventions of automatically generated S3 buckets.

When a user interacts with the AWS Management Console to upload a CloudFormation template file, several API requests are invoked behind the scenes. First, a create upload bucket API request is made by the CloudFormation service. This action attempts to provision a new S3 bucket if one doesn't already exist for that specific CloudFormation context in the chosen region. Upon successful creation, the service returns the bucket name. Subsequently, a put object API request uploads the user's template file to this newly created S3 bucket. Finally, the user submits the stack, triggering CloudFormation to deploy the resources defined in the template.

The critical aspect here is the bucket naming pattern for these CloudFormation-generated S3 buckets: CF template-<hash>-<region>.

• CF template: This is a constant prefix, consistently used across all such buckets.
• <hash>: This is a unique identifier generated per AWS account. Initially, it appears to be a random string, making the full bucket name difficult to predict for a new account.
• <region>: This corresponds to the AWS region where the CloudFormation stack is initiated.

The attack capitalizes on the global uniqueness of S3 bucket names. An attacker can attempt to pre-register a bucket name that they predict or discover for a target account. This means the attacker creates an S3 bucket with the exact name CF template-<hash>-<region> in their own AWS account before the legitimate user attempts to use CloudFormation in that specific region. To make this pre-registered bucket exploitable, the attacker must configure it with two crucial settings:

1. Public Access: By default, S3 buckets block public access. The attacker must explicitly disable this block and allow public access to the bucket.
2. Permissive Resource-Based Policy: The attacker then applies a highly permissive bucket policy (an IAM policy attached directly to the S3 bucket). A proof-of-concept (PoC) policy might grant s3: permissions to (any principal on AWS), allowing any AWS account to perform any S3 action on the attacker's bucket. In a more refined attack, the policy might specifically allow s3:PutObject from any principal, enabling victims to upload files into the attacker-controlled bucket.

Once the attacker has pre-registered and configured the bucket, when the legitimate user attempts to upload a CloudFormation template, the create upload bucket API call will fail for the victim because the name is already taken. However, if the attacker's bucket is configured to accept objects from external accounts (via the permissive policy), the put object API request from the victim's CloudFormation service might still succeed in uploading the template to the attacker-controlled bucket.

This leads directly to the Resource Injection technique, which leverages a Time-of-Check Time-of-Use (TOCTOU) vulnerability. This technique, previously published by Rhino Lab and credited to Matthew Filler, exploits a window of opportunity. CloudFormation typically performs validations on a template (the "check" phase) before it proceeds to deploy resources (the "use" phase). If the attacker can gain control over the S3 bucket where the template is stored, they can modify the template after it has been checked by CloudFormation but before the service begins deploying the resources.

The malicious modification involves injecting an AWS Identity and Access Management (IAM) role resource into the victim's template. This injected role is configured with an AssumeRole policy that trusts the attacker's AWS account ID. For example:

When the victim's CloudFormation stack is deployed, it creates this AttackerAdminRole in the victim's account. Because the AssumeRolePolicyDocument explicitly trusts the attacker's account, the attacker can then use sts:AssumeRole from their own AWS account to gain AdministratorAccess within the victim's account, effectively achieving a full account takeover.

An interesting anecdotal "bug" mentioned by the researchers highlights the stealth of such an injection: when a user retrieves the script (template) from the AWS GUI, they might still see the original script, even though the modified (injected) script is what actually runs during deployment. This makes the attack even harder to detect from a user's perspective. The talk also briefly mentions the AWS Glue service in the context of its default service role often having significant enumeration and write potential, hinting at how an attacker might gain initial access or further escalate privileges if they land in a Glue context. More critically, the researchers state that an attacker could find the victim's account ID in CloudWatch logs related to the Glue service, providing another path to discovering the necessary account ID for crafting targeted bucket names or AssumeRole policies.

Demo / Proof of Concept

▶ Watch: Explaining the predictable bucket naming pattern in detail (5:30)

While the full demonstration of the "Bucket Monopoly" technique was not detailed in the provided transcript segment, the general Proof of Concept (PoC) for the CloudFormation resource injection attack can be inferred from the technical explanation. The attack sequence would typically unfold as follows:

1. Attacker Reconnaissance: The attacker first identifies a target AWS account. This could involve finding their CF template-<hash>-<region> bucket name through open-source intelligence (e.g., GitHub, SourceGraph) or discovering an account ID directly used in another service's S3 bucket name.
2. Bucket Pre-registration: The attacker then creates an S3 bucket in their own AWS account with the exact name (e.g., CF template-<hash>-<region> or some-service-<account-id>-<region>) corresponding to the target victim.
3. Permissive Configuration: The attacker configures this newly created S3 bucket to allow public access and applies a highly permissive resource-based policy. This policy would grant s3:PutObject permissions to any AWS principal, effectively allowing the victim's CloudFormation service to upload templates to the attacker's bucket.
4. Victim Interaction: The victim, unaware of the pre-registered bucket, attempts to use the AWS CloudFormation service to upload and deploy a legitimate template.
5. Template Redirection and Injection: When the victim's CloudFormation service tries to create an S3 bucket for the template, it fails because the name is already taken by the attacker. However, due to the permissive policy on the attacker's bucket, the subsequent s3:PutObject request from the victim's CloudFormation service successfully uploads the template to the attacker-controlled bucket. At this point, the attacker has a brief Time-of-Check Time-of-Use (TOCTOU) window.
6. Malicious Modification: The attacker quickly modifies the uploaded template in their S3 bucket, injecting a malicious IAM role resource. This role, named something like AdminRoleForAttacker, would have an AssumeRolePolicyDocument that trusts the attacker's AWS account ID and grants AdministratorAccess.
7. Victim's Deployment: The victim proceeds to deploy the CloudFormation stack. Unbeknownst to them, CloudFormation now processes the modified template from the attacker's bucket.
8. Account Takeover: The CloudFormation service successfully creates the AdminRoleForAttacker in the victim's AWS account. The attacker, from their own AWS account, can then use the sts:AssumeRole API call to assume this newly created role, gaining full administrative control over the victim's AWS environment.

The mention of "Bucket Monopoly" as a technique to "emphasize the risk of our findings" suggests a broader strategy beyond a single bucket takeover, possibly involving controlling multiple such shadow resources or using the uniqueness property to block legitimate operations. However, the specifics of this technique were not elaborated upon in the provided transcript.

Defensive Implications

▶ Watch: Visualizing cross-region predictable bucket pattern (6:00)

The vulnerabilities highlighted by Aqua Security's research underscore several critical areas where AWS users and security teams must strengthen their defenses.

1. Treat AWS Account IDs with Caution: Despite AWS's stance that account IDs are not secrets, this research demonstrates their utility for attackers in crafting targeted attacks and facilitating cross-account compromise. Organizations should adopt a "security by obscurity is not security, but obscurity can help" mindset. Minimize exposure of account IDs where possible, and never assume they cannot be known by an adversary.
2. Implement Strict S3 Bucket Policies:

• Block Public Access by Default: Ensure that the "Block Public Access" settings are enabled at both the account and bucket levels for all S3 buckets unless absolutely necessary and thoroughly reviewed.
• Restrict Cross-Account Access: Avoid overly permissive resource-based policies that allow s3:PutObject or s3: actions from (any principal). Carefully scope cross-account access to only trusted accounts and specific, required actions. Regularly audit S3 bucket policies for misconfigurations.

1. Monitor for Unusual S3 Bucket Creation and Access Patterns:

• CloudTrail Monitoring: Implement robust CloudTrail logging and monitoring for S3 bucket creation (CreateBucket) and policy changes (PutBucketPolicy). Alert on any unexpected bucket names matching patterns like CF template-<hash>-<region> or those containing known account IDs, especially if they are not initiated by authorized processes.
• Access Logging: Enable S3 access logging to track who is accessing your buckets and from where.

1. Secure CloudFormation Template Management:

• Source Control and Review: Store CloudFormation templates in secure, version-controlled repositories. Implement mandatory code reviews and security scanning for all templates before deployment to detect malicious injections or misconfigurations.
• Least Privilege for Execution Roles: Ensure that the IAM roles used by CloudFormation to deploy stacks operate with the principle of least privilege. They should only have permissions to create and manage the specific resources defined in the legitimate templates, not arbitrary actions or the ability to create new IAM roles with broad permissions.
• Template Scanning: Utilize automated tools to scan CloudFormation templates for common vulnerabilities, misconfigurations, and suspicious resource definitions (e.g., IAM roles with external trust relationships).

1. Address Time-of-Check Time-of-Use (TOCTOU) Vulnerabilities: While difficult to prevent entirely, understanding the TOCTOU window is crucial. Implement mechanisms to ensure the integrity of templates between validation and deployment. For example, using cryptographic hashes to verify that the deployed template matches the validated template, or deploying from immutable artifacts generated during a secure build process.
2. Leverage the Researchers' Open-Source Tool: The researchers developed an open-source tool to help identify these vulnerabilities. Organizations should integrate such tools into their security pipelines to proactively scan for exposed CF template-<hash>-<region> buckets or other shadow resources that might leak account IDs or be susceptible to pre-registration.
3. Regular Security Audits and Penetration Testing: Conduct regular security audits and penetration tests focusing on IaC configurations, S3 bucket policies, and cross-account access to uncover similar "shadow resource" vulnerabilities before attackers do.

Key Takeaways

• AWS Account IDs are valuable to attackers: While not classified as secrets by AWS, their exposure significantly aids attackers in reconnaissance and crafting targeted attacks, making careful handling essential.
• Shadow Resources pose significant risks: Automatically generated AWS resources, like CloudFormation S3 buckets, can go unnoticed by account owners but present critical attack surfaces if misconfigured or exploited.
• Bucket pre-registration is a potent attack vector: Attackers can claim predictable S3 bucket names before legitimate users, then configure them maliciously to intercept or modify data.
• Open-source intelligence (OSINT) bypasses hash randomization: Even with randomized bucket name components, attackers can find existing vulnerable buckets by searching public code repositories and logs.
• Resource injection via TOCTOU leads to account takeover: By combining control over template storage with a Time-of-Check Time-of-Use vulnerability, attackers can inject malicious IAM roles and achieve full administrative control over a victim's AWS account.
• Proactive defense is crucial: Implementing strict S3 policies, monitoring for unusual resource creation, securing CloudFormation template workflows, and utilizing specialized scanning tools are vital to mitigate these sophisticated cloud attacks.

About the Speaker(s)

Yakir Kadkoda, Michael Katchinskiy, and Ofek Itach are security researchers at Aqua Security. Their daily work focuses on identifying and analyzing vulnerabilities within cloud environments, open-source software, and related technologies. Their expertise lies in uncovering novel attack techniques and developing practical solutions to enhance cloud security postures. This presentation at DEF CON 32 exemplifies their commitment to sharing critical research and contributing to the broader cybersecurity community.