AWS CDK Vulnerability: Missing S3 Buckets Allow Account Hijacking

A security vulnerability was discovered in the AWS Cloud Development Kit (CDK), an open-source framework that allows developers to define cloud infrastructure using familiar programming languages.

This vulnerability could, under specific circumstances, enable an attacker to gain administrative access to a target AWS account, leading to a full account takeover.

This Threatfeed delves into the nature of the vulnerability, the conditions under which it can be exploited, and the steps taken to mitigate the risk.

AWS CDK and Infrastructure as Code

Infrastructure as Code (IaC) revolutionizes the way computing infrastructure is managed and provisioned by utilizing code instead of manual configurations. It allows developers to define essential infrastructure components—such as servers, databases, and networks—through machine-readable files.

The AWS Cloud Development Kit (CDK) is a framework that enables developers to define cloud infrastructure using familiar programming languages like Python, TypeScript, or JavaScript. CDK translates this code into AWS CloudFormation templates, which AWS can interpret and deploy efficiently.

This approach streamlines the process of building and managing cloud infrastructure, allowing developers to write, customize, and deploy cloud resources directly from their codebase.

Understanding the CDK Bootstrap Process

Before deploying applications using AWS CDK, users must bootstrap their environment using the cdk bootstrap command. This process deploys a CloudFormation template that automatically creates essential infrastructure components, including:

IAM Roles and Policies: Roles like FilePublishingRole and CloudFormationExecutionRole are created. The FilePublishingRole allows CDK to interact with the bootstrapped S3 bucket for uploading and deleting assets. The CloudFormationExecutionRole grants CloudFormation permission to perform stack deployments on the user's behalf, typically with administrative privileges by default.

A staging S3 bucket is created to store deployment assets, such as CloudFormation templates and other resources. These assets are first generated and saved locally in the cdk.out directory before being uploaded to the S3 staging bucket for use during the deployment process.

Naming Conventions

The resources created during the bootstrap process follow a predictable naming pattern:

`cdk-{Qualifier}-{Description}-{Account-ID}-{Region}`

A unique, nine-character string value. By default, this is hnb659fds, but users can customize it.

A short descriptor of the resource (e.g., cfn-exec-role for CloudFormationExecutionRole).

Account-ID: The AWS account ID.

Region: The AWS Region where the CDK is deployed.

For example, the CloudFormationExecutionRole might be named:

`cdk-hnb659fds-cfn-exec-role-123456789012-us-east-1`

Exploiting Missing S3 Buckets

Predictable Bucket Names and Shadow Resources

The staging S3 bucket's name is predictable, especially when users use the default qualifier. It follows the pattern:

`cdk-{Qualifier}-assets-{Account-ID}-{Region}`

Given that many users do not customize the qualifier, using the default hnb659fds, attackers can predict the bucket name if they know the AWS Account ID and the Region.

S3 Bucket Namesquatting

Since S3 bucket names are globally unique, an attacker can perform _"S3 Bucket Namesquatting"_ or _"Bucket Sniping"_ by creating a bucket with the predicted name if it doesn't already exist. This situation can occur in two scenarios:

New CDK Users: If a user has not yet bootstrapped their CDK environment, an attacker can preemptively create the staging bucket. When the user attempts to bootstrap, the process fails due to the bucket's existence, causing a partial denial-of-service (DoS). The user can resolve this by using a custom qualifier.

Deleted Staging Buckets: If a user previously bootstrapped CDK but later manually deleted the staging S3 bucket—perhaps to free up resources—the bucket name becomes available. An attacker can then claim this bucket.

Implications of the Attack

When the user performs a cdk deploy, the CDK uses existing roles and resources, including the CloudFormationExecutionRole with administrative privileges. If the staging bucket is under the attacker's control:

The CDK uploads deployment assets, including CloudFormation templates, to the attacker's bucket.

The attacker can intercept and modify the templates, injecting malicious code or resources.

CloudFormation, using its administrative role, deploys these tampered templates in the victim's account.

The attacker can create an admin role within the victim's account, which they can assume to gain full administrative access.

Attack Workflow and Potential Impact

Pre-Attack Setup by the Attacker

1.The attacker creates the staging S3 bucket with the predictable name corresponding to the victim's account and region.

2.The attacker sets permissive policies on the bucket to allow public access and interaction.

3.A Lambda function is configured to trigger on PutObject events, designed to inject malicious resources into any uploaded CloudFormation template.

Attack Execution Steps

User Deploys CDK Application: The victim runs cdk deploy, unaware that the staging bucket is controlled by the attacker.

Asset Upload: The CDK uploads the CloudFormation template to the attacker's bucket.

Template Tampering: The attacker's Lambda function modifies the template, injecting a new admin role or other malicious resources.

Deployment of Malicious Template: CloudFormation in the victim's account retrieves and deploys the tampered template, using the CloudFormationExecutionRole with administrative privileges.

Attacker Gains Access: The newly created admin role allows the attacker to assume administrative access to the victim's AWS account.

Severity of the Impact

This vulnerability enables a complete compromise of the victim's AWS account, granting the attacker the ability to:

Access and manipulate resources.

Exfiltrate sensitive data.

Launch further attacks or exploitations.

Statistical Analysis of Affected Users

To assess the prevalence of this vulnerability, a study was conducted:

Dataset: A list of 38,560 well-known AWS Account IDs.

Regions Scanned: us-east-1, us-west-2, and eu-west-1.

Methodology:

Checked for the existence of the CloudFormationExecutionRole to confirm CDK usage.

Verified whether the corresponding staging S3 bucket existed.

Findings:

CDK Usage: 782 accounts (2%) had CDK roles, indicating CDK usage.

Vulnerable Accounts: 81 accounts (10% of CDK users) lacked the staging S3 bucket, making them susceptible to the attack.

AWS Confirmation: AWS corroborated that approximately 1% of CDK users were impacted.

Mitigation Strategies

AWS's Response

Following the disclosure, AWS implemented several fixes:

In CDK version v2.149.0, a condition was added to the FilePublishingRole to ensure it only trusts S3 buckets within the user's account.

AWS emphasized%257B1,5%257D%255Cd/&type=code) the importance of customizing bootstrapping resources and using a custom qualifier.

Direct communication with potentially affected customers.

CLI terminal messages prompting users to upgrade bootstrap resources.

Required User Actions

Despite AWS's fixes, user intervention is necessary:

Upgrade CDK:

Update to CDK version v2.149.0 or later.

Re-run the cdk bootstrap command to apply the new configurations.

Manual Role Adjustment:

If upgrading is not immediate, modify the FilePublishingRole IAM policy.

Add a condition to restrict the role to trust only S3 buckets within the user's account.

Recommendations and Best Practices

To safeguard against similar vulnerabilities, users should adopt the following practices:

Treat AWS Account IDs as Sensitive:

Avoid sharing AWS Account IDs publicly.

Recognize that knowledge of an account ID can facilitate targeted attacks.

Customize Bootstrapping Qualifier:

Always specify a custom --qualifier when running cdk bootstrap.

This reduces the predictability of resource names.

Implement IAM Policy Conditions:

Use conditions like aws:ResourceAccount in IAM policies to restrict access based on the bucket owner's AWS account ID.

Ensure that roles and policies are scoped appropriately to prevent unauthorized access.

Avoid Predictable Resource Names:

Incorporate unique identifiers or hashes into resource names, especially for globally unique services like S3.

This prevents attackers from predicting and preemptively claiming resource names.

Regularly Audit and Monitor Resources:

Periodically check for missing or inadvertently deleted resources critical for deployment processes.

Monitor logs and alerts for unusual activities during deployment.

Disclosure Timeline

27 June 2024: Security issue reported to the AWS security team.

27 June 2024: AWS acknowledged the report and initiated investigation.

11 July 2024: Pull request opened to fix the issue by adding a condition to the bootstrap FilePublishingRole.

12 July 2024: Pull request merged; fix available in CDK version v2.149.0.

09 August 2024: AWS confirmed completion of remediation efforts and updated documentation.

15 October 2024: AWS notified impacted customers.

16 October 2024: AWS added CLI terminal messages alerting users to upgrade bootstrap resources.