Lambda SQLi Allows AWS Red Team to Access Secrets Manager

Overview

This writeup documents the exploitation of a SQL injection vulnerability in an AWS Lambda function to escalate privileges and extract a secret from AWS Secrets Manager. The scenario, designed for AWS red teaming, highlights a critical path from application-level vulnerability to cloud infrastructure compromise.

Reconnaissance and Initial Access

The exercise began with reconnaissance using Pacu, an AWS exploitation framework. The IAM enumeration module identified 22 roles and 3 policies within the target account. This initial phase is crucial for understanding the existing permission landscape and identifying potential pivot points.

The key finding during this phase was a role named invoker-lambda-sqli-privesc-*. The compromised user was explicitly allowed to assume this role via the sts:AssumeRole action. This established the first link in the privilege escalation chain, allowing the red team to move from their current, likely limited, permissions to a more privileged context.

To understand the capabilities of this newly assumed role, the team retrieved the associated policy JSON documents using the AWS CLI command: aws iam get-policy-version --policy-arn --version-id. Three policies were identified, each detailing specific permissions granted to the role.

Exploiting the SQL Injection

The core vulnerability exploited was a SQL injection flaw within a specific AWS Lambda function. This function, likely designed to interact with a backend database, failed to properly sanitize user input. An attacker could craft malicious input strings that would be interpreted as SQL commands rather than data.

The attack vector involved sending specially crafted payloads through the Lambda function's API endpoint. By manipulating the input that the Lambda function passed to its database queries, the red team could execute arbitrary SQL commands. This is akin to tricking a librarian into fetching books not on your request list, but rather any book in the entire library, by subtly altering the card catalog request.

The immediate goal was not just to manipulate database data, but to leverage the SQL injection to interact with the underlying operating system or AWS service metadata exposed to the Lambda execution environment. Many serverless environments, including AWS Lambda, expose instance metadata services that can reveal information about the execution environment, such as temporary credentials or IAM role information.

Privilege Escalation via Lambda Execution Role

The critical step was to identify if the Lambda function's execution role had elevated privileges. If the Lambda function was configured with an IAM role that possessed permissions beyond what was necessary for its intended operation, a SQL injection could become a gateway to broader AWS account compromise.

The red team focused on whether the Lambda execution role could interact with AWS Secrets Manager or other sensitive AWS services. By injecting commands that queried the instance metadata service, they aimed to retrieve the temporary credentials associated with the Lambda function's execution role. Once these credentials were obtained, the attacker could then use them to impersonate the Lambda function and perform actions permitted by its IAM role.

The vulnerability in the SQL query allowed the injection of commands that could, for example, initiate an HTTP request to the AWS instance metadata endpoint (e.g., http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME). If successful, this would return the temporary security credentials for the Lambda execution role.

Accessing AWS Secrets Manager

The ultimate objective was to access sensitive information stored in AWS Secrets Manager. The SQL injection, by enabling the impersonation of the Lambda execution role, provided the necessary permissions to query Secrets Manager. If the Lambda function's execution role had been granted permissions like secretsmanager:GetSecretValue, the attacker could now leverage these permissions.

Using the obtained temporary credentials and the aws secretsmanager get-secret-value command (or equivalent API calls), the red team could retrieve the secret. This secret could be anything from API keys, database credentials, or other sensitive configuration data, effectively completing the attack chain from a web application vulnerability to a cloud secrets compromise.

Implications and Mitigation

This scenario underscores several critical security considerations for cloud-native applications, particularly those leveraging serverless technologies like AWS Lambda.

Firstly, it highlights the persistent danger of SQL injection vulnerabilities. Even in modern cloud environments, traditional application-level flaws can have direct and severe consequences on cloud infrastructure security. Input validation and parameterized queries are non-negotiable for any application interacting with databases.

Secondly, the principle of least privilege is paramount for IAM roles, especially those attached to serverless functions. The Lambda execution role should only have the absolute minimum permissions required for the function to perform its intended task. In this case, if the Lambda function did not inherently need to access Secrets Manager, the execution role should not have been granted that permission. This would have severed the attack chain, even if the SQL injection was successful.

Finally, the exercise demonstrates the importance of robust security testing, including red teaming and penetration testing, specifically tailored for cloud environments. Understanding how application vulnerabilities can be chained with cloud misconfigurations to achieve significant impacts is key to building secure cloud architectures.

The surprising detail here is not the existence of SQL injection or privilege escalation, but how seamlessly a common web vulnerability can pivot to compromise cloud-specific secrets management services when IAM roles are over-provisioned.