A new vulnerability discovered in AWS Cloud Development Kit (CDK) by security firm Aqua could lead to an attacker fully taking over a target AWS account due to the manual deletion of artifact S3 buckets. While AWS fixed the vulnerability, you are still required to take action if you have used CDK version v2.148.1 or earlier.
The AWS Cloud Development Kit (CDK) is an IaC tool that allows developers to define cloud infrastructure using Python, TypeScript, or JavaScript.
At the root of its vulnerability, explain Aqua security researchers Ofek Itach and Yakir Kadkoda, lies the use of an easily predictable S3 bucket name to store files required by CDK to bootstrap the process of creating AWS infrastructure based on the user's requirements. Those files, including several IAM roles, policies, and more, are all stored in the same S3 bucket named following the pattern cdk-{Qualifier}-{Description}-{Account-ID}-{Region}.
Actually, the user can specify the Qualifier to use when running CDK, but:
Since many users run the
cdk bootstrapcommand without customizing the qualifier, the S3 bucket naming pattern of the staging bucket becomes predictable. This is because the default value for the bucket name qualifier is set tohnb659fds, making it easier to anticipate the bucket’s name.
Knowing this, say the researchers, an attacker could create ahead of time the S3 bucket CDK bootstrap would use for a given account, thus causing an error in case the legitimate account owner would attempt to use CDK bootstrap.
This is in itself a kind of denial of service (DoS) attack, but worse, it could lead to a complete account takeover. In fact, if the compromised S3 bucket is used both to read and write, an attacker could, for example, inject an admin role:
The CDK staging bucket contains CloudFormation templates. If an attacker gains access to the CDK staging bucket of other users, these files can be easily tampered with and backdoored, enabling the injection of malicious resources into the victim’s account during deployment.
This scenario is enabled, specifically, by the user deleting the CDK S3 bucket after bootstrapping it, for example, to reduce the number of used buckets. As the researchers detail in their article, an attacker might "hijack" a released CDK S3 bucket and set up privileges and mechanisms to intercept any future attempt to run cdk bootstrap/cdk deploy on the owner's part.
Essentially, we were able to create an admin role in a target account if someone deletes the CDK staging S3 bucket that was created during the bootstrap process and then tries to use CDK again.
Based on their analysis of almost 40k accounts, the researchers estimated about 1% of CDK users to be vulnerable to this attack vector.
While AWS fixed CDK from version 2.149.0 by using stricter ownership checks and updated the documentation to highlight the importance of using custom qualifiers, all users who bootstrapped CDK with any previous versions will remain vulnerable even if they update their CDK. In addition to update CDK, in fact, those users will need to run the cdk bootstrap command again or define an IAM policy condition for the FilePublishingRole CDK role: cdk-${Qualifier}-file-publishing-role-${AWS::AccountId}-${AWS::Region}.
