AWS Cloud Development Kit Vulnerability Exposes Users to Potential Account Takeover Risks

Cybersecurity researchers have uncovered a critical security vulnerability in the Amazon Web Services (AWS) Cloud Development Kit (CDK) that could allow attackers to gain administrative access to target AWS accounts under certain conditions. The researchers from Aqua, Ofek Itach and Yakir Kadkoda, outlined the risks in a report, indicating that under specific scenarios, this flaw could lead to a full account takeover. Following responsible disclosure on June 27, 2024, AWS promptly addressed the issue with the release of CDK version 2.149.0 in July.

The AWS CDK is an open-source development framework that simplifies the process of defining and provisioning cloud resources using programming languages such as Python, TypeScript, or JavaScript. Aqua’s findings build upon previous research that highlights the potential for exploitation of "shadow resources" in AWS, particularly how naming conventions for AWS Simple Storage Service (S3) buckets could be manipulated to execute what are termed Bucket Monopoly attacks, thereby granting unauthorized access to sensitive data.

Setting up an AWS environment for use with the CDK involves a bootstrapping process that provisions several essential resources, including an S3 bucket, an Amazon Elastic Container Registry (ECR), and AWS Identity and Access Management (IAM) roles. According to AWS documentation, the resources are defined in an AWS CloudFormation template, deployed via the AWS CDK Command Line Interface using the cdk bootstrap command. The bootstrapping process allows for automatic creation of a stack named "CDKToolkit" by default.

Notably, the IAM roles generated during this bootstrapping provide permissions to upload and delete assets from the designated S3 bucket, alongside administrator stack deployment access. Aqua pointed out that the naming convention for these IAM roles usually follows a predictable format: "cdk-{Qualifier}-{Description}-{Account-ID}-{Region}." The inclusion of a default value for the qualifier ("hnb659fds") significantly reduces the complexity of predicting the names of these resources.

Due to the common practice of executing the cdk bootstrap command without any customization, Aqua highlighted that many users have S3 buckets with names that are easily guessable, facilitating S3 Bucket Namesquatting or Bucket Sniping. This allows attackers to hijack another user’s CDK bucket if it has not been previously established. Consequently, if an attacker registers a bucket with the predictable name, it could lead to partial denial-of-service when a user attempts subsequent bootstraps with the same account ID and region.

The potential for even more severe consequences arises when an attacker gains read and write access to a compromised S3 bucket. This could allow them to alter CloudFormation templates and execute malicious actions within a victim’s AWS account. Aqua also pointed out that the CloudFormationExecutionRole, which operates under administrative privileges, could enable these attackers to deploy harmful resources.

A hypothetical attack scenario suggests that if a user deletes a CDK S3 bucket after exhausting quota limits, an attacker could exploit this by creating a bucket with the same name. This tactic would allow the attacker to prevail over the CDK’s implicit trust of the rogue bucket, thereby leading to the injection of a malicious admin role into the user’s templates. For a successful attack, the perpetrator would need to claim the bucket, allow public access, and create a Lambda function to manipulate uploaded templates.

AWS confirmed that approximately 1% of CDK users were at risk from this attack vector. The fix implemented ensures that assets are loaded only into user-owned S3 buckets, preventing unauthorized access to data on non-user-controlled buckets. Users are strongly encouraged to customize the default qualifier during the bootstrapping phase.

Additionally, customers who utilized versions of the CDK prior to 2.149.0 would need to update their systems and possibly re-run the bootstrapping command to mitigate risk. Alternatively, IAM policy conditions could be applied to relevant CDK roles. In light of the vulnerability’s disclosure, AWS has taken steps to communicate with affected users regarding necessary upgrades and has enhanced CLI checks to encourage prompt updates.

The incident has highlighted the imperative of safeguarding AWS account IDs, implementing scoped IAM policies, and adopting less predictable naming conventions for S3 buckets. Aqua recommends generating unique identifiers for resources instead of relying on default values. This strategy aims to fortify defenses against attackers proactively taking control of vulnerable bucket names.

The vulnerability disclosure is set against a broader context of security concerns, including findings from Symantec, which revealed that numerous mobile applications had hard-coded AWS and Azure credentials, posing significant risks to user data safety. The identified applications had various vulnerabilities that could allow malicious entities to exploit cloud credentials, leading to severe data breaches. These findings accentuate the ongoing need for caution and robust security practices in cloud resource management.