Going down the attacker path

To be honest, I wasn’t sure how to approach this one, I checked my notes from flaws.cloud challenge (the first version)
I tried looking at an incorrect submission response. maybe this is a hint after all, this follows the format for s3 bucket URL.

But I’m not allowed to access it using browser or…

via AWS CLI.
Completely out of ideas, I decided to check the hint, and then it hit me. I didn’t even try messing with the input!
It asked me not to bruteforce, but what if I try something else. In the source code, it’s parsing the input into a float value and checking if the provided input is a finite number.
I tried putting in characters and numbers greater than the 100 digit limit couldn’t break it. Remember the s3 bucket url, it was passing input through url params, I tried changing that and it worked.
Actually it didn’t it, showed me some errors but those errors exposed some sensitive information, like AWS Access ID of someone’s account, who probably has access to that bucket.

Well, that didn’t go well, I tried adding this profile to my AWS CLI but it says this access key ID does not exist. That’s because I hadn’t added the session token, if MFA is enabled then I have to include the session token in the “credentials” file as well.

However, I can’t find a bucket with this url and I do not have permission to list buckets in this account.
Maybe that’s not the bucket url…

Now that I look back at it, it was pretty straight forward.

What went wrong ?

AWS Lamba obtains IAM role credentials as environment variables. These are not supposed to be accessible but sometimes developers tend to dump these during errors to help with debugging. That’s why when I used alphabets instead of digits the website behaved pretty well and showed me a alert dialog but the url it was sending request to showed the error message and those environment variables were exposed.

The next target — Level 2

Target : http://container.target.flaws2.cloud/
For this one we already have a hint here, “ECR is named level2”.

AWS ECR (Elastic Container Registry) allows users to manage and analyse various images.

In this case, I have the name of the repository, I’ll just check if this actually exists.

After messing around with these images a little bit, I found the docker login credentials for this container.

I can use these creds to look into the docker image.

I’m pretty sure there is something useful in there I just need to format it a little bit, or better yet, I’ll just download the entire thing.
I used the credentials I found earlier to pull the entire image.

Upon inspecting the level2 image, I found several layers. I tried to extract some information from these layers using AWS CLI.

I used the “Id” of the docker image to get it’s download url, it gave me a text file, looks like a log file but in JSON format.
There it is, the password with which this image was setup, my entry point to level 3.

Moving on to Level 3

This time we are given two links, hinting towards the /proxy endpoint, which reminds me of flaws.cloud (the first part of this challenge). In level 5 I encountered something like this.

Unfortunately, that didn’t work because these are for S3 buckets, but in this case we have a container deployed on ECS. And for containers deployed on ECS, I found this on AWS Docs.

To be honest, I couldn’t understand everything that’s written here, but I’m pretty confident that I have to look for this AWS_CONTAINER_CREDENTIALS_RELATIVE_URI. Right after the magic IP (not sure if it’s called magic IP for ECS containers too) the AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variable determines the endpoint for finding credentials. In other words I have to navigate to /proxy/http://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI
These credentials are placed there for containers that need it to communicate with or use other AWS services. These are generally used for testing purposes.
Now, where are environment variables stored on a linux system ? /proc/self/environ. That’s the endpoint I checked, and there it was.