Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

S3 buckets are file storage on AWS. AWS eats its own dogfood a lot, meaning that many of the AWS services will use S3 under the hood.

In Cloud Formation (infrastructure as a service), an S3 bucket was created that was per region when CF was turned on in the region. This was a contains all of the user defined templates.

S3 is a global AWS service, unlike most things at Amazon. So, there is a classic vulnerability called bucket sniping. This is all about registering the bucket before someone else does, then having access to it once the service starts using it.

By creating the bucket in account B, when account A setup CF in that region, account A would use the user controlled bucket. To make this viable, the public must be made public and have a very generous resource policy that allows account A access.

At this point, the template can be modified to add resources in the account! The authors mention a TOCTOU issue on Cloud Formation from previous research to add in the resource but not strictly needed. To exploit this, do the following:

1. Claim the bucket with the predictable name of the victim.
2. Create a lambda function to execute upon bucket access from the victims account. This
3. Wait for them to start using CF in that region.
4. In the lambda function, modify the CF template that was written before execution.
5. Run the backdoor templated file. This will create an admin role controlled by the attacker that can be assumed by them, giving them admin access to the account. To do this, the executor of the CF template must have IAM permissions.

The bucket has a random value associated with it. For whatever reason, they were unable to figure it out. Via OSINT on Github, it seems feasible to expose the hash.

From there, they wanted to find other services vulnerable to the same issue. They found AWS Glue, EMR, SageMaker, CodeStar and Service Catalog vulnerable to the same attack. In terms of impact, sometimes it was RCE on the service itself or data manipulation.

Many AWS services run with the execution of the user itself. Since this is the case and the bucket permissions are open, this exploit makes sense. However, I'm fairly confident this is a standard thing that AWS engineers should test for, making it surprising how many cases of this were found, especially in such big services. Overall, great post though!