Finding Treasures in Github and Exploiting AWS for Fun and Profit — Part 1
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.
Table of Contents
- Introduction
- How I found the treasure?
- How can I automate this process?
- What after finding the sensitive information?
- References
Introduction
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.
How I found the treasure?
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
GitHub Dorks
- filename:credentials aws_access_key_id
- “token” “AQoDY”
- “rds.amazonaws.com”
- filename:credentials AWS_ACCESS_KEY_ID
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).
How can we automate this process?
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
.
- Run the below command to search the sensitive information in the given git repository
./trufflehog git https://github.com/NAME/REPO
Trufflehog supports the detection of a LOT credentials in git repos and even on the filesystem.
Found AWS credentials, now what?
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) using the following command
aws ec2 describe-snapshots --snapshot-ids <snapshot-id-here>
It turned out to be public, which is a good find for attackers :D
Watch out for our Part 2 in the coming weeks, where I show how I exploited the public snapshot to uncover even more goodness.