FL(AWS): Basic AWS Misconfigurations and Exploitation- Part 1

The flAWS Challenge

FLAWS is fun and interesting series of CTF-like challenges based on AWS Cloud Environment. It focuses on how simple misconfigurations or mistakes that may lead to Data Breach of the Cloud Service Customers. There are total of 6 level in this challenge, and each challenges are based on different topics in the AWS cloud environment. The best thing about this challenge is that it is completely FREE! You don’t need to spend a penny while completing this challenge, although, you will need an AWS free-tier account to complete some of the levels. You can find this challenge hosted on: flaws.cloud

Since this blog would have been very lengthy, I have divided this challenges in two parts, the next three level of this challenges’ write up is available here.

Now, lets get started with the first level of this challenge.

Level 1

Enumeration

This static web page maybe be hosted in an s3 bucket, therefore, static analysis or any other traditional web application analysis was not be very helpful here. So, we can start with the Domain reconnaissance with nslookup tool, again performed reverse DNS lookup which gave me the Domain Name of the server.

We get two valuable information from the Domain Recon, which were, Confirmed that this static web site is hosted on s3 bucket and the region of this server (us-west-2).

Bucket Enumeration

I tried to list the contents of the buckets using aws-cli tool to check if it was publicly accessible, but it asked for user credentials.

Since we didn’t have any user credentials for now, I tried using –no-sign-request flag which does not require credentials to access the bucket, which was successful and the contents of bucket was listed.

The “secret-dd02c7c.html” seemed interesting, we can download that file from the bucket using the following command.

That secret file contained the link to advance to the Next Level.

Takeaway

On AWS S3 buckets can be used for various usage and functionalities which also includes hosting static web page similar to github.io. While using the s3 bucket some developers or cloud users sets them up without proper implementation of permissions (Making it accessible to “Everyone”), making it vulnerable to unauthorized access of the bucket’s content. Just like web applications should not allow directory listing, s3 bucket also should not allow bucket listing.

Level 2

Enumeration

Since this is similar to previous challenge, we need to perform DNS recon like before.

Bucket Enumeration

I tried performing --no-sign-request for this challenge as well, but it was not possible because the permission is set for this challenge.

According to the description, we will need an free-tier AWS account for this challenge. We can get a hint that (maybe) any valid AWS user can list the content of the bucket. I configured my AWS account in the aws-cli.

Now we can successfully access the content of the bucket using the AWS profile we created just now.

Again, Download the “secret” file from the bucket and open it on the web browser, which will contain the link to the next challenge.

Takeaway

This another AWS s3 bucket vulnerability/misconfiguration where developers or cloud users sets the accessibility permission of the bucket accessible to “Any Authenticated AWS users”, which they might think is accessible to the users of their account, but actually makes it accessible to anyone that has an AWS account.

Level 3

Since we are still dealing with s3 buckets, lets start with DNS recon and reverse DNS lookup to get the domain name.

Bucket Enumeration

This bucket was also accessible to everyone and no sign-in was required. But this time it was different. There was no any “secret” file this time, rather it contained another interesting file this time, which was “.git”.

We can download all the contents in the s3 bucket and we can further analyze the “.git” directory with git tool, to check if there any valuable or sensitive information or data saved in the git logs.

GIT Analysis

Using the git log command we can view the history of the repository like the changes committed by the developers or cloud users. Analyzing the logs, we can get a hint that a user had uploaded something sensitive in the first commit and which was removed in the current commit.

It’s not a problem! git is an awesome tool, we can even compare the commits and view the changes that were made between the two commits. And guess what? We found the access key and secret key of another user which was removed.

Configuring Another User Profile

We can use those found credentials to configure new profile in the aws cli.

Recalling what the description said, maybe this compromised user has permission to access other buckets. which was indeed true, we get the link to the other buckets from here.

Takeaway

Developers or cloud users often mistakenly leak AWS keys in the public and try to cover up their mistake without revoking the keys. One should always delete or inactive the AWS and Secret keys that may have been leaked or misplaced.

Until Next Time..

Remaining three Levels of this challenge will be available at the next part of this series, which is available here.

Thank you for Reading.