Disclaimer: This article is written for educational purposes, the author and Appsecco does not encourage readers to do engage in questionable practices without the permission of the repository owner.
This is a story in which I discovered some AWS credentials and endpoints which I then used to gain root access to an EC2 instance.
GitHub is where over 56 million developers shape the future of software, together. Contribute to the open-source community, manage their Git repositories, and do lots of stuff. Apart from this developers also add API keys, passwords, customer data, etc. without understanding the impact of what a leak could do.
I was hunting on a private bug bounty program, in which the target’s scope includes all subdomains & their open source code repositories. Like any other bounty hunter, I navigated to GitHub and searched for any sensitive strings within GitHub, trimming the results down to the repositories that I knew were in scope.
I used a particular dork in the GitHub search: filename:credentials aws_access_key_id .
This shows up a lot of results, which you can sort and search for the repos you are interested in. Here are some additional dorks to try to find credentials and tokens
One of the repos of the target contained the AWS credentials, host endpoint and a snapshot identifier.
To demonstrate this, I have used my own repository which you can see in the screenshot below. You can see a host endpoint, AWS credentials, and Snapshot ID being leaked.
I configured the AWS credentials, by running the below command
aws configure --profile stolencreds
I was then able to run aws cli commands with the profile argument on the target cloud account. The credentials had a lot of permissions within the account which I was able to discover using a tool (more on this a little later).
There are a bunch of interesting tools that can help us to find the credentials via automation. One of the more popular ones is trufflehog.
./trufflehog git https://github.com/NAME/REPO
Trufflehog supports the detection of a LOT credentials in git repos and even on the filesystem.
Alongside the credentials, I found an EC2 instance endpoint. Riding on a hunch that this instance could somehow be accessed through the credentials, I started to explore my access.
There are multiple tools available that can give you a fair idea of what permissions a given AWS credentials have. I tried a tool called weirdALL to do this.
The tool runs through a LOT of Get and Describe API calls across the target AWS account and prints what is allowed.
All tools that do permission enumeration are bound to be noisy and a good monitoring team can pick up enumeration attempts easily.
The credentials had a DescribeSnapshots permission that we can use to describe the EBS snapshots within the AWS account. I ran the aws cli command to figure out the snapshots and their status within the account.
aws ec2 describe-snapshots --region <REGION> --profile stolencreds
or
aws ec2 describe-snapshots --region <REGION> --owner-id <ACCOUNT_ID>
After obtaining the Snapshot ID, I tried to check the visibility of the snapshots (public to AWS users or private to account). It turned out to be public, which is good find for attackers :)
Watch out for our Part 2 post next week, where I show how I exploited the public snapshot to uncover even more goodness.