Exploiting AWS Cross-Account access

Philip Zeh
Dec 7, 2021 · 4 min read

Your S3 Bucket might be exposed to the latest cross-account vulnerability

Introduction

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

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

coarse iam policy

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.

leaked sensitive file using SAR

In short SAR makes it effortless for attackers to move from one account to another, reading sensitive information and inflict damage.

The Fix

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

Stay vigilant when creating IAM policies!

Axel Springer Tech

Tech and product folks writing about their work across the…