AWS Cloud Development Kit flaw exposed accounts to full takeover

Remember Bucket Monopoly? Yeah, it gets worse

Amazon Web Services has fixed a flaw in its open source Cloud Development Kit that, under the right conditions, could allow an attacker to hijack a user's account completely.

The Cloud Development Kit (CDK) is an open source framework, developed by AWS, that allows developers to define cloud application infrastructure as code using programming languages such as Python, TypeScript, JavaScript, Go and others, and then provision these resources through AWS CloudFormation.

Bug hunters at Aqua spotted the CDK issue on June 27, according to the firm's security researchers Ofek Itach and Yakir Kadkoda. About two weeks later, the cloud giant patched the flaw with CDK version v2.149.0.

AWS confirmed that about one percent of CDK users were susceptible to this security issue, and assured The Register that it "investigated and resolved all reported concerns." In an emailed statement, an AWS spokesperson wrote that the business unit appreciated Aqua's work in reporting the flaw and collaborating with AWS, and added:

On July 12, 2024, AWS released an update to the AWS Cloud Development Kit (AWS CDK) CLI that implemented additional security controls to mitigate the potential for data disclosure for customers performing CDK deployments. Customers using the latest version will need to perform a one-time action to upgrade their bootstrap resources. AWS has reached out to potentially affected customers directly to notify them of the need to upgrade, and has added additional checks to the CLI to remind users to upgrade.

The security problem is related to an earlier attack method dubbed "Bucket Monopoly" – also identified by Aqua – in which criminals could predict AWS S3 bucket names, pre-load malicious code into a bucket, and then sit back and wait for the target org to execute it unwittingly.

Once that happened, the attackers could steal data, or even take over a user's account without them knowing.

The newer issue also involves these S3 buckets, the predictable nature of their names, and attackers abusing this predictability via S3 Bucket Namesquatting.

Prior to deploying any apps, CDK requires users to bootstrap their environment. This automatically creates needed infrastructure components including identity and access management (IAM) roles, permissions and policies, and an S3 staging bucket.

As with the earlier Bucket Monopoly problems, these CDK staging buckets follow a set naming mechanism – "cdk-{Qualifier}-{Description}-{Account-ID}-{Region}" – that makes them easy to predict as long as you know their AWS Account-ID and the region where the CDK was deployed. The Aqua duo noted:

Since the Prefix is always cdk, the Qualifier is by default hnb659fds, and assets is a constant string in the bucket name, the only variables that change are the Account ID and the Region.

And, it turns out, there are thousands of instances in which the default qualifier is used during the bootstrap process. That makes it that much easier to claim another user's CDK staging bucket name, and then perform all the evil deeds detailed in the Bucket Monopoly attack overview.

In certain scenarios, the CDK issue could "allow an attacker to gain administrative access to a target AWS account, resulting in a full account takeover," Itach and Kadkoda wrote.

All of these users have since been notified by AWS. As part of its fix, AWS now ensures that assets are only uploaded to buckets within the user's account – thus preventing the use of any data that's not owned by the account that initiated the bootstrapping process.

However, even with the updated version, user action is required if you've ever bootstrapped with an older version: CDK version 2.148.1 (July 11, 2024) or earlier. To mitigate this risk, here's what Aqua suggests:

If you're using CDK version v2.148.1 or earlier, upgrade to version v2.149.0 or later. After upgrading, re-run the cdk bootstrap command.

Alternatively, instead of upgrading the CDK version, you can apply an IAM policy condition to the FilePublishingRole CDK role: cdk-${Qualifier}-file-publishing-role-${AWS::AccountId}-${AWS::Region}, similar to the AWS patch.

Plus, as the duo suggested in their earlier research, don't use predictable S3 bucket names, or risk having an attacker namesquat your bucket. "Instead, generate unique hashes or random identifiers per region and account, and incorporate them into your S3 bucket names." ®