flAWS.cloud
SUMMARY
flAWS.cloud is an intentionally vulnerable AWS environment made by Scott Piper designed for educational purposes. According to the author "everything is run out of a single AWS account, and all challenges are sub-domains of flaws.cloud ". There are no vulnerabilities such as SQLi, XSS, etc. but AWS misconfigurations and mistakes that we can abuse to solve the challenges.
A second part is available here flAWS2.cloud.
KEYWORDS
AWS, S3 bucket enumeration, IAM, EC2, lambda function enumeration.
REFERENCES
https://tcm-sec.com/unearthing-secrets-in-git-logs/
https://hackingthe.cloud/aws/exploitation/ec2-metadata-ssrf/
LEVEL 1
We are prompted to find the first sub-domain by enumerating buckets.
Start with DNS enumeration on the domain name.
And with lookup on the discovered IP addresses. We find out the site is hosted in an AWS S3 bucket and the region is us-west-2
We can enumerate the bucket without credentials with AWS command line tool.
Or with curl using the endpoint full URL.
The AWS CLI command expects the bucket name without the region suffix, and the region parameter in the --region flag.
In fact, the command also works without region parameter.
In this case, AWS is capable of detecting the bucket location even without explicitly specifying the region. This is because it attempts to locate the bucket across multiple regions. Specifying the region explicitly ensure a faster response.
Download the secret and get the URL for the next challenge.
After completing each challenge, the author provides a brief explanation of the vulnerable misconfiguration. In this case, the S3 bucket was configured to be accessible by everyone, therefore we were able to browse it without credentials.
LEVEL 2
Navigate to level 2 URL: http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/
Here, we are prompted to do basically the same as before but as an authenticated AWS user. Therefore, to solve this challenge you need an AWS account.
Configure your AWS profile with your account's AWS keys and browse the same bucket, there you find the secret containing the URL for the next challenge.
The author explains that what was done was basically to change permissions from "Everyone" to "Any AWS authenticated user", which seems to be common. Ofter, people mistakenly think it refers to any user authenticated in their account; however, it refers to anyone that uses AWS.
LEVEL 3
Navigate to level 3 URL: http://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/
Here we are prompted to find our first AWS keys.
Let's start by listing the bucket contents.
Looks like there is a git repo, clone it with aws s3 sync
Now we can look for secrets in the commits log.
And with the disclosed AWS keys we configure a new profile.
And login and browse the bucket content, where we find the URLs for all the challenges.
In the lessons learned the author warns about credentials hard coded in source files forgotten in old revision files.
LEVEL 4
Navigate to level 4 URL: http://level4-1156739cfb264ced6de514971a4bef68.flaws.cloud/
We are prompted to get access to a web page running on an EC2 instance. A hint is provided: a snapshot was made on the EC2 instance shortly after Nginx was set up and started.
Since we have disclosed AWS key before, let's take the opportunity to enumerate current user.
And since the author mentions a snapshot was created, let's have a look at available snapshots.
The output is too large, so we need to filter the output to select only the snapshots owned by the user.
Since we know from out initial enumeration the region is us-west-2, we can now create a volume in our AWS account from the snapshot.
Next, we launch an EC2 instance in the us-west-2 region from our own account AWS dashboard. In the storage options, choose the volume you have just created and then start the instance.
Connect via SSH with your keys and mount the volume.
Nginx settings are available at this location.
This includes credentials that will allow you to unlock the next level.
In the lessons learned, the author reminds us to protect snapshots that contains secrets and credentials.
LEVEL 5
Navigate to level 5 URL: http://level5-d2891f604d2061b6977c2481b0c8333e.flaws.cloud/243f422c/
Here we are prompted to disclose information via HTTP proxy.
This definitely sounds like SSRF, so let's look for ways to disclose secrets from misconfigured AWS services via SSRF.
It can be done with curl querying certain internal IP address to discover if there is an IAM role associated to the EC2 instance.
And now check if we can steal credentials of this role.
With the stolen access key, secret access key and token we create a profile by either manually editing the ~/.aws/credentials file or just using env variables.
Now you browse the level 6 bucket URL found in the git.
The URL is in the hidden directory.
In the lessons learned, the author mentions the IP 169.254.169.254 as an address to take into account in the cloud world, as it usually can be used to disclose services metadata.
LEVEL 6
Navigate to the last challenge's URL: http://level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud/ddcc78ff/
We are prompted to abuse account attached policies.
First step would be to create a profile with the AWS keys provided and enumerate the user
In the output we see the user name.
With the disclosed username we enumerate the attached policies.
There are two attached policies. Let's enumerate first the list_apigateways policy.
It seems currently enforced version is v4, let's see what is inside this version.
It indicates this policy allows sending GET requests to rest API endpoints.
Let's enumerate the second attached policy MySecurityAudit
Find out what version v1 of this policy allows.
There are quite a lot of things allowed by this policy. For example, lambda: list * permits listing all lambda functions.
Note: if invalid signature exception is reported when issuing this command, enable clock synchronization.
Now enumerate the lambda function /aws/lambda/Level6 policy.
This reveals the rest API gateway ID s33ppypa75.
You can get stages of this API.
The stage name is "Prod".
Lambda functions are called using the rest-API-ID, stage name, region, and resource.
Which we can translate to the final URL we have to visit to finish the challenge.
Here we are prompted to visit another URL.
In the final lessons learned the author advises against setting overly permissions when defining policies.
Last updated