How to Exploit Code Injection Vulnerabilities in Serverless Goat

27 July, 2021 | 4 Min Read

Cloud-Native and Serverless applications are trending models for developing cloud applications as they provide opportunities to decrease costs, maintainability, and time-to-market and increase development speed. Since serverless applications and technologies (e.g., Infrastructure-as-code) are trending they are naturally a target for attackers. To account for this, the OWASP Foundation has published an interpretation of the OWASP Top-10 list of Web Application Security Risks the OWASP Serverless Top 10. Alike, OWASP has also published ServerlessGoat, which is an intentionally vulnerable serverless application to demonstrate vulnerabilities.

In the following, we will show you step by step how to exploit code injection vulnerability in OWASP ServerlessGoat Java version. This will help you to spot vulnerabilities in serverless applications easier and to avoid similar vulnerabilities when writing your own code.

Note This an excerpt of the series How To Prevent Code Injection Vulnerabilities in Serverless Applications by Manuel Benz.

Quick Start - ServerlessGoat

ServerlessGoat provides MS-Word .doc to text converter service. Users can submit an URL pointing to an MS-Word document to receive a link to a downloadable file containing the plain text.

First, we deploy ServerlessGoat in our AWS account.

Unfortunately, the official ServerlessGoat is currently not usable due to running on a deprecated NodeJS runtime. Thus, we published a Java version of ServerlessGoat. You can deploy it here. REMEMBER: Only deploy Serverless Goat into a test account and remove the application afterward!

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

Test Invoke of ServerlessGoat


Investigating the Code Injection Vulnerability

Let’s take a look at the implementation of ServerlessGoat to find the vulnerability. ServerlessGoat processes the provided URL as follows:

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

Looking at the implementation of this procedure, we can see that the document_url query string parameter directly flows into the OS-command invocation in Line 3, without any input validation.

Thus, an attacker can craft any document_url query string parameter that leads to completely ignoring the piped catdoc invocation and instead execute an arbitrary OS-command, as described in Even more, an attacker can then also acquire the output of the executed OS-command by accessing the proposed S3 bucket URL.

For example, if an attacker injects https://foobar; cat /var/task/index.js # as a document_url the shell first invoke curl https://foobar , and then cat the source code of the lambda function. Everything after the cat command is ignored due to the bash comment character (#).

Exploiting the Command Injection Vulnerability

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:

Exploit ServerlessGoat - etc/passwd

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

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

Exploit ServerlessGoat - ls

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:

Exploit ServerlessGoat - environment variable

Ouch 😣…this is a lot of sensitive information!

Further Vulnerabilities and Exploits

Feel free to play around with the further vulnerabilities that you spot in ServerlessGoat. You can find a complete list of vulnerabilities and example exploits in the official OWASP ServerlessGoat repository in the file

Fixing the Code Injection Vulnerability

If you want to find out how to fix the vulnerability, just read the first part of the series How to Prevent Code Injection Vulnerabilities. If you want to add a web application firewall (WAF) to protect your application, go directly to the second part of the series How to Prevent Code Injection Vulnerabilities using a WAF.

Related posts

Time to uplift your cloud security

See what CodeShield can do for your cloud.

Try for free
cta Image