A bug in the AWS API lets hackers work out the permissions a given set of credentials has without generating logs and alerting defenders on governance, compliance, and operational auditing tool CloudTrail.
The bug was first identified in October by Nick Frichette, an experienced penetration testor at State Farm, a large US-based group of insurance and financial services companies, and detailed in a technical write-up.
The bug affects 645 different API actions across 40 different AWS services, Frichette first noted on October 17, 2020. AWS says it is not a vulnerability and has declined to fix it -- arguably a gift for Red Teamers or bad actors.
Basically, the bug means that anyone who gets their hands on AWS credentials (e.g. culling them from a Git repository -- a fairly frequent occurance); stealing them from a running EC2 instance or simply phishing someone, ermissions the role or user they’ve compromised has access to without alerting the blue team as no logs are generated in CloudTrail.
(Attackers regularly scan and scrape GitHub repos for passwords, API tokens, credentials, et al. and it takes minutes for them to start trying to exploit them once they've been spotted, honeypot activity shows.)
AWS API bug - how it works.
"The vulnerability affects certain AWS services that use POST requests and the X-Amz-Target header (Each AWS API uses different protocol types. Some use GET requests, some POST to an API endpoint, etc.)" Frichette noted in his blog. "The majority of these services require the Content-Type header to be ‘application/x-amz-json-1.1’. In the majority of instances, sending ‘application/x-amz-json-1.0’ will provide you with an error; typically 404 - ‘UnknownOperationException’ or 500 - ‘InternalFailure’.
He added: "However, on the services with vulnerable API calls you get a 403 response if you did not have permission to call the API. If the role did have permission to call the API you instead get a 404. Because these are technically “malformed” requests, none of this traffic is sent to CloudTrail. This means you can enumerate whether or not a given role has privileges to make the API call without that reconnaissance being logged. It is important to note that you would only get a 404 response if the role had permission to make that API call, and if the resource was set to ‘*’.
Read the full technical write-up on Nick Frichette's site here.
Frichette told The Stack: "I found it by accident. I was curious about how the AWS API works on a very low level. While I was poking around, I happened to notice that I was getting different response codes and eventually stumbled into the fact that none of it was getting logged to CloudTrail... I'm not too bothered by it not being treated as bug by AWS. It's not a critical vulnerability by any means so I can't blame them for not fixing it right away. That being said, the vulnerability can be very useful to enumerate permissions stealthily and it would be better if it was fixed."
AWS had not responded to a request for comment as we published. Frichette, who contacted AWS' security team on September 2, 2020, described them as "very polite and easy to work with", but said he disagreed that it's not a bug worth fixing. (One suspicion is that various unseen dependencies make fixing it hard and not worth AWS's while).
As he notes in his blog: "One of the hardest parts about attacking AWS infrastructure is finding what permissions you have available to a role you’ve compromised. You can use tools to brute-force these permissions however that’s a very noisy process and is likely to trip alerts (which is a good thing). Because of this bug, an adversary can enumerate whether they have hundreds of API permissions" without triggering alerts.
It is, Frichette notes gently to The Stack, "another little thing for cloud security folks to be aware of. There are a number of little tricks that can't/won't be fixed that adversaries can use. Defenders have to be aware of these techniques and know that they may be used against them."
