flAWS2 – Task 4 Exploitation Guide #
This write-up walks through Task 4 of the flAWS2 challenge, where we exploit misconfigured public EC2 snapshots to extract sensitive data. Public snapshots are a recurring misconfiguration in AWS, and this task highlights why leaving them open can expose organizations to major risks.
Challenge Description #
We are given an EC2 instance hosting a page at:
4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud
The hint mentions that a snapshot of this EC2 instance exists. Our goal is to investigate the snapshot, mount it, and extract credentials that can be used to access the website.
Step 1 – Identify IAM User and Snapshot Owner #
First, check which IAM user is linked to our flAWS account:
aws --profile flaws sts get-caller-identity
This confirms our AWS identity and provides the Account ID being used.
From the output, we find a user backup with account ID 975426262029, which has been taking EC2 snapshots.
Step 2 – List Public Snapshots #
Query snapshots owned by the backup account:
aws --profile flaws ec2 describe-snapshots --owner-id 975426262029
Normally, snapshots are private. However, if shared publicly, anyone can create a volume from them—this is the vulnerability we’ll exploit.
Step 3 – Create a Volume from the Public Snapshot #
We import the exposed snapshot into our AWS account:
aws --profile default ec2 create-volume \
--availability-zone us-west-2a \
--region us-west-2 \
--snapshot-id snap-0b49342abd1bdcb89
This creates a volume in our account, based on the leaked snapshot.
Step 4 – Mount the Snapshot to an EC2 Instance #
-
Launch an Ubuntu instance in the same region (us-west-2a).
-
Attach the snapshot volume to the instance.
-
Note the device name (e.g., /dev/xvdbd).
-
SSH into the instance and list block devices:
lsblk
-
We identify the snapshot volume as /dev/xvdbd1.
-
Check its filesystem type:
sudo file -s /dev/xvdbd1
- Mount the snapshot:
sudo mount /dev/xvdbd1 /mnt
- Now the snapshot contents are accessible under /mnt.
Step 5 – Extract Secrets from Snapshot #
- Explore the mounted filesystem:
cd /mnt
ls -la
-
We discover a script: setupNginx.sh in the Ubuntu home directory.
-
Inside, we find hardcoded credentials:
-
Username: flaws
-
Password: nCP8xigdjpjyiXgJ7nJu7rw5Ro68iE8M
-
Step 6 – Login to Target Website #
- Using the recovered credentials, we log in to:
http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud
Security Takeaways #
-
Public Snapshots = Data Breach: EC2 snapshots often contain secrets (SSH keys, API tokens, config files). Making them public is equivalent to publishing them online.
-
Use Resource Policies: Restrict snapshots to specific AWS accounts instead of marking them public.
-
Audit Regularly: Use AWS Config and IAM Access Analyzer to detect public snapshot exposures.
-
Secrets Management: Never hardcode passwords in setup scripts. Use AWS Secrets Manager or Parameter Store.
With this, Task 4 is solved by exploiting a public EC2 snapshot misconfiguration and retrieving sensitive login credentials.