Exploiting AWS Lambda: From Input Injection to Environment Variable Theft

TLDR: Serverless architectures are often treated as inherently secure by developers, but they are just as vulnerable to classic injection attacks as traditional servers. This post breaks down how improper input validation in AWS Lambda functions can lead to command injection and the exfiltration of sensitive environment variables. Pentesters should focus on identifying entry points that trigger Lambda execution and testing for command injection payloads that can dump process memory or configuration data.

Serverless security is often misunderstood as a "set it and forget it" configuration. Many developers assume that because they aren't managing the underlying OS, they don't need to worry about traditional web vulnerabilities. That is a dangerous misconception. When you deploy an AWS Lambda function, you are still writing code that processes untrusted input. If that input reaches a system shell or an interpreter without proper sanitization, you are looking at a classic injection vulnerability, just in a different environment.

The Mechanics of Lambda Injection

The core issue in many serverless environments is the lack of input validation at the function level. When a Lambda function is triggered by an event from Amazon API Gateway, the function often parses the incoming request body to perform some action, such as file processing or data transformation. If the code uses that input to construct a system command, an attacker can inject arbitrary shell commands.

Consider a scenario where a Lambda function takes a file path or a URL from a user request and uses it to perform a conversion. If the developer uses a function like os.system() or subprocess.run() in Python without validating the input, the function becomes a gateway to the underlying execution environment.

# Vulnerable code snippet example
import subprocess

def lambda_handler(event, context):
    user_input = event['queryStringParameters']['file']
    # The shell executes the input directly
    result = subprocess.run(f"convert_tool {user_input}", shell=True, capture_output=True)
    return result.stdout

In this case, an attacker doesn't need to break out of a container in the traditional sense. They are already executing code within the Lambda runtime. The goal shifts from gaining initial access to escalating privileges or exfiltrating data.

Exfiltrating Environment Variables

Once you have command injection, the first thing you should look for is the environment configuration. AWS Lambda stores sensitive information—such as database connection strings, API keys, and temporary credentials—as environment variables. These are accessible to the process running the function.

During a penetration test, you can use your injected command to dump these variables. A simple env or printenv command will often reveal everything you need to pivot further into the AWS account. If the function has an associated IAM role with broad permissions, those stolen credentials can be used to access other services like Amazon S3 or Amazon DynamoDB.

The impact is significant. You aren't just compromising a single function; you are potentially compromising the entire data pipeline that the function interacts with. If the function has permission to read from an S3 bucket, you can use the stolen credentials to download sensitive data directly from your local machine.

Testing for Vulnerabilities

When assessing a serverless target, start by mapping the event sources. Identify every API endpoint that triggers a Lambda function. Use Burp Suite to intercept these requests and fuzz the input parameters. Look for signs of command execution, such as time delays or reflected output.

If you find an injection point, don't stop at whoami. Test for Regular Expression Denial of Service (ReDoS) if the function uses complex regex patterns for input validation. A poorly crafted regex can hang the Lambda execution, leading to increased costs and potential service disruption.

For dependency analysis, use tools like npm-audit or OWASP Dependency-Check to identify vulnerable libraries included in your deployment package. Many serverless functions are bloated with unnecessary dependencies that increase the attack surface.

Defensive Hardening

The most effective defense against these attacks is the strict application of the Principle of Least Privilege. Ensure your Lambda functions have the minimum IAM permissions required to perform their specific tasks. If a function only needs to read from one specific S3 bucket, do not grant it s3:* access.

Furthermore, move sensitive secrets out of environment variables and into AWS Secrets Manager. This allows you to rotate credentials automatically and audit access logs. Finally, always validate and sanitize user input before passing it to any system-level function. Treat your Lambda code with the same level of scrutiny you would apply to a legacy monolithic application.

Serverless is not a security panacea. It shifts the responsibility of infrastructure security to the provider, but it leaves the application-level security squarely in your hands. If you are building or testing these systems, assume the code is vulnerable until you prove otherwise. Start by auditing your IAM policies and input validation logic today.