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.
Part | Topic | Link |
---|---|---|
Part 1 | Penetration Testing on AWS - Part One | Read Now |
Part 2 | Penetration Testing on AWS - Part Two: Flaws.Cloud Walkthrough | Read Now |
Part 3 | Penetration Testing on AWS - Part Three: Flaws.Cloud Walkthrough | Read Now |
Part 4 | Penetration Testing on AWS - Part Four: Flaws.Cloud Walkthrough | Read 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 theaws 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!