Cybersecurity researchers have discovered a security flaw affecting the Amazon Web Services (AWS) Cloud Development Kit (CDK) that could lead to account hijacking under certain circumstances.
“The impact of this issue could, in certain scenarios, allow an attacker to gain administrative access to a target AWS account, leading to full account takeover,” Aqua said in the report shared with The Hacker News.
After responsible disclosure on June 27, 2024, the issue was reviewed by project support specialists at 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 through CloudFormation.
The problem discovered by Aqua is based on preliminary findings from a cloud security firm about shadow resources in AWS and how predefined naming conventions for AWS Simple Storage Service (S3) buckets can be used to orchestrate Bucket Monopoly attacks and gain access to sensitive data.
Preparing an AWS environment for use with the AWS Cloud Development Kit (AWS CDK) is done through a process called initialization, in which certain AWS resources are provisioned to the environment. This includes AWS S3 bucket, Amazon Elastic Container Registry (Amazon ECR) repository, and AWS Identity and Access Management (IAM) roles.
“The resources and their configuration used by the CDK are defined in the AWS CloudFormation template,” it said. AWS documentation.
“To boot the environment, you use the cdk bootstrap command of the AWS CDK Command Line Interface (AWS CDK CLI). The CDK CLI retrieves the template and deploys it to AWS CloudFormation as a stack known as a boot stack. The default stack name is CDKToolkit.”
Some of IAM roles created as part of the initial boot process, give permission to load and remove assets from the associated S3 bucket, and to perform stack deployments with administrative access.
Aqua said that the naming pattern for IAM roles created by AWS CDK follows the structure “cdk-{Qualifier}-{Description}-{Account ID}-{Region}” where each field is explained below –
- Qualifier, a unique nine-character string value that defaults to “hnb659fds”, although this can be configured during the boot phase
- Description, description of the resource (eg cfn-exec-role)
- Account ID The account ID of the AWS environment
- Region, AMS region environment
Similarly, the S3 bucket created during upload follows the naming pattern “cdk-{Qualifier}-assets-{Account-ID}-{Region}”.
“Since many users run the cdk bootstrap command without setting the qualifier, the S3 container naming pattern for the staging block becomes predictable,” Aqua said. “This is because the default value for the bucket name qualifier is set to ‘hnb659fds’, which makes predicting the bucket name easier.”
with thousands of copies discovered on GitHub using the default qualifier, this also means that guessing the name of the bucket is as easy as looking up the AWS account ID and the region in which the CDK is deployed.
Couple this aspect with the fact that S3 bucket names are globally unique across AWS accounts, and the loophole opens the door to what is called S3 Bucket Namesquatting (or Bucket Sniping), allowing an attacker to take over another user’s CDK if it doesn’t already exist.
This can then open the way for a partial denial of service (DoS) if a user tries to load a CDK with the same account ID and region, a scenario that can be resolved by specifying a custom qualifier at boot time.
More serious consequences can occur if the victim’s CDK has permission to both read and write data from and to an attacker-controlled S3 bucket, making it possible to spoof CloudFormation templates and perform malicious actions on the victim’s AWS account.
“The CloudFormation service deployment role, which is the CloudFormationExecutionRole in the CDK, has administrative privileges on the account by default,” Aqua noted.
“This means that any CloudFormation template written by the victim’s CDK to the attacker’s S3 bucket will be deployed later with admin rights in the victim’s account. This would allow an attacker to create privileged resources.”
In a hypothetical attack where a user initiated a CDK download process in the past and subsequently deleted an S3 bucket due to quota constraints, 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 fake bucket and read/write CloudFormation templates to it, making them susceptible to exploitation. However, for this to succeed, the attacker must fulfill the following conditions −
Claim a bucket with a predictable name and allow public access
Create a Lambda function that will inject a malicious admin role or backdoor into a specified CloudFormation template file every time it is uploaded to the bucket
In the final step, when the user deploys the CDK using “cdk deploy”, the process not only sends the template to the replica bucket, but also introduces an admin role that the attacker can assume to eventually gain control of the victim’s account.
In other words, the attack chain facilitates the creation of an administrator role on the target AWS account when the S3 CDK created during the boot 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.
A fix introduced by AWS ensures that assets are only uploaded to buckets in the user’s account, so that the CDK does not move data to buckets that do not belong to the account that initiated the upload. This too urged customers to use a special qualifier instead of the standard “hnb659fds.”
However, user action is required if the initial boot was performed using CDK version v2.148.1 or earlier, which requires updating the CDK to the latest version and re-running the bootstrap command. Alternatively, users can apply an IAM policy condition to the FilePublishingRole CDK role.
The findings again call for keeping AWS account IDs secret, defining IAM policies with scope, and avoiding assigning predictable names to S3 buckets.
“Instead, generate unique hashes or random IDs for each region and account and include them in your S3 cache names,” Aqua concluded. “This strategy helps protect against attackers preemptively hijacking your bucket.”
The disclosure comes after Broadcom-owned Symantec found several Android and iOS apps with hard-coded and unencrypted cloud service credentials for AWS and Microsoft Azure Blob Storage. user data is at risk.
Pic Stitch offending apps include: 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 program’s binary or source code can potentially obtain these credentials and abuse them to manipulate or steal data, leading to serious security breaches,” security researchers Yuanjing Guo and Tommy Dong said.
