Finding Treasures in Github and Exploiting AWS for Fun and Profit — Part 2
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. Please note a personal snapshot was used for the demo.
In our journey from Part 1, we found AWS credentials and used them to enumerate and discover an AWS EBS snapshot which turned out to be public. This post continues our journey of what to do next.
To read Part 1 of this post, go to https://blog.appsecco.com/finding-treasures-in-github-and-exploiting-aws-for-fun-and-profit-part-1-be5cfadf942
Table of Contents
- Introduction
- Where can you find public snapshots?
- What to do after finding these snapshots?
- How do you protect your snapshots?
- References
Introduction
Amazon Elastic Block Store (Amazon EBS) provides block-level storage volumes for use with EC2 instances. EBS volumes behave like raw, unformatted block devices. You can mount these volumes as devices on your instances.
EBS volumes that are attached to an instance are exposed as storage volumes that persist independently from the life of the instance. This document shows how can you detect these public snapshots and exploit them to gain sensitive information.
Where can you find public snapshots?
AWS allows you to configure EBS snapshots to have public visibility. This is so that you can wantingly make your snapshots public as part of the wider community or if you wanted to distribute the snapshot to a wider audience as part of your business offerings. However, more often than not, AWS users accidentally expose these snapshots to all AWS users.
A quick way to check if a snapshot id you have obtained is public or not is to run the following command
aws ec2 describe-snapshots --snapshot-ids <snapshot-id-here>
If you see an output, the snapshot is public.
AWS has over 20,000+ public snapshots in US East 1 region alone! You can see them in your console here.
What to do after finding these snapshots?
To quickly work with a public snapshot (best results with a non encrypted snapshot), you can create a volume out of them and attach the volume to an EC2 instance and browse the filesystem.
Using the snapshot-id obtained from the credentials discovered in Part 1 of the post, we can create a volume and attach the volume to an Ubuntu instance.
Once attached, we can, mount the filesystem to check through the disk. After attaching the volume, ssh into the instance which is launched
ssh -i "YOURS.pem" ubuntu@<ip>Run the command to view the filesystem - lsblk
Now, let's mount the partitionxvdf1 to /mnt using the mount command.
mount /dev/xvdf1 /mntOnce you mount you can browse the files and folders, hunting for credentials gets you some quick wins. A good place to check is the /mnt/root/.ssh directory which contains SSH keys if default paths are used when creating them.
Looking at the ~/.bash_history file should give you some IP addresses that could potentially be accessible using the SSH keys.
Additional discovery can be performed on this machine. We found the/opt folder to contain some interesting stuff.
I saw that the dev folder had a git repository.
To view the git commits on the repo, we can use git log . After checking the commits, one commit caught my attention. The commit message read Remove env config which I thought was interesting.
I copied the commit ID of the commit and ran git show <COMMIT-ID> This showed me the credentials of an instance including some other sensitive information. This is a good example of what a post exploitation scenario would like.
How do you protect your snapshots?
A good way to secure your EBS snapshots is to ensure their visibility is set to private AND they are encrypted.
We can automate this using Service Control Policies as well. Create an SCP that blocks “ec2:ModifySnapshotAttribute” which is responsible for modifying snapshot permissions to make it public. This prevents making snapshots public (available to all AWS accounts). We will write about this in a future post.
In the AWS console, look at the Permissions tab for any snapshot and make sure it says “This snapshot is currently Private” if not navigate to your modify permissions in snapshots. Check the below image:
Conclusion
As with any system, AWS cloud offers multiple options to configure resources securely. Access to resources should always be based on least privileges and should be periodically audited for misconfigurations. Until next time!
References
EBS Snapshots exposed publicly
