Post

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

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

Flaws.cloud is an interactive platform created by Scott Piper of Summit Route, serving as an educational tool for Amazon Web Services (AWS) security concepts. Designed as a Capture The Flag (CTF) challenge, it offers an engaging and fun way to learn the basics of AWS security. The platform includes challenges and tutorials to enhance participants’ understanding of AWS security, covering topics like misconfigurations and defensive analysis.

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.

The Setup

For this challenge we will need to be able to interact with AWS resources. To do this we will use AWS CLI (Command Line Interface). I will install this on my kali instance, but installation should be the same for any 64-bit Linux distro.

1
sudo apt install aws

Check that it’s installed:

1
aws --version

Once it is installed, we will need to configure it. To do this you need to sign up for an AWS account (free tier is fine, we don’t need to pay anything). You can do this at their website here.

Once you have signed up for an account you will need to get your keys to use with the CLI.

Sign in to the Amazon AWS portal, click on your name in the top right and select My Security Credentials. Now click on the Access Keys (access key ID and secret access key) option. You should be prompted with creating new ones (or if you have set them up already you will see them there). When you create you will see a pop-up box, copy this info out for the next command.

Note that setting the correct permissions for the user is very important. The new user would need at least Read permissions in order to read other buckets! To be sure, set it to AmazonS3FullAccess. The logic of evaluating permissions for bucket operations is described here.

Now we can input the keys with:

1
aws configure

Now follow the prompts and put the keys. You should be ready to go! Note: For better experience use US-WEST-2 as region as that is what is used for the flaws challenge and it will save you some hassle if you forget to specify the region within a command.

Note that the above will set the default profile with those keys. You can run aws configure --profile PROFILENAME to configure a new profile. With a new profile you can use any command and specify the profile with --profile PROFILENAME. This is important for managing lots of accounts and preventing you from having to reset your defaults all the time during tests.

Level 1

There is a hint saying that this level is buckets of fun and that we need to find the first sub-domain. Lets get the IP address (A Record) of flaws.cloud

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

  > flaws.cloud
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	flaws.cloud
Address: 52.92.237.43
Name:	flaws.cloud
Address: 52.92.189.107
Name:	flaws.cloud
Address: 52.92.136.99
Name:	flaws.cloud
Address: 52.92.229.235
Name:	flaws.cloud
Address: 52.92.177.115
Name:	flaws.cloud
Address: 52.92.139.19
Name:	flaws.cloud
Address: 52.92.146.11
Name:	flaws.cloud
Address: 52.218.219.50

Now, lets do an reverse look-up on 54.231.184.251

1
2
3
4
5
6
7
8
9
  > 52.92.237.43
43.237.92.52.in-addr.arpa	name = s3-website-us-west-2.amazonaws.com.

Authoritative answers can be found from:
92.52.in-addr.arpa	nameserver = x1.amazonaws.com.
92.52.in-addr.arpa	nameserver = x2.amazonaws.com.
92.52.in-addr.arpa	nameserver = x3.amazonaws.org.
92.52.in-addr.arpa	nameserver = x4.amazonaws.org.
92.52.in-addr.arpa	nameserver = pdns1.ultradns.net.

It’s an s3 static website in the us-west-2 region.

If you using a custom domain (e.g. flaws.cloud) for you S3 hosted static site, then the bucket name must match the domain name.

This tells us the bucket name is flaws.cloud

The URL format for S3 HTTP end points are as follows: s3-<region>.amazonaws.com/<bucketname>

So given the information we have, we can tell that the s3 end point for this bucket is: http://s3-us-west-2.amazonaws.com/flaws.cloud. Browse there, and you’ll get an XML response referencing the following files within the bucket.

Or we can use the aws cli to get more information:

To start with, lets list the contents of the flaws.cloud bucket: aws s3 ls s3://flaws.cloud --no-sign-request

The --no-sign-request flag in the aws s3 ls s3://flaws.cloud command tells the AWS CLI to list the contents of the specified S3 bucket without using any authentication

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 see that contents listed includes some hints and also a secret document which is a HTML page.

Copy the html document name and append it to the flaws.cloud url like so http://flaws.cloud/secret-dd02c7c.html and browse there and you should see the following screen!

1
2
3
4
5
6
7
8
9
10
|     || |     /    ||  |__|  |/ ___/
|   __|| |    |  o  ||  |  |  (   \_ 
|  |_  | |___ |     ||  |  |  |\__  |
|   _] |     ||  _  ||  `  '  |/  \ |
|  |   |     ||  |  | \      / \    |
|__|   |_____||__|__|  \_/\_/   \___|

# Congrats! You found the secret file!

Level 2 is at [http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud](http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/)

Level 2

Now click on the link and we should be on level 2. We can see lessons learned, how to fix the issue, and the hint for level 2. This tells us its the same but with a slight twist and that we will need an AWS account.

The previous level was an s3 bucket that any internet user could list as long as they had the CLI. With this hint, it seems like if we do exactly the same (since we already set up our account), we will be able to pass the level.

List the bucket contents (note, you will need to replace the s3:// URL with the new URL for level 2 that can be seen in your browser): aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud

1
2
3
4
5
6
2017-02-26 21:02:15      80751 everyone.png
2017-03-02 22:47:17       1433 hint1.html
2017-02-26 21:04:39       1035 hint2.html
2017-02-26 21:02:14       2786 index.html
2017-02-26 21:02:14         26 robots.txt
2017-02-26 21:02:15       1051 secret-e4443fc.html

Now we see another secret, so lets browse to it as we did before (http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/secret-e4443fc.html).

1
2
3
4
5
6
7
8
9
10
|     || |     /    ||  |__|  |/ ___/
|   __|| |    |  o  ||  |  |  (   \_ 
|  |_  | |___ |     ||  |  |  |\__  |
|   _] |     ||  _  ||  `  '  |/  \ |
|  |   |     ||  |  | \      / \    |
|__|   |_____||__|__|  \_/\_/   \___|

# Congrats! You found the secret file!

Level 3 is at [http://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud](http://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/)

Conclusion

Congratulations on making it through the first two levels of the Flaws.cloud CTF challenge! You’ve learned how to interact with AWS resources using the AWS CLI, explore S3 buckets, and uncover hidden files—skills that are crucial for understanding AWS security and common misconfigurations. These are just the basics, and there’s plenty more to explore as we continue through the challenge.

I’ll be continuing the next level at next blog Penetration Testing on AWS - Part Three, where we’ll dive deeper into AWS security and explore more advanced techniques to tackle the remaining levels. Stay tuned for more, and remember: always test your own skills first before looking for solutions. Happy hacking!

This post is licensed under CC BY 4.0 by the author.