Exposed Vulnerability in AWS Cloud Development Kit Puts Users at Risk of Potential Account Takeover
A security loophole in the Amazon Web Services (AWS) Cloud Development Kit (CDK) has been uncovered by cybersecurity researchers, posing a risk of potential account takeover under specific conditions.
A report by Aqua disclosed that in particular scenarios, an attacker could exploit this issue to gain administrative control over a targeted AWS account.
The security flaw was promptly addressed by the CDK project maintainers in the release of CDK version 2.149.0 in July, following responsible disclosure on June 27, 2024.
AWS Cloud Development Kit (CDK) is a framework for defining cloud application resources and provisioning them through CloudFormation, supporting Python, TypeScript, or JavaScript.
The vulnerability identified by Aqua builds on previous findings by the cloud security firm regarding shadow resources in AWS, focusing on predefined naming conventions of AWS Simple Storage Service (S3) buckets that could be exploited in Bucket Monopoly attacks for unauthorized data access.
The setup of AWS environment for CDK usage involves bootstrapping, where essential AWS resources like an S3 bucket, Amazon Elastic Container Registry (Amazon ECR) repository, and AWS Identity and Access Management (IAM) roles are provisioned.
As per the AWS documentation, resources and configurations utilized by the CDK are defined in an AWS CloudFormation template.
To initialize an environment, the AWS CDK Command Line Interface (AWS CDK CLI) uses the “cdk bootstrap” command to deploy the template to AWS CloudFormation as a stack, known as the bootstrap stack with a default name of “CDKToolkit.”
During the bootstrapping process, certain IAM roles are generated to allow uploading and deleting assets from the S3 bucket and conducting stack deployments with administrator privileges.
Aqua highlighted the IAM roles naming convention used by AWS CDK, comprising the structure “cdk-{Qualifier}-{Description}-{Account-ID}-{Region}.”
- The Qualifier is a unique, defaulting to “hnb659fds” and can be customized
- Description defines the resource (e.g., cfn-exec-role)
- Account-ID is the environment’s AWS account ID
- Region indicates the AWS environment region
Similarly, the S3 bucket naming format during bootstrapping is “cdk-{Qualifier}-assets-{Account-ID}-{Region}.”
Due to many users using the default qualifier, Aqua noted the predictability of the S3 bucket naming, as the default qualifier value “hnb659fds” simplifies guessing the bucket’s name.
With numerous instances identified on GitHub utilizing the default qualifier, determining the bucket’s name becomes trivial by discovering the AWS Account ID and region.
Moreover, as S3 bucket names are globally unique among AWS accounts, this exposes a vulnerability allowing for S3 Bucket Namesquatting (Bucket Sniping) by seizing another user’s CDK bucket if available.
This scenario could lead to a partial denial-of-service (DoS) when bootstrapping the CDK with the same account ID and region, solvable by specifying a custom qualifier.
A potential risk arises when the victim’s CDK can read and write data from the attacker’s S3 bucket, enabling manipulations in CloudFormation templates and executing malicious operations within the victim’s AWS account.
Aqua highlighted that the CloudFormation service’s deploy role (CloudFormationExecutionRole) possesses administrative rights by default.
This implies any CloudFormation template written to the attacker’s S3 bucket by the victim’s CDK could later be deployed with administrative privileges in the victim’s account, enabling the creation of privileged resources by the attacker.
In a hypothetical attack, if a user had previously bootstrapped the CDK and later deleted the S3 bucket, an adversary could recreate the bucket with the same name to exploit the CDK’s implicit trust towards the bucket.
This manipulation could potentially allow the attacker to inject malicious elements into CloudFormation templates, posing a security threat. The attacker must fulfill certain prerequisites for this attack to succeed.
- Acquire the bucket with a predictable name and enable public access
- Create a Lambda function to insert a malicious admin role or backdoor into the CloudFormation template upon upload to the bucket
Upon deploying the CDK using “cdk deploy,” the process sends the template to the target bucket, along with potential an administrator role that the intruder can adopt to ultimately seize control of the target’s account.
In different terms, the sequence of attacks enables the establishment of an administrator role in a targeted AWS account when a CDK S3 bucket configured during the initialization process is removed and the CDK is redeployed. AWS has confirmed that about 1% of CDK users were exposed to this attack vector.
The solution implemented by AWS guarantees that resources are solely uploaded to buckets within the user’s account to prevent the CDK from transmitting data to buckets not under the ownership of the launching account. It has also recommended customers to utilize a custom qualifier instead of the default “hnb659fds.”
According to a statement shared with The Hacker News, AWS reassured that all concerns concerning unauthorized data exposure during CDK deployments have been thoroughly investigated and resolved.
“On July 12, 2024, AWS introduced an update to the AWS Cloud Development Kit (AWS CDK) CLI that introduced additional security measures to counteract the possibility of data leakage for customers executing CDK deployments,” an AWS representative informed the publication.
“Users on the latest version will be required to carry out a one-time update to their bootstrap resources. AWS has directly contacted potentially impacted customers to notify them of the need for an upgrade, and has added extra checks to the CLI to prompt users to proceed with the update.”
Consequently, user intervention is necessary if the initialization was done using CDK version v2.148.1 or earlier, mandating them to upgrade the CDK to the most recent version and rerun the bootstrap directive. Alternatively, users can choose to apply an IAM policy clause to the FilePublishingRole CDK role.
These discoveries once again underscore the importance of safeguarding AWS account IDs, establishing a scoped IAM directive, and refraining from assigning predictable names to S3 buckets.
“Instead, produce unique hashes or random identifiers per region and account, and integrate them into your S3 bucket names,” Aqua concluded. “This approach helps guard against adversaries preemptively taking possession of your bucket.”
The revelation coincides with Symantec, a subsidiary of Broadcom, discovering several Android and iOS applications that embed and expose cloud service credentials for AWS and Microsoft Azure Blob Storage, placing user information at jeopardy.
Among the implicated applications are Pic Stitch: Collage Maker, Crumbl, Eureka: Earn Money for Surveys, Videoshop – Video Editor, Meru Cabs, Sulekha Business, and ReSound Tinnitus Relief.
“This risky practice implies that anyone with access to the app’s binary or source code could potentially extract these credentials and misuse them to tamper with or steal data, leading to severe security breaches,” security analysts Yuanjing Guo and Tommy Dong noted.
(The narrative was adjusted post-publication to incorporate a response from AWS.)
About Author
