Exploiting AWS Cross-Account access
Your S3 Bucket might be exposed to the latest cross-account vulnerability
Introduction
This writeup is for anyone willing to learn what a Confused Deputy Attack on AWS might look like and how to fix it.
Earlier this year security researchers presented a Confused Deputy Attack on S3 Buckets at Black Hat 2021. A Confused Deputy Attack is a security issue where an entity that doesn’t have permission to perform an action or access data can use a more-privileged entity to perform that action.
The theoretical exploit
Usually one might think that given an AWS Account that it is completely isolated from other AWS Accounts/Customers.
In theory this is true, but real world scenarios look different.
Simply spoken AWS offers possibilities to grant to other AWS Accounts and resources. IAM policies allow different services to access one another.
An example for that is allowing multiple accounts to invoke a centralized api gateway authorizer.
According to the OWASP TOP 10 List of 2021 “94% of applications were tested for some form of broken access control”.
As these numbers are quite critical security misconfiguration is the number one security risk, even on AWS.
Nowadays most customers, including my employer, make us of a multi-account approach. Instead of deploying every single application in one account, one divides everything into several accounts, each of which for a specific purpose.
It’s quite common for a company to have hundreds if not thousands of accounts in AWS. Due to maintenance reasons customers grant AWS services across their multiple accounts.
That’s where a confused deputy attack comes into play:
If you do not have access to certain resources one of the AWS Services might have them. You just need to find a way to trick the AWS Service into performing actions on your behalf. That’s it. 😄😈
The SAR vulnerability
AWS Serverless Repository is a platform service that allows customers to store and deploy serverless applications. It needs to pull objects from S3 Buckets.
Due to a misconfigured sample IAM policy that AWS initially provided in their documentation it is possible to exploit the Service to read from other private S3 Buckets. This can lead to leaked sensitive information like passwords or source code.
The policy allows Serverless Repository to access any object in the bucket.
The problem: it does not define or limit who can use the service to access the bucket.
As an attacker all you have to do is create a private application in SAR and update it’s readme url using the aws cli:
aws serverlessrepo update-application --application-id <insert-your-id-here> --readme-url <victim-bucket/file-to.access>All the attacker has to do is guess the bucket and file names. As there’s a cli command for updating the readme-url one can easily automate this.
For demo purposes i setup another AWS account as well as another private serverless application and tried to access sensitive data using my first one. Guess what: It worked.
In short SAR makes it effortless for attackers to move from one account to another, reading sensitive information and inflict damage.
The Fix
Since this vulnerability was discovered AWS has fixed the default policy in their documentation. It’s quite straight forward as all you have to do is restrict the access to your own source account.
Sadly AWS can’t fix this issue all on its own as it is not allowed to modify or update resource policies of its customers. Whenever user-action is involved the fixing a vulnerability is always less effective. All Amazon was able to do was sending emails and security notifications in the Personal Health Dashboard.
At the time of this blog post i was able to identify that at least 5 out of 10 SAR application buckets that i tested were still improperly configured.
ACT NOW!
Conclusion
AWS has a strict security standard (which btw is high-level) yet customers are prone to the #1 security issue. Even AWS can do mistakes. This type of cross-account vulnerability is fairly new, most users are completely unaware. We don’t even know how many vulnerabilities inside of AWS have not been found yet, similar issues likely exist.
Stay vigilant when creating IAM policies!
