DEV Community

Cover image for Hacking AWS Account via AWS Lambda SSRF
Sena Yakut for AWS Community Builders

Posted on • Originally published at Medium

Hacking AWS Account via AWS Lambda SSRF

Server-side request forgery (SSRF) attack is used for abusing functionality on the server to read or update internal resources. The main idea behind an SSRF attack is to manipulate the input parameters of an application that interact with external systems, such as URLs, IP addresses, or file paths. By injecting a special URL that is important for internal systems, an attacker can force an application to access an internal resource that is not intended to be exposed. Besides SSRF is very dangerous for traditional web applications, it’s also a threat for cloud resources. Today, we will see an example SSRF scenario on AWS Lambda and how it can be dangerous for your AWS environment. Let’s start together!

AWS Lambda SSRF Scenario:
1-) Let’s assume that we’ve a sample webpage that we will upload our contents to apply a job opportunity.

Job Opportunity Scenario

2-) We need to review the source code of the page. It includes a request to API Gateway endpoint to upload our CV.

API Gateway Details

3-) Let’s try to call the same API endpoint on Postman or Burp Suite. This is an expected usage of the API. But we think there is a problem to read the pdf files content because body message is not completed. But we assume the cv file is tried to read (this is a file operation). So, we can try SSRF and get some data if we are lucky. But how can we do this on AWS API Gateway / AWS Lambda?

API Endpoint on Postman

4-) In AWS Lambda, AWS credentials are stored in environment variables. To get them, you need to access a path like file:///proc/self/environ. We can try:


After we’ve tried with /proc/self/environ, we get lots of details!! Let’s analyze the response.


5-) There are lots of AWS credentials. As you see, we get DB username, password, and hostname but we have also AWS credentials. Let’s extract them and use in an AWS profile.

API Gateway Response with AWS Credentials

6-) We’ve created the AWS profile.

Creating AWS Profile via “Pentest” name

7-) You need to use get-caller-identity function to return details about the IAM user or role whose credentials are used to call the operation.

aws sts get-caller-identity — profile <your-profile>
Enter fullscreen mode Exit fullscreen mode

Image description

8-) We need to know the policies that are attached to this AWS Lambda role.

aws iam list-attached-role-policies — role-name <role-name> — profile <your-profile>
Enter fullscreen mode Exit fullscreen mode

Image description

9-) Yes, we get administrator access! 🤯 We can create an IAM user via AWS CLI.

aws iam create-user — user-name <username> — profile <your-profile>
Enter fullscreen mode Exit fullscreen mode

Image description

10-) You should create login profile with password.

aws iam create-login-profile — user-name <username> — password <my-password> — profile <your-profile>
Enter fullscreen mode Exit fullscreen mode

Image description

11-) We need to attach administrator policy to this user.

aws iam attach-user-policy — policy-arn arn:aws:iam::aws:policy/AdministratorAccess — user-name <username> — profile <your-profile>
Enter fullscreen mode Exit fullscreen mode

12-) We’ll able to access the account with administrator rights! That’s all! 🤭 🤫

Access the Account with Administrator Rights

Preventions / Recommendations:

Preventions / Recommendations SSRF

  • Validate every input.
  • Always follow at least privilege principle in AWS IAM roles.
  • Add authentication & authorization to your public API endpoints.
  • Blacklist/Prevent Unused URL Schemas (like file://)
  • For other details, please see OWASP Cheat Sheet.

Thanks for reading! Stay safe in the cloud! 🤞 ⛅️

Top comments (0)