BLACK HAT USA – Las Vegas – Thursday August 8 – Six critical vulnerabilities in Amazon Web Services (AWS) could allow attackers to target organizations with remote code execution (RCE), exfiltration, denial-of-service attacks, or even account takeovers.

“Most of the vulnerabilities were considered critical because they allowed the attacker to gain access to other accounts with minimal effort,” Yakir Kadkoda, lead security researcher at Aqua, told Dark Reading.

During a briefing on Wednesday at Black Hat USA In Las Vegas, researchers from Aqua Security revealed that they have discovered new attack vectors using the “Bucket Monopoly” and “Shadow Resources” bugs. The affected AWS services include Cloud Formation, CodeStar, EMR, Glue, SageMaker, and Service Catalog.

When Aqua researchers discovered the vulnerabilities in February, they reported them to AWS, which acknowledged the issues and gradually implemented mitigations for the affected services between March and June. Open-source iterations can still be vulnerable, however.

‘Bucket Monopoly’: Attacks on Public AWS Account IDs

The researchers were the first to discover Bucket Monopoly, an attack vector that can significantly increase the success rate of attacks that abuse AWS S3 buckets, which are online storage containers for managing objects, such as files or images, and resources needed to store operational data.

The problem is that S3 storage buckets are designed to use predictable, easy-to-guess AWS account IDs rather than uniquely identifying each bucket name using a hash or qualifier.

“Sometimes all an attacker needs to know about an organization is its public AWS account ID. This information is not currently considered sensitive, but we recommend that organizations keep it secret,” Kadkoda said.

To resolve the issue, AWS changed the default configuration.

“All services have been fixed by AWS, as they no longer auto-generate the bucket name,” he explains. “AWS now adds a random identifier or sequence number if the desired bucket name already exists.”

Security researchers and AWS customers have long discussed Whether AWS account IDs should be public or private. AWS warns customers against sharing credentials and advises them to use and share account IDs with caution. However, according to AWS documentation on account identities, account IDs “are not considered secret, sensitive, or confidential information.”

Aqua’s researchers disagree.

“Based on our research, we strongly believe that account IDs should be considered secrets, as other types of similar exploits can be performed based on knowing an account ID,” Kadkoda notes in a detailed technical report on the vulnerabilities published Friday. “While the common assumption is that knowing an account ID alone is not enough to compromise an account, attackers can still use it to getting information about your AWS account and more.”

An AWS spokesperson declined to comment but said AWS was aware of the investigation.

“We can confirm that we have resolved this issue, that all services are functioning as expected and that no customer action is required,” the spokesperson said.

Shadow Resources: Hidden resources provide cover for attackers

Kadkoda says his team also discovered the Shadow Resources attack vector, which can create AWS S3 service components without the account owner’s knowledge.

The researchers initially discovered the issue in the AWS CloudFormation service, where an attacker could perform resource squatting by creating accounts in unused AWS geographic regions with the same names as legitimate, existing stacks. Once the victim stored their workloads in a new region, they could connect to it and then unknowingly consume attacker-controlled S3 buckets.

That’s because when you use the service with the AWS Management Console to create a new stack, AWS automatically creates an S3 bucket to store CloudFormation templates. The name of the S3 bucket is the same across all AWS regions, allowing an attacker to guess the account name and gain access to it.

“I can take over your S3 bucket and poison and replace the configuration,” says Aqua security researcher Assaf Morag. “It’s a big deal because between the lines, you can use remote code execution to grab the accounts of any company in the world.”

All services require configuration files and AWS uses S3 buckets as the file system to store configurations.

“In most cases, these configurations are really important because these are the instructions for the services,” Morag says. “It could be a YAML file or other things that the service needs to use behind the scenes.”

Given that customers could have hundreds or thousands of separate AWS accounts spread across regions worldwide, shadow service exploits could have been significant, Morag points out. It is not known where victims of the vulnerability have fallen.

“The chances of being attacked or becoming a victim were huge,” he says.

Open Source Projects in S3 Buckets May Still Be Vulnerable

While AWS has reduced the vulnerabilities affecting its services, Kadkoda warns that the attack vectors could still affect open source projects deployed in their AWS environments. Many open source projects automatically create S3 buckets or instruct users to implement them, he notes.

“We have found that many open source projects are vulnerable to this vector because they use it behind the scenes with predictable bucket names,” Kadkoda said.

Users should check if the name of each existing bucket has already been claimed elsewhere. If so, they should rename the bucket.

In all cases, Kadkoda and Morag say that users should avoid creating S3 buckets with predictable or static identifiers in the first place. Instead, they should create an S3 bucket name with a unique hash or random identifier for each region and account to prevent attackers from claiming them first.