# NCS Final Project

## Goal of the Project
Statically analyse vulnerable [Juice Shop](https://github.com/juice-shop/juice-shop) web application with semgrep. Deploy the environment and exploit critical vulnerabilities, suggest possible fixes

## Responsibilities
* Daniyar Cherekbashev - Analysis and exploitation for each vulnerability
* Ali Mansour - Demo
* Gleb Statkevich - Difficulties and conclusion sections, help with deployment and some vulns

## Execution plan
First of all, we'll clone the Juice Shop repository to perform static analysis with semgrep.

84 vulnerabilities were found, 19 of which having High severity.

We will deploy [Docker Container](https://hub.docker.com/r/bkimminich/juice-shop) of the application with `docker pull bkimminich/juice-shop` and `docker run -d -e "NODE_ENV=unsafe" -p 3000:3000 bkimminich/juice-shop` (**!! IMPORTANT !!** to run with environment variable `NODE_ENV=unsafe` so that all potentially unsafe challenges will be unlocked and working) and observe, exploit, and provide remediation for the most critical vulnerabilities.

## Observing the vulnerabilities

After deploying the enivronment, we can open it at http://localhost:3000

## NoSQL Injection
The very first vulnerability with High severity that semgrep shows to us is a potential NoSQL vulnerability that might be possible at 8 endpoints.

### Description
NoSQL injection occurs when a query, most commonly delivered by an end-user, is not sanitized, allowing the attacker to include malicious input that executes an unwanted command on the database.

**CWE-943**: Improper Neutralization of Special Elements in Data Query Logic
**CVSS v3.1** score: 4.3 `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N/E:F/RC:C`

### Exploitation

Let's examine the source code of endpoint `routes/trackOrder.ts:18`

As we can see, user input is inserted in the NoSQL statement without any sanitization or validation. In this case we can simply bypass `'this.orderId === ${id}'` by making `id` variable escape the quote and evaluate to true, thus retrieving all orders from the database.
Let's find this endpoint in the application to validate our assumption.

We firstly need to create account, add shipping address and payment information with random values, then order any item.

Then, when we navigate to the order history at http://localhost:3000/#/order-history, we see that the request is made to the `track-order` endpoint with our order id

After using `'||1==1||` (escaping from the string with `'`, using `||` to always evaluate to true by using `1==1` condition after) as payload we retrieve all orders of all users from the database, including the one that we just ordered

### Remediation
To prevent NoSQL injection, it is important to validate and sanitize user input: use strict data types, filter out malicious input by using pattern matching. Also, it is important to use parameterized queries instead of dynamically constructing queries, as they were designed to specifically remove any user-interaction and separate query logic from the user input, automatically handling the proper escaping.

For this case, for a user-defined variable `id`, we can convert it to

const id = String(id).replace(/[^\w-]+/g, '')

which removes all non-alphanumeric characters from the string, making it impossible to perform injection.
Example:

## SSTI to RCE
Another finding that caught our eyes is unvalidated user input that is compiled into the template, essentially leading to SSTI vulnerability

### Description

Server-Side Template Injection (SSTI) vulnerability is a security flaw that allows an attacker to execute arbitrary code on a web server or other applications that use server-side templates. It occurs when user-supplied input is directly embedded into template variables without proper sanitization or validation. Exploiting this vulnerability can lead to remote code execution, enabling the attacker to gain unauthorized access, modify data, or compromise the entire system.

**CWE-1336**: Improper Neutralization of Special Elements Used in a Template Engine
**CVSS v3.1** score: 9.8 `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`

### Exploitation

This is how it looks in the code, template here is the variable that was passed by user from the username field in profile edit page.

User profile is located at http://localhost:3000/profile
We try simple template injection like `#{3+3}` (`#{}` is pug-specific payload) and see that 6 was successfully rendered on the page.

After searching for existing ways to exploit SSTI on Node.js, we find out that we can use `global.process.mainModule` to import `child_process` and then execute commands/spawn shell.

Let's try this simple payload
`#{var spawn=global.process.mainModule.require('child_process').spawn;var child=spawn('whoami');child.on('error', function(err){console.log(err);});}` to execute `whoami` command

It seems that it's impossible to reach RCE in this particular Docker image, as calling spawn shell comands lead to `ENOENT` error

However, file reading still works, for example, with
`#{const fs=require('fs');fs.readFile('../../../../../../../../../../../etc/passwd','utf-8',(err,data)=>{if(err){throw err}console.log(data)});}` payload

Still, SSTI is one of the most critical vulnerabilities as it typically leads to RCE in any environment with the access to shell
### Remediation
Just like in NoSQL injection, it is important to firstly sanitize user input before using it in the template. To do this, various means are possible (use of regex, white lists of authorised expressions, etc).
Additionally, it is crucial to use a secure template engine that restricts execution of arbitrary code and limits the functionality of templates.
For even more secure approach, run user-supplied data in a closed environment, where risky modules and features are disabled.

For our specific case (pug engine), it will be enough to match user input with the regex like this `/#{(.*)}/` and, if match occurs, disallow render or remove special characters from input to render the secure version of input

## XXE
Another interesting finding is the call to `parseXml()` function with the unsanitized data passed by user. This might open a potential vector of XXE attack

### Description
XXE (XML External Entity) vulnerability is a type of security flaw that occurs when an XML parser processes external entities, allowing an attacker to read files from the server. Exploiting this vulnerability can lead to sensitive information disclosure, remote code execution, or denial of service.

**CWE-611**: Improper Restriction of XML External Entity Reference
**CVSS v3.1** score: 7.5 `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N`

### Exploitation
XML seems to be parsed from the file uploaded by user

One of the places where the user is able to upload the files to the server is the complaint section at http://localhost:3000/#/complain.
If we open file upload window we see that only `.pdf` and `.zip` are probably accepted

However, if we open the DOM tree and locate file input section, we see that XML is mentioned in the label

If we open source javascript file and search for xml, we confirm that XML files are actually accepted here

Let's create file `test.xml` with the following content to test if XXE actually exists here

<!--?xml version="1.0" ?-->
<!DOCTYPE replace [<!ENTITY example "Doe"> ]>
 <userInfo>
  <firstName>John</firstName>
  <lastName>&example;</lastName>
 </userInfo>

After uploading file, open `Network` tab in devtools and find request to `file-upload` endpoint, then, open `Preview` tab

We see that `<lastName>&example;</lastName>` got successfully rendered to `<lastName>Doe</lastName>`. Now we can try something more useful, for example, reading `/etc/passwd` file
Change `test.xml` file to the following, refresh the page and upload the file again

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY>
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>

Now, we see contents of `/etc/passwd` file in the preview

### Remediation
Most XXE vulnerabilities arise because the application's XML parsing library supports potentially dangerous XML features that the application does not need or intend to use. The easiest and most effective way to prevent XXE attacks is to disable those features.

In this case, it is enough to simply parse XML document in vm and set `noent` parameter to `false`:

const xmlDoc = vm.runInContext('libxml.parseXml(data, { noblanks: true, noent: false, nocdata: true })', sandbox, { timeout: 2000 })

`NOENT` set to `true` means that no entity nodes should be created in the parsed document, meaning that every entity is expanded. By setting it to `false` XXE attacks are not possible in any way.

## Difficulties faced
1. Time constraints: with aforementioned amount of vulnerabilities to analyse and exploit, it was a time-consuming process to investigate them and suggest possible fixes.
2. Resource constraints: addressing high severity vulnerabilities such as nosql injections, SSTI to RCE required significant resources in time, knowledge, and skills.
3. Coordination challenge: divide the tasks in appropriate way and cooperate in the optimal way to reveal the strengths of each team members was a challenge at the beginning.
4. Technical limitations: During the work we encountered with limitations in terms of tools, environment. At the end, there were challenges with capturing sound for demo with a fine quality
## Conclusion
Despite of having several challenges we reached the goal that was set in the beginning - we performed statical analyse and revealed vulnerabilities with the suggestions of how to fix them. As for the resource we analysed, given the high number of vulnerabilities, especially those with high severity, it is clear that the Juice Shop web application has significant security flaws. The presence of NoSQL injections, SSTI to RCE, and XXE vulnerabilities highlights the need for thorough and comprehensive security testing and remediation.

## Demo
https://youtu.be/JuaC8C1Aw0I

## Links
https://hub.docker.com/r/bkimminich/juice-shop
https://semgrep.dev/