Cybersecurity researchers have disclosed a security flaw impacting Amazon Web Services (AWS) Cloud Development Kit (CDK) that could have resulted in an account takeover under specific circumstances.
“The impact of this issue could, in certain scenarios, allow an attacker to gain administrative access to a target AWS account, resulting in a full account takeover,” Aqua said in a report shared with The Hacker News.
Following responsible disclosure on June 27, 2024, the issue was addressed by the project maintainers in CDK version 2.149.0 released in July.
AWS CDK is an open-source software development framework for defining cloud application resources using Python, TypeScript, or JavaScript and provisioning them via CloudFormation.
The problem identified by Aqua builds upon prior findings from the cloud security firm about shadow resources in AWS, and how predefined naming conventions for AWS Simple Storage Service (S3) buckets could be weaponized to orchestrate Bucket Monopoly attacks and gain access to sensitive data.
Preparing an AWS environment for usage with the AWS Cloud Development Kit (AWS CDK) is accomplished by a process called bootstrapping, wherein certain AWS resources are provisioned to the environment. This includes an AWS S3 bucket, Amazon Elastic Container Registry (Amazon ECR) repository, and AWS Identity and Access Management (IAM) roles.
“Resources and their configuration that are used by the CDK are defined in an AWS CloudFormation template,” according to AWS documentation.
“To bootstrap an environment, you use the AWS CDK Command Line Interface (AWS CDK CLI) cdk bootstrap command. The CDK CLI retrieves the template and deploys it to AWS CloudFormation as a stack, known as the bootstrap stack. By default, the stack name is CDKToolkit.”
Some of the IAM roles created as part of the bootstrapping process grant permission to upload and delete assets from the associated S3 bucket, as well as perform stack deployments with administrator access.
Aqua said the naming pattern of the IAM roles created by AWS CDK follows the structure “cdk-{Qualifier}-{Description}-{Account-ID}-{Region},” where each of the fields are explained below –
- Qualifier, a unique, nine-character string value that defaults to “hnb659fds” although it can be customized during the bootstrapping phase
- Description, resource description (e.g., cfn-exec-role)
- Account-ID, AWS account ID of the environment
- Region, AWS region of the environment
In a similar vein, the S3 bucket created during bootstrapping follows the naming pattern “cdk-{Qualifier}-assets-{Account-ID}-{Region}.”
“Since many users run the cdk bootstrap command without customizing the qualifier, the S3 bucket naming pattern of the staging bucket becomes predictable,” Aqua said. “This is because the default value for the bucket name qualifier is set to ‘hnb659fds,’ making it easier to anticipate the bucket’s name.”
With thousands of instances discovered on GitHub where the default qualifier is used, this also means that guessing the bucket’s name is as simple as finding the AWS Account ID and the region to which the CDK is deployed.
Combining this aspect with the fact that S3 bucket names are globally unique across all AWS accounts, the loophole opens the door for what’s called S3 Bucket Namesquatting (or Bucket Sniping), allowing an attacker to claim another user’s CDK bucket if it doesn’t exist already.
This could then pave the way for a partial denial-of-service (DoS) when a user attempts to bootstrap the CDK with the same account ID and region, a scenario that could be resolved by specifying a custom qualifier during bootstrapping.
A more serious consequence could occur if the victim’s CDK has permission to both read and write data from and to the attacker-controlled S3 bucket, thereby making it possible to tamper with CloudFormation templates and execute malicious actions within the victim’s AWS account.
“The deploy role of the CloudFormation service, which is the role CloudFormationExecutionRole in CDK, has administrative privileges within the account by default,” Aqua pointed out.
“This means that any CloudFormation template written to the attacker’s S3 bucket by the victim’s CDK would be deployed later with administrative privileges in the victim’s account. This would allow the attacker to create privileged resources.”
In a hypothetical attack, should a user have initiated the CDK bootstrap process in the past and subsequently deleted the S3 bucket due to quota limits, an adversary could take advantage of the situation to create a bucket with the same name.
This could then cause the CDK to implicitly trust the rogue bucket and read/write CloudFormation templates to it, making them susceptible to exploitation. However, for this to succeed, the attacker is expected to fulfil the below prerequisites –
Claim the bucket with the predictable name and allow public access
Create a Lambda function that will inject a malicious admin role or backdoor into a given CloudFormation template file whenever it’s uploaded to the bucket
In the final stage, when the user deploys the CDK using “cdk deploy,” not only does the process send the template to the replica bucket, but also inject an admin role that the attacker can assume to ultimately gain control of the victim’s account.
Put differently, the attack chain facilitates the creation of an admin role in a target AWS account when a CDK S3 bucket set up during the bootstrap process is deleted and the CDK is used again. AWS has since confirmed that approximately 1% of CDK users were vulnerable to the attack vector.
The fix put in place by AWS ensures that assets are only uploaded to buckets within the user’s account so as to prevent the CDK from pushing data to buckets not owned by the account that launched the bootstrapping. It has also urged customers to use a bespoke qualifier instead of the default “hnb659fds.”
That said, user action is required if bootstrapping was carried out using CDK version v2.148.1 or earlier, necessitating that they update the CDK to the latest version and re-run the bootstrap command. Alternatively, users have the option of applying an IAM policy condition to the FilePublishingRole CDK role.
The findings once again call for keeping AWS account IDs a secret, defining a scoped IAM policy, and avoiding giving predictable names to S3 buckets.
“Instead, generate unique hashes or random identifiers per region and account, and incorporate them into your S3 bucket names,” Aqua concluded. “This strategy helps protect against attackers preemptively claiming your bucket.”
The disclosure comes as Broadcom-owned Symantec found several Android and iOS apps that hard-coded and unencrypted cloud service credentials for AWS and Microsoft Azure Blob Storage, putting user data at risk.
Some of the offending apps include Pic Stitch: Collage Maker, Crumbl, Eureka: Earn Money for Surveys, Videoshop – Video Editor, Meru Cabs, Sulekha Business, and ReSound Tinnitus Relief.
“This dangerous practice means that anyone with access to the app’s binary or source code could potentially extract these credentials and misuse them to manipulate or exfiltrate data, leading to severe security breaches,” security researchers Yuanjing Guo and Tommy Dong said.