AWS Lambda is a widely used cloud service which allows customers to create event driven serverless functions of short duration. To find out whether a bad lambda function could lead to AWS account takeover, I created some code to deploy one and uploaded to GitHub.
The code returns the environment variables of the container in which the lambda function is being executed - this simulates what could happen if the Lambda function was vulnerable to an injection attack or a malicious dependency was included in the code.
An attacker can simply take these credentials and use the AWS command line to perform any actions within the AWS account which are allowed by the Identity and Access Management (IAM) role assigned to the Lambda function. In my example code, this is access to AWS Secrets Manager. In the worst case, it could be access to IAM allowing an attacker to set up their own administrator account.
So the answer is YES - if the AWS Lambda function is vulnerable, and the assigned role has excessive permissions, a bad Lambda function can lead to AWS account takeover.
To protect an AWS account from takeover due to bad Lambda functions, see my blog 10 Steps to Lambda security. Click on the read more link below for screenshots and technical details.
I deployed the bad lambda code using Terraform, then browsed to the API Gateway URL. This invoked the Lambda function and returned the environment variables of the Lambda container:
Next, I copied the AWS Access Key, AWS Secret Access Key and AWS Security Token values into a new profile in my AWS command line credentials file:
Finally, I used the command line to list secrets within AWS Secrets Manager, and then obtained one of the secret values:
If you want to try this yourself, clone the repository, install to a development AWS account where you're not already using AWS Secrets Manager, and follow the instructions in the README.
Paul Schwarzenberger is a Cloud Security Architect and DevSecOps specialist