By Andreas Dann | July 27, 2021
How to Exploit Code Injection Vulnerabilities in Serverless Goat
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.
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:
Let’s take a look at the implementation of ServerlessGoat to find the vulnerability. ServerlessGoat processes the provided URL as follows:
- Download the document via the supplied URL using
curlOS-command (line 3)
- Convert it to text using the Linux
catdoctool (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)
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
catdoc invocation and instead execute an arbitrary OS-command, as described in LESSONS.md
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
and then cat the source code of the lambda function.
Everything after the
cat command is ignored due to the bash comment character (
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
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
It seems that the server stores it’s used libraries in the
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
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 😣…this is a lot of sensitive information!
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 LESSONS.md.
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.