AWS Pentesting: Cybr’s Access Secrets Manager via Lambda Function with LFI lab

Introduction

This walkthrough covers the Cybr’s Access Secrets Manager via Lambda Function with LFI lab. Lambda is a serverless compute service offered by AWS that automatically runs your code in response to events, scaling as needed and charging only for the compute time used. Lambda can be exposed to the internet or private.

The lab features a web application powered by Lambda that is vulnerable to a file inclusion/path traversal vulnerability.

File Inclusion vulnerability allows an attacker to include a file, usually exploiting a “dynamic file inclusion” mechanisms implemented in the target application. The vulnerability occurs due to the use of user-supplied input without proper validation.

Due to command injection, we can then get the temporary tokens of the Lambda service. This token has access the Secrets Manager, an AWS offering that securely stores, manages, and retrieves sensitive information like API keys, passwords, and database credentials.

Starting the lab generates a unique Lambda endpoint of the web app.

The app has several input fields like “Names”, “Emails”. etc in “Create Profile” function. Its has one input field in the “Find Employee” function/feature ( at least in the UI).

We can try to create a profile. The app returns an employee code which is 1001.

Interestingly, this 1001 employee code is not found when we used the “Find Employee” function.

Since this 1001 could be referencing something like an employee information, we can then try to change this to other numbers like 1002 or 1000 and check if there are changes in the response. If there are changes, and the response shows sensitive details of other employees, we would have an IDOR vulnerability, a type of Broken Access Control vulnerability. We can also automate this by using Intruder in Burp.

Next, we would have to check for other injection vulnerabilities ( SQL Injection, Command Injection, etc) on several input fields in the app. We can do this manually and using tools for automated testing.

For the interest of time, lets focus on file inclusion since the lab mentioned that its vulnerable to LFI.

Lets send the HTTP request to Repeater and Intruder.

In Intruder, I selected “Sniper attack” for the “Attack type”. For payload type, I selected “ Simple list”. I then selected “Fuzzing — path traversal” payload from the “Add from list” ( available only on Burp pro) dropdown. If you are not using Burp Pro, you can use different payloads from Github like the Intruder payload for lfi/traversal of Payloadallthethings.

We can click ‘Start attack” and wait for the tool to finish. We can then filter the results by Status code. We are only interested with 200 response. Lets also check the length that is/are different from the rest of the response.

The two images above show that “ ../../../../../../../../../../../../etc/hosts “ works

Lets then go to Repeater and use the same payload. We can also try other payloads that we know will most likely work such as “ /etc/passwd “ Note that if payload wont work, try encoding it. The command as shown below is successful.

Thinking this is a Lambda service, we can use “ /proc/self/environ” to try to get the STS temporary credentials. “ /proc/self/environ” is a virtual file in Linux that contains the environment variables of the current process

Lets configure this credentials in our attack machine to check the permission we got.

As usual, we can use aws-enumerator again, which we can get from this link, to bruteforce for permission available for the token. We can cross check the findings with other tools such as enumerate-iam.

./aws-enumerator cred -aws_access_key_id  <key> -aws_secret_access_key <secret> -aws_session_token <token>
./aws-enumerator enum -services all -speed slow
./aws-enumerator dump -services sts,secretsmanager

The aws-enumerator result above shows that we have permission to ‘ListSecrets” in the Secret Manager service which is most likely the secretsmanager:ListSecrets permission.

You may also add the region in the “.env” file that was created by the aws-enumerator tool.

Running enumerate-iam tool just shows that we have the permission to the following “dynamodb.describe_endpoints” , “sts.get_caller_identity”, “secretsmanager.list_secrets”.

enumerate-iam.py --access-key ACCESS_KEY --secret-key SECRET_KEY --session-token SESSION_TOKEN --region <region>

(Note that if you wonder why the token is now different, this is because I requested another token from Lambda.)

The image above demonstrates that using the dynamodb.describe_endpoints provides limited information and is not particularly useful for identifying potential attack vectors

As part of my methodology, I would again run Cloudfox with “inventory” option ( or Prowler with “quick-check” option) to see the services allowed in the current IAM access from a high level perspective.

./cloudfox aws --profile cybr inventory

The image above shows that Secret Manager is indeed used and deployed in us-east-1.

To confirm our permission to the service, lets run the “list-secret” secretsmanger command below to list the secret ids.

aws secretsmanager list-secrets --profile <profile name>

Having obtained the secret id, run “get-secret-value” to try to read the secret retrieving the flag.

secretsmanager get-secret-value --secret-id <ID> --profile <profile name>
secretsmanager get-secret-value --secret-id CYBr<redacted> --profile cybr

References:

https://cybr.com/hands-on-labs/lab/access-secrets-manager-via-lambda-function-with-lfi/
https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_Local_File_Inclusion#