DEV Community: Manuel Benz

How to Prevent Code Injection Vulnerabilities in Serverless Applications (Part 2/2)

Manuel Benz — Thu, 11 Feb 2021 10:14:01 +0000

This article is Part 2 of a series. Here, I’m going to explain how to secure Serverless applications from injection attacks using AWS Web Application Firewalls (WAF).

In Part 1 I introduced ServerlessGoat, an intentionally vulnerable serverless MS-Word .doc to text converter service. I explained how to exploit its code injection vulnerability and how to fix the vulnerability by replacing an invocation of the command-line tool cat with a proper JS library to download the MS-Word document. Furthermore, I shortly introduced input validation with denylists, i.e., excluding inputs that contain specific characters or match a certain format, and allowlists, i.e., only allowing inputs with a certain format or input that matches an item in a given list of constants. Let’s dive deep into how AWS WAF can help us implementing allow-/denylists for input validation!

If you missed out on Part 1, feel free to catch up!

Input Validation using AWS WAF

Input validation can of course be implemented in the serverless function directly — and should be according to security best practices. However, serverless infrastructures often contain a plethora of different functions that might all profit from similar input validation in which case it makes sense to use a central point for additional pre-sanitization.

Fortunately, with Web Application Firewalls (WAF) AWS proposes a means to conduct input validation for multiple functions even before they are invoked at all. WAFs can be attached to API gateways and Load Balancers and already allow the use of pre-configured rules for the OWASP Top-Ten as described in the corresponding whitepaper.

Implementing a Denylist with AWS WAF

Using WAF, it is straight forward to implement a basic denylist approach and attach it to the ServerlessGoat API gateway. WAF specifications can be created with the AWS console, CLI, and REST API. For the sake of simplicity, I’m going to explain how to setup WAF in the AWS console. This allows for easier testing and playing around with WAF using a proper graphical user interface.

After deploying the ServerlessGoat application, let’s follow the documentation to set up an Access Control List (ACL) for WAF in the created API gateway. Like in traditional firewalls, ACLs are lists that allow/prevent access from specific sources to specific assets based on rules.

Step 1: Open the API Gateway console for the serverless-goat API -> go to Stages -> open Prod stage -> create a new Web ACL

Step 2: In the Web ACLs console, press Create Web ACL. Fill-in metadata for the ACL and press Add AWS resources

Step 3: Select the Prod and Stage stages of the serverless-goat API gateway ->Press ADD -> Press Next to add rules to the ACL

Step 4: In the Add rules and rule groups view, click on Add rules and then select Add my own rules and rule groups

Step 5: Use the visual rule editor to create a rule that applies if a semicolon (;) character is contained in the document_url query string parameter -> Since we are building a denylist, make sure to block the request if the rule applies -> Add the rule

Step 6: Make sure to allow all requests that do not match any rule! We want to only exclude requests where the document_url query string parameter contains a semicolon. -> Press Next -> Next -> Next -> Create the web ACL

AWS will take some time to set up the ACL and attach it to the API gateway stages. After the creation is completed, we can test if our denylist behaves as expected.

Browse to the Prod stage view of the serverless-goat API gateway. You can now see the ACL being correctly assigned to the stage. Expand the /api/convert endpoint to acquire the endpoint URL of the stage:

Using this URL, we can now test our denylist. If we propose a valid MS-Word document to the document_url parameter, we get back the contained text as plaintext:

Trying to attack the Goat with https://foobar;cat /etc/passwd # now results in Forbidden, as our WAF has successfully detected the semicolon char in the input parameter:

Pitfalls of Denylists

Are we secure now? NO! 😦 We just prevented the specific attack where commands are chained with a semicolon. However, bash at least allows for a bunch of other possible solutions to chain and inject additional commands into the OS command, e.g., using && or || (to only name a few).

If we now propose https://www.puresec.io/hubfs/document.doc> /dev/null && cat /etc/passwd # as document_url, where we throw away the output of the curl command by directing it to /dev/null and then chain the invocation of cat with the && (and) operator, we are still able to exploit the command injection vulnerability to read /etc/passwd :

This boils down to a general problem with denylists: It is very hard to come up with all possibly problematic inputs and specifically filter out requests that contain those. It’s almost guaranteed that an attacker will be able to find a proper input that circumvents the rules of a denylist by using specific publicly accessible enumeration tools. But how to properly validate the input then? Use allowlists to only allow very specific input formats and deny everything else!

Implementing an Allowlist with AWS WAF

Implementing allowlists with WAF is as easy as implementing denylists. For our allowlist, we want to come up with a pattern that is as specific as possible to only match a proper input document. Let’s, therefore, create a regular expression to match a valid document_url.

For this, we again open the AWS Firewall Manager -> Select the Regex pattern sets view -> Press Create regex pattern set

We now create a regular expression in our region that only matches URLs starting with http(s), ending with .doc, and nothing in between but plain words and slashes (/). Thereby, we especially prevent an attacker from adding any bogus input before, after, or in between the provided URL:

Now, we want to add the previously created regular expression as a filter to our ACL:

Go to Rules tab -> Add rules -> Add my own rules and rule groups

The setup is similar as in Step 5. This time, however, we are using our previously created regular expression as matcher:

Remember, we are building an allowlist. Thus, make sure that this time, to allow requests where the document_url query parameter matches this rule.

To finalize the allowlist, we now have to make sure that our previously created rule from the denylist is not active anymore and we only allow requests that match our newly created Allow_Valid_URLs rule. Therefore, after creating the new rule, delete the old Deny_Command_Chaining rule and set the default web ACL action for requests that don’t match any rules to Block.

The rule section of our ACL should now look like this:

Since we edited the existing ACL that is already bound to our API gateway, we do not have to conduct any further steps. Let’s test our allowlist:

As we can see, none of our attacks is working anymore and we are still able to use the service with a valid document_url. 👍

Are we secure now? Well, ServerlessGoat has quite some more issues waiting to get fixed — at least we secured our app from Command Injection Attacks now! 🛡

Keep in mind, however: Realistic apps are much harder to overlook and you can never be sure that your WAF restricts bogus data to flow to your function through every possible channel. Therefore, in addition to a WAF, never trust the inputs to your lambda functions and implement additional counter measurements in your code!

Fixing the vulnerability is one thing. But how to find it in the first place?

We develop CodeShield to help developers finding and fixing vulnerabilities in serverless applications. Check out our product tour to try it yourself!

About

Manuel Benz is co-founder of CodeShield, a novel static security testing tool focusing on in-depth program analysis of Microservice architectures and Serverless applications. Prior to the start-up, Manuel worked as a researcher on combinations of static and dynamic program analysis for vulnerability detection at the Secure Software Engineering group at Paderborn University. Manuel is still actively maintaining the Soot static program analysis framework for Java.

How to Prevent Code Injection Vulnerabilities in Serverless Applications (Part 1/2)

Manuel Benz — Thu, 03 Dec 2020 13:01:46 +0000

Recently Serverless application architectures are a trending model for web application development. This is hardly surprising since serverless backends can help to save huge costs for hosting and maintaining web applications. Instead of having full-blown servers continuously running and producing costs, serverless functions can be fired only on-demand, when there is load for the server to process, and are paid-per-use only for the time of their execution.

Like usual web applications, serverless applications are equally affected by security vulnerabilities. Indeed, the OWASP Foundation has published an interpretation of the OWASP Top-10 list of Web Application Security Risks specifically for serverless. Alike, OWASP has published ServerlessGoat, a
serverless version of their (in-)famous WebGoat application. ServerlessGoat is an intentionally vulnerable serverless application containing instances of eight of the ten most critical serverless application vulnerabilities.

With ServerlessGoat, OWASP not only ships an application to showcase how not to build a serverless application but also proposes a great and in-depth explanation on how to attack it. Unfortunately, the authors miss the opportunity to explain how to fix or (better) even prevent these vulnerabilities in the first place.

This article is Part 1 of a series. Here, I’m going to explain how to exploit the OS Command Injection vulnerability in ServerlessGoat and how to generally fix it. In Part 2 of the series, I then show how to secure applications from injection attacks using AWS Web Application Firewalls (WAF).

Exploiting ServerlessGoat code injection

ServerlessGoat implements an MS-Word .doc to text converter service. For this, the app accepts a user-supplied URL to an MS-Word document and processes as follows:

Download the document via the supplied URL using curl OS-command (line 3)
Convert it to text using the Linux catdoc tool (line 3)
Store the resulting text in an S3 bucket (line 8–14)
Respond with an URL to the generated text in the S3 bucket (line 16–21)

A user can then access the plain-text conversion of her supplied MS-Word document via the returned S3 URL.

Main Logic of ServerlessGoat

Looking at the implementation of this procedure, one quickly notices that the proposed document_url query string parameter is directly used in an OS-command invocation (Line 3) without any means of proper input validation.

As described in Lesson 2 of the author’s exploitation guideline, an attacker can thus craft a document_url query string parameter that leads to completely ignoring the piped catdoc invocation and instead execute an arbitrary OS-command. Even more, the attacker can then also acquire the output of the executed OS-command by accessing the proposed S3 bucket URL.

For example, providing https://foobar; cat /var/task/index.js #as document_url will make the shell first curl https://foobar, then cat the source code of the lambda function. The remainder of the original command
(catdoc) is ignored due to the out-commenting (#) of everything after the cat command.

By reading the acquired contents of the index.js file from the S3 bucket, an attacker is thus able to completely reverse-engineer the lambda function and search for further possibly exploitable weaknesses in the code. But that’s just
one possible attack, an attacker could also exploit the vulnerability to spawn a reverse shell, get access to environment variables, read the /etc/passwd file,
run some privilege escalation attacks, etc.

Let’s try it!

First, we deploy ServerlessGoat in our AWS account.

Note: Unfortunately, the official ServerlessGoat is currently not usable due to running on a deprecated NodeJS runtime. As an alternative, we published a Java version of the application which can be used as a replacement. You can deploy it here.

Second, let’s try the service with a proper MS-Word document:

Works! Let’s see if we can run a simple command injection attack to get some information about the users on the target machine by printing the /etc/passwd file:

Perfect! By using https://foobar ; cat /etc/passwd # as document_url, we are able to see all groups and users on the system.

Now that we know we can execute arbitrary commands on the machine, let’s try to list the directory tree of the server with ls -LR:

It seems that the server stores it’s used libraries in the .lib directory.
Having a list of all used libraries, we could search for more attack vectors by exploiting known vulnerabilities of those. A good starting point to learn more about possible vulnerabilities and exploits for those could be the National
Vulnerability Database (NVD) and exploit-db.

To find even more possible attack vectors, we could also download the server’s .class files and decompile them to learn about its concrete implementation.

Lastly, let’s see if we can learn something from the environment variables on the machine:

Ouch 😣…that’s a lot of sensitive information!

Fixing the Vulnerability

Generally speaking, such injection vulnerabilities, e.g., OS Command Injection, SQL Injection, Code Injection, XSS, etc., stem from user input being used directly in sensitive operations.

To prevent such vulnerabilities, there are two solutions, first, if possible, do not use user input in sensitive operations at all, and/or, second, validate that the user input has a proper format and is not able to exploit the sensitive operation.

Do not use an OS Command for Downloading the Document

In our ServerlessGoat example, the OS Command Injection attack is possible because the document_url user input directly flows into an OS command invocation of curl. Using curl to download the MS-Word document seems to rather be a convenience-driven decision. By no means, it is necessary to use curl to download a file. Instead, we can just use some JS native way to acquire a web-resource and store it in the file system, e.g., with the request library, and afterward propose this downloaded file to the catdoc command. Using this approach, no user input will directly flow into the OS command anymore. Even more, with such a fix, proposing some bogus document_url as input will rather lead to the request API failing fast due to not being able to acquire any proper web-resource.

Note: Indeed, AWS has recently removed the curl command from their amazonlinux:2 runtime. This certainly helps to prevent OS-Command Injections like the one in ServerlessGoat since users are rather forced to use a proper library for sending web requests instead of curl.

What if I need to pass User Input to a Sensitive Operation?

In certain scenarios, one will not be able to completely prevent using user input in an OS Command, e.g., due to the need for a specific application which’s functionality cannot be mimicked by a third-party library or if the runtime-performance that only a binary application can provide is required.

In such cases, it is important to properly validate the user input before it is used in the OS command. Such validation is usually done by using either denylists, i.e., excluding inputs that contain specific characters or match a certain format, or by using allowlists, i.e., only allowing inputs with a certain format or input that matches an item in a given list of constants.

In Part 2 of this series, I will explain how to set up AWS Web Application Firewalls (WAF) to secure your serverless application from injection attacks.
The AWS WAF proposes a deny- and allowlist approach to conduct exactly such input validation for multiple functions even before they are invoked at all. 🛡

Fixing the vulnerability is one thing. But how to find it in the first place?

We develop CodeShield to help developers finding and fixing vulnerabilities in serverless applications. Check out our product tour to try it yourself!