AWS Pentesting: Cybr’s Exploiting Lambda SSRF to Access S3 Buckets lab

5 min readJan 4, 2025

Introduction

This walkthrough covers the Cybr’s Exploiting Lambda SSRF to Access S3 Buckets 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 Server-Side Request Forgery or SSRF vulnerability.

SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL

Due to SSRF vulnerability, we can then get the temporary tokens of the Lambda service. This token has access to a restricted S3 bucket.

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

We can then view the source code by checking the “Page source” which source a JavaScript that performs a call to a /products endpoint.

Next, we access the /products endpoint, which reveals no sensitive information or data that could be leveraged for further attack scenarios.

Next, lets perform fuzzing on the main URL to check for other possible endpoints and parameters.

My go to tool for fuzzing is Ffuf and Gobuster, we can also try other tools for this use case.

The success of fuzzing will depend on the wordlists the we use. My go to wordlist to use are from Seclist, from Assetnote or we can also create our custom wordlist.

This this lab, we will use the common.txt wordlist from Seclist which we can get from this link.

ffuf -w wordlist.txt -u http://example.com/FUZZ
ffuf -w common.txt -u https://l5fzqzic5cpspmeplbo45ducyu0vhbyt.lambda-url.us-east-1.on.aws/FUZZ

Based on the image above, we can see the “doc” endpoint. Requesting this endpoint shows that this is the API documentation used by the app.

We can see two unique endpoint which is “/product/” and “/product-image”. The “/product-image” has a “url” parameter which possibly requests for the images that are displayed in the UI.

Seeing the “url” parameter , makes me think of testing this for SSRF or openredirect vulnerability. Some common parameters that may indicate or lead to SSRF vulnerabilities include: url, host, file, image_url, among others.

In the images below, I tried “google.com” and “website.hook” in the parameter values but it just says “no attribute “get”” error.

When we tried “http://localhost” the error is now different.

At this point, we can run an automated scan on this endpoint. We can also do test cases for different injection attacks but in this lab, we will focus on SSRF.

We can then send the request to Repeater and Intruder.

In Intruder, we tried the “SSRF target” payload” ( available only on Pro)

Running the attack yielded no results on the first attempt.

I then asked Chatgpt to create a list of top 50 possible payload for SSRF. You may try different test cases like top 100 payloads or even more :).

Running the attack again shows that when using the “file:///proc/self/environ“ the SSRF attack is successful.

We can also use tools such as SSRFmap which we can get from this link.

I used the docker option in this lab.

docker run -it -v $(pwd):/usr/src/app ssrfmap ssrfmap.py -r request.txt --ssl -p url -m readfiles -v

Using the default payload used by SSRFmap, the tool detected that the app is vulnerable to SSRF and the /proc/self/environ file can be retrieved.

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

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.