flAWS2.cloud
SUMMARY
flAWS2.cloud is the continuation of flAWS.cloud, an educational challenge to learn common vulnerabilities and misconfigurations in AWS. This time, the challenge is divided in two parts: offensive and defensive. We are supposed to begin as an attacker and exploit our way through misconfigurations in serverless (Lambda) and containers (ECS Fargate). Once finished, we will continue with the defensive path, where we will take the role of an investigator trying to understand how an attack happened, while learning common techniques to investigate incidents.
KEYWORDS
AWS command line, ECR, Docker, jq tool, Athena.
REFERENCES
OFFENSIVE PATH
LEVEL 1
Navigate to level 1 URL: http://level1.flaws2.cloud/
We are prompted to find a 100-digit PIN, brute forcing won't help.
Enter any PIN and capture the request with Burpsuite, we see a GET request to 2rfismmoo8.execute-api.us-east-1.amazonws.com.
Send to repeater to fuzz the application. If we send a PIN made of letters instead of numbers the application dumps all kind of information included in environmental variables.
Here we disclose the AWS credentials as well as the AWS region: us-east-1
Let's use credentials to connect to the bucket and enumerate the secrets.
Download the secret and find the level 2 URL inside the file.
In the lessons learned the author mentions 3 vulnerabilities:
Developers dumped environmental variables when error conditions occur in order to help them when debugging problems; however, they forgot to deactivate the feature after the application entered in production.
IAM role has permissions to list contents of a bucket.
Lack of user input sanitization.
LEVEL 2
Navigate to level 2 URL: http://level2-g9785tw8478k4awxtbox9kk3c5ka8iiz.flaws2.cloud/
The author provides a hint: check if other resources apart from S3 buckets, such as ECR resources, have open access.
With the AWS keys we have disclosed in the previous step we can enumerate the user ID.
Now we can enumerate the image registry, if the ECR is public, we will list the images with the following command.
The image is public so we can download it with docker pull
First log in into the ECR registry.
Now we pull the image.
Now we can run a container and open a shell to search for secrets.
In the web root directory find we find the index.htm file, that contains the level 3 URL.
Also, in the Nginx htpasswd file there are hashed credentials.
You can see the clear text password browsing the image history.
In the lessons learned, the author warns against misconfigured public resources.
LEVEL 3
Navigate to the last challenge URL: http://level3-oc6ou6dnkw8sszwvdrraxc5t5udrsw3s.flaws2.cloud/
This time we are prompted to take advantage of a proxy.
If we follow the author's hint, it seems containers running via ECS have their credentials at URI 169.254.170.2/v2/credentials/guid
And the GUID parameter is taken from an environment variable AWS_CONTAINER_CREDENTIALS_RELATIVE_URI
As a reminder, environment variables in a Linux system are stored here /proc/self/environ
First, let's dump environment variables by navigating to URL.
Look for the environmental variable containing the GUID, it should be something similar to this.
So next step would be to dump the AWS credentials using the disclosed GUID.
And use them to list the bucket.
There you find the URL for the ending screen: http://the-end-962b72bjahfm5b4wcktm8t9z4sapemjb.flaws2.cloud/
DEFENSIVE PATH
Now we take the role of a defender investigating the incident.
We have AWS credentials for "security" account as an IAM user. This account contains a copy of the logs and has the ability to assume the "security" role in the target account.
Credentials provided:
Account ID: 322079859186
Username: security
Password: password
Access key: AKIAIUFNQ2WCOPTEITJQ
Secret key: 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
Credentials give access to the security account, and you can also have access to an S3 bucket, named flaws2_logs that contains the CloudTrail logs recorded during the attack.
OBJECTIVE 1: DOWNLOAD THE CLOUDTRAIL LOGS
Start by trying the account credentials and enumerating the user.
Then connect to the S3 bucket, where you find a bunch of logs.
Just download all files.
OBJECTIVE 2: ACCESS THE TARGET ACCOUNT
Next step would be to check our access to the target account (653711331788). For this just add another profile in the config file ~/.aws/config
You also need to configure profile "security" since it will be source profile for "target_account". The final AWS config file would be something like this.
Now you can enumerate target account and verify the access.
OBJECTIVE 3: USE jq
In this challenge we are prompted to browse logs by means of the jq tool.
First step, unzip the logs to extract the JSON files.
Now you can cat the JSON with the jq tool and extract whatever field you want.
For example, to list a sequence of the events of the attack.
OBJECTIVE 4: IDENTIFY CREDENTIAL THEFT
Now we are challenged to find the credential hack by analyzing the logs.
If we search by ListBuckets events, there is an access from IP 104.102.221.250 using role level3
Using our access to the target account we get more details on the leve3 role.
This indicates the level3 role is only supposed to be run by the AWS ECS service. However, if we check the previously disclosed IP, we find this address does not belong to the AWS IP range.
So we conclude someone from outside has been able to list the buckets, since the access was made from a non-AWS IP address. Next step will be to determine how this access was possible (maybe because of a misconfigured open resource).
OBJECTIVE 5: IDENTIFY THE PUBLIC RESOURCE
Now we are challenged to identify the public resource that has been abused to initiate the attack.
First we enumerate all events recorded and we see the attacker called ListImages and GetDownloadUrlForLayer.
If we analyze the ListImages event we see the repository accessed was level2
Let's see the policy applicable to this repository.
The principal is set to *, therefore the repository is public for anyone requesting the indicated actions.
So this is the vulnerability exploited by attackers: a overly permissive public policy on the repository.
OBJECTIVE 6: USE ATHENA
In this challenge the author describes how to enumerate the logs using an alternative tool called Athena. This tool is available in the AWS console and is useful for querying the logs. To complete the challenge you will need to use your own AWS account.
Last updated