pentesting.cloud part 1: “Open To The Public” CTF walkthrough
Recently I have a very good time playing the pentesting.cloud CTF and in this blog post I want to start a new walkthrough series of IMHO the most interesting challenges. I’ll start from the hard challenge named “Open To The Public”.
Let’s get it started!
This challenge doesn’t require any setup and at the first glance its description doesn’t provide much information:
No files are required for this challenge. The flag is an AWS Access Key.
The access key is NOT on this domain, do not try to enumerate/hack this site or you will be permanently banned.
There are multiple AWS resource types which can be made public. Scott Piper created the list of such resource types which can be found here. But to be able to find anything related with the challenge we need at least the AWS Account ID. If you’ve already finished any other pentesting.cloud’s challenge (for example the Intro challenge) you could spot that all files related with challenges are stored in the S3 bucket named pentesting-challenges-public. There’s an interesting research about determining AWS Account ID from the public bucket name 🤯 The research authors also published the open-source tool which does the magic for you. So let’s try it:
Now let’s check if the same account was used to share something else than just objects in the S3 bucket. Let’s start from looking for the public EBS snapshot (my first guess was EBS, because few years ago I created a similar CTF challenge). You can use the AWS Management Console to search through public EBS snapshots. Additionally, you can use the filter Owner = 943126763185 :
Bingo!!! As you can see above, there’s publicly shared EBS snapshot. Copy the snapshot ID and let’s explore its content.
Exploring the EBS snapshot
First of all you need to have a running EC2 instance (a free tier t2.micro instance with default settings will perfectly works here). However, you cannot directly attach the snapshot to the EC2 instance. You need to firstly create an EBS volume from the snapshot (please note that the volume has to be created in the same Availibility Zone as your running EC2 instance; otherwise you won’t be able to attach it). To do it, go into into the AWS Management Console and then: Service -> EC2 -> Volumes -> Create Volume -> Specify custom snapshotid… and provide the ID of the shared snapshot:
Once the volume is created, now it’s time to attach it to the running EC2 instance (in AWS Management Console: Service -> EC2 -> Actions -> Attach volume and choose here your EC2 instance ID):
Then log in to your EC2 instance (in my example I used AWS Session Manager), find attached volume (command: lsblk) and mount it to your file system (command: sudo mount [device] [mount point]):
Intuitively I went to /home directory. In the .bash_history file you can see that the ssm-user used the OS root user:
So let’s check the root’s .bash_history file:
Hmmm… still don’t see a flag, but at least I can see a date when all those actions were taken (please note that based on the output of ls -al command you can find out that the .bash_history file was modified on 24ᵗʰ August). So instead of inspecting all files in the mounted volume let’s filter out only those which were modified after 23ʳᵈ August (you can do it by running the following command: find /mnt/ -type f -mtime -xx where -xx is the number of days when files were modified). That resulted in finding 165 files.
From the challenge description we know that:
“(…) the flag is an AWS Access Key”
In the official documentation you can find information that the AWS Access Keys use either AKIA or ASIA prefixes. If you run grep ^AKIA against all the files modified after 23ʳᵈ August you’ll finally find the flag in the /mnt/var/lib/amazon/ssm/i-022903e02a0fed192/session/orchestration/sso-admin-087e79117eb921608/Standard_Stream/ipcTempFile.log file:
As you can see all the SSM session’s commands and their outputs are stored locally in the file in
/var/lib/amazon/ssm/[instance ID]/session/orchestration/[SSM session ID]/Standard_Stream/ipcTempFile.log
The logs can be easily revealed by anyone with permissions to the shared EBS snapshot. In other words any retrieved or passed as parameters secrets can be unintentionally exposed via the local SSM logs.
Alternative solution
The flag can be also retrieved in a different way. Let’s take a look one more time on the/mnt/root/.bash_history file, specifically the last actions taken by the root user :
# cat /mnt/root/.bash_history
...
python3 flag.pyc
rm -f flag1.zip
rm -f flag1.bz2
rm -f flag.pyc
rm -f flag.py
ls
rm -f flag*
ls
cd ec2-user/
ls
rm -f *
ls ../ssm-user/
exitAs you can see the flag* files were removed. But does it mean they were permanently removed? If you read the official whitepaper “Overview of Security Processes” you can read there that:
An EBS snapshot is a block-level view of an entire EBS volume. Note that data that is not visible through the file system on the volume, such as files that have been deleted, may be present in the EBS snapshot.
That means that I should be able to restore removed files. To test it I’ll use the PhotoRec tool, which is a free file recovery tool. It can be easily installed on Amazon Linux instance using the following commands:
# amazon-linux-extras install epel -y
# yum update -y
# yum install testdisk -yLet’s run the PhotoRec and choose the mounted volume to restore removed files from it:
As the volume is mounted as the XFS file system you won’t see the restored filenames (EXT4 would work better here). However, as we know that the flag is an AWS Access Key we can search through all the restored files. As you can see below the flag was “injected” in the Lorem Ipsum text:
Conclusions
The “Open To The Public” challenge is not only a great fun but also focuses on the important security risks. We can learn from it that:
- all the SSM session’s commands and their outputs are stored locally,
- removed files from EBS volumes can be restored (the EBS volumes are wiped after termination).
Stay tuned and soon I’ll publish more walkthroughs of pentesting.cloud challenges 😉
