Critical vulnerabilities in six services under Amazon Web Services (AWS) could have enabled account takeover, remote code execution, AI data manipulation, sensitive information disclosure and more, researchers from Aqua Security disclosed at Black Hat USA on Wednesday.
The discoveries by Aqua Security’s Nautilus research team were presented in the session “Breaching AWS Accounts Through Shadow Resources” Wednesday morning at the cybersecurity conference held this year in Las Vegas. The research was presented by Lead Security Researcher Yakir Kadkoda and Senior Security Researcher Ofek Itach, of Aqua Security, and former Aqua Security Researcher Michael Katchinskiy.
[For up-to-the-minute Black Hat USA coverage by SC Media, Security Weekly and CyberRisk TV visit our spotlight Black Hat USA 2024 coverage page.]
The “Shadow Resources” attack vector, which has since been addressed by AWS, stemmed from the automatic generation of S3 buckets by various AWS services, including CloudFormation, Glue, EMR, SageMaker, ServiceCatalog and CodeStar. Users may not be aware that these buckets are being created when they start a new project or file upload, and the bucket names follow a predictable naming scheme that could be exploited by an attacker.
First discovered in the CloudFormation service and later identified in the five other services through further investigation, the Shadow Resources flaw enabled an attacker to create their own S3 bucket using the predetermined name of a bucket yet to be created by the target. For CloudFormation, auto-generated S3 buckets followed a naming format that included a service-wide fixed prefix, a unique hash that remains consistent for a given AWS account, and the region that the bucket was created from.
Therefore, if an attacker knew the target’s unique hash, they could create a bucket including the CloudFormation prefix, the hash and any of the 33 AWS regions. No two S3 buckets can have the same name across any accounts, so when the targeted user’s account attempts to create a new bucket with the name claimed by the attacker, it will result in an error – or worse.
AWS flaws allowed attackers to ‘squat’ in other users’ ‘shadow buckets’
The researchers found that, in the case of CloudFormation, attempting to upload a template file from a region where an attacker has already claimed the predicted bucket name would cause the template to be placed in the attacker’s bucket, but only if the attacker configured the bucket to allow public access and read and write permissions for the CloudFormation service.
By gaining access to the victim’s uploaded file, not only could the attacker steal potentially sensitive information stored in the template, but they could also manipulate the template to inject a backdoor, leading to potential account takeover. This could be done using a Lambda function that takes advantage of the time between initial template upload and template execution to automatically inject a backdoor as soon as the template is placed in the attacker’s bucket.
The backdoor described by the researchers is in the form of a new admin role that can later be assumed by the attacker. However, the researchers note that such a backdoor can only be created if the victim user who uploaded the template, via the AWS Management Console, has permissions to create new admin roles.
Due to the vulnerability, attackers could essentially squat in “shadow buckets” automatically created by CloudFormation and potentially unknown to the target themselves, simply waiting for the target to create a new CloudFormation stack in a new region for the first time, triggering the Lambda function and backdoor injection.
“While this process can take some time, you need to consider that in big organizations with hundreds of accounts and thousands of users the probability of occurrence is high,” the researchers noted in a blog post.
Several AWS services previously vulnerable to ‘Shadow Resources,’ ‘Bucket Monopoly’ attacks
Following their discovery of the “Shadow Resources” vulnerability in AWS CloudFormation, the researchers expanded their investigation to other AWS services and discovered that the Glue, EMR, SageMaker, ServiceCatalog and CodeStar services were also affected by their own versions of the flaw.
All of these services created “shadow buckets” to store certain resources upon a new user action, such as creating a new Glue job, new EMR Studio or new SageMaker Canvas, and these buckets had predictable names including fixed prefixes, AWS account IDs and region codes.
Depending on the service, exploitation of the vulnerability could result in different impacts: manipulating the code of Glue jobs could lead to remote code execution (RCE), injecting code into Jupyter notebooks uploaded by EMR could enable cross-site scripting (XSS) attacks, reading and writing of SageMaker datasets could lead to theft or manipulation of AI training datasets and squatting of CodeStar S3 buckets can lead to denial-of-service (DoS) due to the inability to create new projects using another account’s bucket.
Attackers could improve the success rate of their attacks by creating what the researchers called a “Bucket Monopoly,” claiming the names of all possible buckets in all regions for any known user hash or account ID. This way, any new bucket generated in any region by the target would lead to an attacker-controlled bucket.
Aqua Security first reported these flaws to the AWS security team in February 2024, prompting a swift response that concluded with full resolution of all vulnerabilities by June 2024.
AWS account IDs, unique hashes should be treated as secrets
Although the “Shadow Resources” vulnerabilities have been addressed by AWS, the researchers note that their findings demonstrate the importance of treating potential identifiers, such as AWS account IDs, as secrets. The Shadow Resources and Bucket Monopoly attackers rely on the attacker obtaining either the account ID or unique CloudFormation bucket hash of the victim, meaning that protecting these values could effectively prevent the attacks.
The researchers were able to discover many exposed CloudFormation hashes and AWS account IDs by conducting regex searches on GitHub, and large lists of known AWS account IDs are also available online, showing the scope of the threat posed by the now-resolved vulnerabilities. S3 bucket squatting may still be a concern, however, as some open-source AWS integrations also automatically generate S3 buckets that may have similarly predictable names. In order to prevent exploitation of similar, not yet identified flaws in open-source integrations and other services, the researchers recommend users avoid exposing their account IDs and hashes, implement the aws:ResourceAccount condition to ensure services avoid using buckets owned by other accounts, verify the ownership of buckets used by their services and use unique names for S3 buckets whenever possible, rather than predictable names following known naming conventions.
Also, since the potential for account takeover using this vulnerability was dependent on the permission level of the user whose action triggered use of the attacker's S3 bucket, this demonstrates the importance of following least privilege principles when assigning roles to users.
[For up-to-the-minute Black Hat USA coverage by SC Media, Security Weekly and CyberRisk TV visit our spotlight Black Hat USA 2024 coverage page.]
