AWS Vulnerability: Users At Risk Of Account Takeover Attacks

As per recent reports, cybersecurity researchers have recently uncovered an AWS vulnerability in the Cloud Development Kit (CDK). This vulnerability if exploited could result in account takeover attacks under certain scenarios. In this article, we’ll dive into the details of a possible exploit, initial discovery, and more. Let’s begin! 

AWS Vulnerability: Initial Discovery And Details

The Amazon Web Services (AWS) CDK is an open-source software development framework used to define application resources using programming languages via CloudFormation. The programming languages that are used include:  

• Python.
• TypeScript.
• JavaScript. 

Before diving into more details, it’s worth noting that the problem was identified by Aqua, a cloud security firm, based on their prior findings. Those findings detailed shadow resources in AWS. In addition, they also shed light on how predefined naming conventions for AWS Simple Storage Service (S3) buckets be weaponized. 

The prevalence of such a scenario would allow threat actors to orchestrate Bucket Monopoly attacks, and if successful, such attacks would help gain access to sensitive information. As far as the AWS vulnerability in the CDK is concerned, it’s important to know that such environments can be created via bootstrapping.

During the bootstrapping process, various AWS resources are provisioned to the environment. These resources include:  

• An AWS S3 bucket.
• Amazon Elastic Container Registry (Amazon ECR) repository.
• AWS Identity and Access Management (IAM) roles.

S3 Bucket Naming Security Risk 

To fully comprehend the AWS vulnerability, individuals must know that some of the IAM roles created as part of the bootstrapping process grant different types of permission. These permissions include uploading and deleting assets associated with the S3 buckets. In addition, they may also include permission stack deployment with administrative access. 

Cybersecurity experts have stated that the naming pattern of the IAM roles that are created by AWS CDK follows the same structure:

“cdk-{Qualifier}-{Description}-{Account-ID}-{Region}”

The details of each field within this structure are mentioned below:  

In addition, the S3 bucket that is created during the bootstrapping process follows the naming pattern:

“cdk-{Qualifier}-assets-{Account-ID}-{Region}.”

Providing further insight pertaining to this AWS vulnerability, Aqua stated that:  

“Since many users run the cdk bootstrap command 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 to ‘hnb659fds,’ making it easier to anticipate the bucket’s name.”

It’s worth mentioning that multiple instances that were discovered on GitHub were using the default qualifier. What this means for threat actors is that guessing a bucket’s name is as simple as determining the AWS account ID and the region to which the CDK is deployed. 

This AWS vulnerability allows threat actors to orchestrate S3 Bucket Name Squatting. This technique, also referred to as Bucket Sniping, ensures that hackers are about to successfully exploit the AWS vulnerability as it allows them to claim another user’s CDK bucket.

Consequences Of The AWS Vulnerability Exploit

As far as the consequences of a possible exploit are concerned, this AWS vulnerability paves the way for a partial denial-of-service (DoS). This happens when a user attempts to bootstrap the CDK with the same account ID and region. 

The intensity of the consequences of the AWS vulnerability increases when the compromised CDK has permission to read and write data from and to the S3 bucket controlled by the attacker.

Such privileges would allow a threat actor to make it possible to tamper with CloudFormation templates. This would entail that hackers can conduct malicious actions within the compromised account. Commenting on CloudFormation templates, experts have stated that:  

“The deploy role of the CloudFormation service, which is the role CloudFormationExecutionRole in CDK, has administrative privileges within the account by default. 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.”

AWS Account Takeover Vulnerability Attack Chain 

As far as the attack chain for this AWS vulnerability is concerned, the threat actor would need to create a bucket with a name that matches that had already existed. For this, users would have to initiate the CDK bootstrap process and subsequently delete the S3 bucket. This would be the asset used to initiate the AWS vulnerability exploit. 

The creation of a duplicate bucket would cause the CDK to trust it, ensuring that threat actors can have CloudFormation templates written to it. But, there are certain prerequisites that a hacker must meet for this to succeed. These include:  

• • Claiming the bucket with the predictable name and allowing public access

• Creating a Lambda function to inject a malicious admin role or backdoor into a given CloudFormation template file. 

Once all these conditions are fulfilled, the AWS vulnerability hacker can take complete control of the targeted account. However, for this to happen, the user must deploy the CDK using “cdk deploy.” Doing so would send the template to the duplicate bucket that was created by the hacker during the initial stage of the attack. 

In addition, it would also inject an admin role used for acquiring control. It’s worth noting that the admin role would be injected using the attacker’s Lambda function. This function would backdoor the CloudFormation template file written but the victim’s CKD to the compromised S3 bucket. 

Once this chain of events is complete, the victim’s account will read and deploy resources from the attacker’s bucket, allowing the hacker to create a new admin role. Providing insights into this attack methodology, cybersecurity experts have stated that: 

“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. However, we should consider the likelihood of someone deleting the CDK S3 bucket after it has been bootstrapped.”

Security Protocols Mitigating Risk 

Given the possible aftermath of this AWS vulnerability being exploited, learning about security measures that can be adopted to mitigate risk is essential. These security protocols include: 

• Updating to CDK version CDK version v2.149.0 as it comes with enhanced security measures that dictate that only S3 buckets within the user’s account are trusted. This keeps the CDK from pushing data to a bucket not owned by the user account. 
• Using a custom qualifier instead of the default “hnb659fds” by customizing bootstrapping resources as mentioned in the updated AWS documentation. 

It’s worth mentioning that users who bootstrapped with an older version may still be at risk of falling prey to the AWS vulnerability exploit. To mitigate the risk such users should upgrade to version v2.149.0 or later and re-run the “cdk bootstrap” command. As an alternative such user can also apply an IAM policy that’s similar to the AWS patch. 

결론 

This AWS vulnerability highlights the importance of maintaining secure configurations and up-to-date software versions. By following recommended protocols such as updating to CDK version v2.149.0 and customizing default settings users can significantly reduce the risk of account takeover attacks and protect sensitive AWS resources. Such vulnerability and possible attack scenarios now dictate the use of proactive cybersecurity measures that can help mitigate risk and improve security posture. 

The sources for this piece include articles in The Hacker News and Aqua.