AWS 'Bucket Monopoly' attacks could allow complete account takeover
Vulnerable services fixed by the cloud biz but open source projects still at risk
Black Hat Critical flaws across at least six Amazon Web Services cloud services could have allowed attackers to execute remote code, steal data, or even takeover a user's account without their knowledge, according to research presented today at Black Hat.
Aqua Security's Nautilus team detailed the vulnerabilities, which have since been fixed by the cloud services giant, in a conference talk titled: Breaching AWS Accounts Through Shadow Resources.
But first they chatted with The Register about how sophisticated criminals, such as those backed by nation states, could predict AWS S3 bucket names, and then also use a new method they call "Bucket Monopoly" to essentially pre-load malicious code into a bucket and wait for the target org to unwittingly execute it.
This, the researchers said, could have led to "catastrophic" attacks across any organization in the world that has ever used the six cloud services in question.
"At the end of the day, any vulnerability that can reach the creation of admin user and de facto account takeover is risky, and the consequences could be crippling to an organization," Assaf Morag, a lead data analyst at Aqua Nautilus research team, told The Register.
Plus, while AWS fixed the vulnerabilities across these six services — CloudFormation, Glue, EMR, SageMaker, ServiceCatalog, and CodeStar — similar issues may still exist across other AWS offerings and open source projects, many of which use S3 buckets for implementation.
Name squatting 'on steroids'
The flaws stem from predictable S3 bucket names. When an organization uses any of these six services for the first time in a new region, AWS automatically creates an S3 bucket with a certain name. The bucket name is the same across all AWS regions — except for the region part — and it's divided into the name of the service of the AWS account ID, a random 12-character hash, and the name of the region.
Once a new bucket is created, its name is unique, and no one else can create another bucket with the same name.
For example, an AWS account using CloudFormation in the us-east-1 region could have this name: cf-templates-123abcdefghi-us-east-1
And then if the same account used CloudFormation in a different region, such as eu-west-2, AWS would auto-create a new bucket named: cf-templates-123abcdefghi-eu-west-2
In all, AWS has 33 of these geographic regions.
Up first: Poking holes in CloudFormation
Beginning with CloudFormation, Aqua Nautilus decided to find out if an attacker could guess the name of a CloudFormation S3 bucket and then create a new bucket in a different region before the victim did? The answer, of course, was yes.
And the assumption is that an attacker could create this phony bucket that appears to be the real deal, and then when the victim attempts to use their CloudFormation in a different region, they will see this bucket and assume it is theirs.
Meanwhile, the attacker could have already filled it with malicious stuff, which will then be injected into anything that works with this bucket. Or they could sit back and wait for the victim to drop sensitive files in the bucket and then have full access to that data, among other nefarious deeds.
"It's a very realistic scenario," Morag told The Register. "All you need is to have the account ID of the company, and if you do a short threat collection or threat intelligence session on the company, you can find it."
While he added that script kiddies or fraudsters with limited technical abilities won't be able to pull it off, "we are talking about state-sponsored threat actors, the more advanced, professional attackers."
- PowerShell? More like PowerHell: Microsoft won't fix flaws in package gallery ripe for supply chain attacks
- Infosec watchers: TeamTNT crew may blast holes in Azure, Google Cloud users
- Lights, camera, AI! Real-time deepfakes coming to DEF CON
- Sneaky SnakeKeylogger slithers into Windows inboxes to steal sensitive secrets
The biggest hurdle is determining the victim's hash, which is unique to each account but the same across all regions. It's made up of 12 characters, both letters and numbers, and according to Aqua there's some 4,738,381,338,321,616,896 possible combinations, so it's impossible to guess or brute force.
"The possible combinations are enormous, so we took another approach," former Aqua researcher Michael Katchinskiy said. This involved using GitHub regex and Sourcegraph searches, and scraping open databases, looking for leaked hashes, "and we found a nice amount," he noted.
On Friday, the Aqua crew will publish a technical analysis of the vulnerabilities and potential exploits across all the various AWS services, so keep an eye out for that. But here's what the threat intel group says an attacker could do provided they know the CloudFormation hash part of the targeted AWS account.
The first, which Ian Mckay called S3 Bucket Namesquatting in an earlier blog about abusing S3 buckets' predictable naming mechanisms, occurs when the victim tries to deploy a new CloudFormation stack in a different region — and finds the intended bucket name has already been claimed by an attacker. CloudFormation returns an error message because the bucket name is already in use and the victim is prevented from using the "upload a template file" feature on CloudFormation.
The researchers consider this a denial-of-service attack, in part because S3 buckets' default is to block all public access so the victim can't perform any actions on the attacker-controlled bucket.
But wait, there's more
However, to do something even nastier, the criminal could change the S3 bucket's configuration settings to make it publicly accessible. This attack also requires writing a permissive policy that allows the victim's service to read and write data to and from the attacker's bucket.
"And then the bucket just sits, waiting for the vulnerable service to write some data to it," lead Aqua security researcher Yakir Kadkoda told The Register.
In this scenario, the victim org tries to create an S3 bucket in the new region and upload a template file to CloudFormation. The bucket already exists, and because of its permissive policy, the victim's account trusts it and can write files to it — including templates with users' credentials and other sensitive information — resulting in an information disclosure attack.
And finally, in a scenario that could end very, very badly for the victim organization, Aqua developed a proof-of-concept in which the criminals use a Time of Check to Time of Use (TOCTOU) issue within CloudFormation to modify the templates before they are executed and create an administrative role.
CloudFormation was the first AWS service that Aqua tried to exploit — and successfully found exposed hashes on GitHub — by abusing S3 buckets. But after reviewing "a few dozen" others, using similar attack methods, they came up with a total of six vulnerable cloud services.
Again, you can read about all six in the forthcoming research, but another especially scary one would allow miscreants to inject code into AWS Glue, resulting in remote code execution. Glue is a data integration service that automates the extraction, transformation, and loading (ETL) process for analytics and machine learning.
A similar naming mechanism in SageMaker, AWS's service for training and deploying machine learning models at scale, can be abused to manipulate data and expose sensitive data used to train ML models.
"It's like a landmine," Katchinskiy said.
In response to these findings, spokespeople for Amazon told us: “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.” ®
Editor's note: This article was updated on August 8 to include Amazon's response.