Critical AWS Vulnerabilities Allow S3 Attack Bonanza

Source: Holger Burmeister via Alamy Stock Photo

BLACK HAT USA – Las Vegas – Thursday, Aug. 8 – Six critical vulnerabilities in Amazon Web Services (AWS) could have allowed threat actors 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 gave access to other accounts with minimal effort from the attacker perspective,” Aqua’s lead security researcher Yakir Kadkoda tells Dark Reading.

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

Upon discovering the vulnerabilities in February, the Aqua researchers reported them to AWS, which confirmed the issues and rolled out mitigations to the respective services piecemeal between March and June. However, open source iterations could still be vulnerable.

'Bucket Monopoly’: Attacking Public AWS Account IDs

The researchers first uncovered Bucket Monopoly, an attack method that can significantly boost the success rate of attacks that exploit AWS S3 buckets — i.e., online storage containers for managing objects, such as files or images, and resources required for storing operational data.

The issue is that S3 storage buckets were designed to use predictable, easy-to-guess AWS account IDs instead of a unique identifier for each bucket name using a hash or qualifier.

“Sometimes the only thing that an attacker needs to know about an organization is their public account ID for AWS, which is not considered sensitive data right now, but we recommend it is something that an organization should keep as a secret,” Kadkoda says.

To mitigate the issue, AWS changed the default configurations.

“All of the services have been fixed by AWS in that they no longer create the bucket name automatically,” 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 debated whether AWS account IDs should be public or private. AWS cautions customers against sharing credentials and advises them to use and share account IDs carefully. 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 since there may be other kinds of similar exploits that could be carried out based on knowing an account ID,” Kadkoda notes in a detailed technical report on the vulnerabilities set to be published on Friday. “Although the common assumption is that knowing an account ID alone is not sufficient to hack an account, attackers might still use it to gather information about your AWS account and more.”

An AWS spokesperson declined to comment on that specifically, but did say that AWS was 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,” the spokesperson says.

Shadow Resources: Hidden Assets Offer Cover for Attackers

Kadkoda says his team also discovered the Shadow Resources attack vector, which can create AWS S3 service components unknown to the account owner.

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

That’s because when using 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, which is how an attacker can guess the account name and gain access to it.

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

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

“In most cases, these configurations are really significant because these are the instructions to 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 can have hundreds or thousands of distinct AWS accounts spread across regions worldwide, exploits of shadow services could have been significant, Morag emphasizes. Where there were any victims of the vulnerability is not known.

“The potential of being attacked or being a victim could have been massive,” he says.

Open Source Projects in S3 Buckets Could Still Be Vulnerable

While AWS has mitigated the vulnerabilities impacting its services, Kadkoda warns that the attack vectors could still impact open source projects deployed in their AWS environments. Many open source projects automatically create S3 buckets or direct users to deploy them, he notes.

“We found a lot of open source projects vulnerable to this vector because they’re using them behind the scenes with predictable bucket names,” Kadkoda says.

Users should check to see whether each existing bucket’s name has been claimed elsewhere, and, if so, they should rename it.

In all cases, Kadkoda and Morag say 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 a random identifier for each region and account to prevent attackers from claiming them first.

About the Author

Jeffrey Schwartz is a journalist who has covered information security and all forms of business and enterprise IT, including client computing, data center and cloud infrastructure, and application development for more than 30 years. Jeff is a regular contributor to Channel Futures. Previously, he was editor-in-chief of Redmond magazine and contributed to its sister titles Redmond Channel Partner, Application Development Trends, and Virtualization Review. Earlier, he held editorial roles with CommunicationsWeek, InternetWeek, and VARBusiness. Jeff is based in the New York City suburb of Long Island.