The AWS bucket trap: six major services affected by critical vulnerabilities

The last thing a network defender wants is to find out that the company’s services are hosted on an attacker's infrastructure. Researchers from Aqua Security have discovered that an AWS account ID – a resource plentiful on GitHub – is all an attacker needs to claim ownership of some important S3 buckets before they’re even created.

S3 buckets are simple cloud storage containers on Amazon Web Services (AWS), similar to file folders on a computer that store files. They can be used to store images, videos, or other data, but some AWS services also create S3 buckets for operational data.

One unique feature of the S3 buckets is that each has a unique name and only one bucket may exist with that name.

However, when AWS services, such as CloudFormation or SageMaker, create an S3 bucket to store scripts or data, AWS uses predictable naming conventions. Usually, the bucket name consists of three parts: service name, account ID, and region.

With that knowledge, an attacker, knowing the account ID, can claim the bucket first. Hackers, in theory, could surround their targets with multiple buckets and wait until the victims want to add an additional service or region. Once it does, the AWS service, instead of creating a new S3 bucket, will attribute the attacker’s “shadow” resource.

Depending on the rights and service type, attackers could then read sensitive data, inject malicious code remotely, or even compromise an entire AWS account. In the most severe cases, modifying CloudFormation templates could allow attackers to inject an admin role.

“During February 2024, we discovered critical vulnerabilities in six AWS services. The impact of these vulnerabilities range between remote code execution (RCE), full account takeover, manipulation of AI modules, exposing sensitive data, data exfiltration, and denial of service,” the report by three Aqua Security researchers reads.

Researchers called the technique “Bucket Monopoly.” Six AWS services – CloudFormation, Glue, EMR, SageMaker, ServiceCatalog, and CodeStar – were affected by it.

“We can now determine that AWS account IDs should be considered secret, as they are the only piece of information an attacker needs to exploit AWS accounts and services.”

The security firm responsibly disclosed the newly discovered vulnerabilities to AWS, and the cloud computing giant patched the issues. However, the underlying attack vector may still exist, affecting other services and projects relying on predictable patterns.AWS indicated that they “are confirming the results of each team’s investigation and will contact customers directly in the event they are affected by any of the reported issues.”

“AWS is aware of this research. We can confirm that we have fixed this issue, all services are operating as expected, and no customer action is required,” an AWS spokesperson told Cybernews.

Cybernews previously reported how bucket names can cause troubles for cloud service users, leading to bill increases or worse.

How can attackers abuse “shadow resources”?

Researchers discovered the issue while using the AWS CloudFormation service, which automates cloud resource setup using templates. Each time they uploaded a template file, a new S3 bucket with a specific naming convention was automatically created.

“We noticed that when you use this service via the AWS Management Console for the first time in a new region to create a new stack (collection of AWS resources), the service automatically triggers AWS to create an S3 bucket for storing our CloudFormation templates,” researchers said. “The name of the bucket is the same across all AWS regions, except the region’s name.”

Experimenting with unique buckets and their names revealed that the attacker, having some information about the account, can guess the names of buckets that a victim may potentially use in the future. The owner of the AWS account may not always be aware that these resources exist.

The CloudFormation created S3 buckets using a specific name with the prefix “cf-templates,” a random 12-character hash, and the name of a region. For different regions, the only difference in the separate bucket name was the region part.

If the attacker claims the bucket first and leaves it private, that effectively denies the victim from using the Cloud Formation service. However, a threat actor can escalate the attack by leaving the bucket open for public access and creating a permissive policy.

“This way, the victim’s vulnerable service will be able to read and write data to the attacker-controlled bucket,” researchers said. “It will trust it, access it, and drop its template file to it.”

CloudFormation templates potentially contain sensitive information, such as environment variables, credentials, and more. Disclosure of this information alone could have a critical impact on the organization.

However, attackers can then elevate this vulnerability to an even higher level of severity by modifying the victim’s CloudFormation templates before they’re executed, injecting a backdoor or other resource. The malicious template could create a new admin role, which the attacker then assumes.

“Essentially, we have an admin role in a targeted organization simply by knowing their CloudFormation unique hash. This is the most severe vulnerability that we can achieve in the cloud, as it allows us to take over the victim's account,” researchers said.

Obtaining the unique hash is not that easy. Multiple attempts to predict or calculate it failed. Nevertheless, researchers found numerous hashes used by different AWS accounts simply by searching on GitHub.

Moreover, some other AWS services don’t even require the hash for S3 bucket creation – they use account ID as a unique identifier instead.

What can attackers achieve?

In total, researchers described six vulnerable AWS services.

One of them, AWS Glue, is a service utilized by data engineers and analysts to automate the extraction, transformation, and loading (ETL) processes, streamlining data preparation for analytics and machine learning. This service creates buckets to store jobs mostly as Python scripts.

“An attacker who knows your AWS account ID could potentially create this bucket in any region if it doesn't already exist, and then wait for the victim to use Glue ETL via the AWS Management Console for the first time in a new region. This will lead to the victim's Glue service writing files to the attacker-controlled bucket,” the report explains.

This would allow an attacker to inject any code, resulting in a remote code execution attack. If the victim had granted excessive permissions to Glue jobs, this could lead to a complete compromise of the account.

AWS EMR (Elastic MapReduce), which is a cloud big data platform, uses a similar S3 bucket naming pattern: aws-emr-studio-{Account-ID}-{Region}. Attackers can also create an unclaimed bucket with this predictable name and wait for the victim to deploy a new EMR Studio in a new region, inject malicious code into a Jupyter notebook, resulting in a cross-site scripting (XSS) attack when the user opens it.

Researchers gave another example: “The attacker could redirect the user to a spoofed AWS login page to steal their credentials. Even worse, if the role assigned to the service has higher permissions, the attacker could create resources or compromise the entire account.”

The last three AWS services, creating easy guessable S3 buckets, were as follows:

• AWS SageMaker is a service for building, training, and deploying machine learning models at scale. The attacker could access and manipulate important data
• AWS CodeStar is a service that simplifies project management. The attacker could prevent the user from using a service.
• AWS Service Catalog is a tool designed to help organizations create and manage catalogs of approved resources. The buckets created by this service have a unique hash in their name. Attackers, by claiming buckets first, could inject remote resources, enabling the deployment of malicious resources or, in some cases, adding an admin user that can be assumed by the attacker. The damage would heavily depend on the privileges granted by users.

“We have clearly shown that by doing all the above, attackers can use the S3 buckets planted in their account to execute code, manipulate or steal data, and even gain full control over the victim account without the user’s knowledge,” the report reads.

Organizations use “many open-source projects” to deploy resources in their AWS environments. These often create S3 buckets automatically and may also be abused by attackers to access files or even take over the account.

Researchers recommend that AWS users treat their account ID as a secret, double-check the buckets’ ownership, and carefully define roles and permissions. The experts also suggest getting creative with naming the S3 buckets, using unique, randomized names and making them harder to guess.

The research “Bucket Monopoly: Breaching AWS Accounts Through Shadow” by Aqua Security researchers Yakir Kadkoda, Michael Katchinskiy, and Ofek Itach was introduced at the Black Hat USA 2024 conference.