How to Prevent Code Injection Vulnerabilities in Serverless Applications (Part 2/2)
This article is Part 2 of a series. Here, I’m going to explain how to secure Serverless applications from …
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:
Works!
Let’s take a look at the implementation of ServerlessGoat to find the vulnerability. ServerlessGoat processes the provided URL as follows:
curl
OS-command (line 3)catdoc
tool (line 3)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 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 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 (#
).
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 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
:
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 😣…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.
This article is Part 2 of a series. Here, I’m going to explain how to secure Serverless applications from …
Checkout Serverless Goat for Java and train your security skills. The code is available under …
Recently Serverless application architectures are a trending model for web application development. This is …