Viviry Tech | INFOSEC encyclopedia: March 2018

Now that we have the OWASP Juice Shop set up and we have our tools ready to go, let's start digging into the web app.

Environment setup

Log into the Juice Shop VM

Open up a Terminal, browse to the location of Juice Shop (e.g. Downloads/js642), type in, "npm start", and press Enter

Open up ZAP (Applications > Other > OWASP ZAP)

In ZAP, choose "Yes" (the top option) and click "Start"

Open up Firefox

In Firefox, click the three bars

Click on "Preferences"

Click on the wizard's hat (Advanced)

Click on "Network"

Click on "Settings"

Go back to ZAP

Click on the gear to access the options

Scroll down to "Local Proxies" and verify that the proxy port for ZAP is 8080

Click "Ok"

Go back to Firefox and we should still be in the settings menu

Click "Manual proxy" and configure the "HTTP Proxy" to be "localhost" on port "8080". Check the box to use the proxy for all protocols

Scroll down to "No Proxy for:"

Remove all entries in there

Click "Ok"

Close the preferences tab in Firefox

In the first Firefox tab, browse to http://127.0.0.1:3000

ZAP may take control and pop up a box talking about breakpoints. Click "Ok" if this pops up.

In Firefox, you may see a warning saying that the server was restarted and our progress from the previous session was restored. We can either close this box (by clicking on the "x") or we can delete the cookie and start fresh. Click the box to delete the cookie and start over. You'll get a warning that you need to manually restart the application to start over.

Go back to Terminal and press "Control+C" to force quit the running npm process.

Press the up arrow to quickly get the command, "npm start"

Press enter to re-run Juice Shop (by running running "npm start")

In Firefox, refresh the page (http://127.0.0.1:3000)

Go back to ZAP

We should see activity now that we're proxying our network traffic through ZAP

Click the arrow next to "Sites"

Click the arrow next to "127.0.0.1:3000"

If we scroll a little, we see interesting directories

If you click on "Alerts", you can see potential findings that were found passively

Go back to Firefox

Click on "Score Board"

The five blue boxes should still be "pressed" and showing all of the challenges. Scroll to the bottom.

We see that the RCE Tier 1 challenge involves some kind of denial of service. Now that we have ZAP running in the background, let's see if normal transactions can lead us to some kind of way forward with this.

Go back to the Terminal and press "Control+C" to force stop the JuiceShop

Microsoft Visual Studio Code

We need just one more tool in our toolbox to dive deeper into the JuiceShop. We're going to use Visual Studio Code! We're going to use VSCode for debugging this Node.js based webapp.

To install VSCode on Linux, go to https://code.visualstudio.com/docs/setup/linux

We're going to use the Red Hat instructions on this page. Do the two steps that start with "sudo" to add in the Microsoft key and their repository location.

In Terminal, type in, "yum check-update" and press Enter

In Terminal, type in "sudo yum install code, and press Enter. Follow any prompts to continue with the installation.

In Terminal, browse to the folder location of the JuiceShop (e.g. Downloads/js642)

In Terminal, type in "code ." which will start VSCode in the context of the JuiceShop application

VSCode is natively aware of Node.js applications and automatically has context of how to work with Node.js applications. We are going to use this to our advantage so we can natively run and debug this application to gain further insight into how this application works. In order to do this, we're going to examine the code that runs the web server for the Node.js application. This project uses "server" to do the heavy lifting for this application. The configuration for the web server is conveniently located in "server.js". We're going to evaluate the application from a white-box perspective where we get to see everything to better assess the security from this view.

There are a lot of ways to explore this application to derive where you can find the deserialization vulnerability. In my experience, the vulnerability lies where can you mess with data. With that, deserialization based attacks can be a problem thru APIs exposed as part of the application where data is more "freeform" (cough JSON) and more complex than a simple integer. An integer can have a simple bounds and type check to validate appropriate input. When you have JSON based data, that can be a little bit more messy depending on how data validation is performed.

Our white box assessment is going to demonstrate why JSON input can still be abused. The "classic" example of abusing JSON data to perform deserialization attacks has been demonstrated in .Net and Java based web apps. There's really no reason why this can't be an issue elsewhere like in a JavaScript based web app, like OWASP Juice Shop, which allows attackers and defenders to examine in a safe setting. Digging around in the app, if we peek at the web server running the application, we see that Swagger is used in the application. Swagger is great to help people understand your API and can give them a way to play with the API in a web based setting. The deserialization vulnerability with the JuiceShop is through the API. We'll dig more into the how and why later, but first let's explore the server configuration and get VSCode to run/debug the JuiceShop. This ability will allow us to examine step-by-step what's going on as the issue is exploited.

Running with the bulls... or VSCode

In VSCode, you may get a warning about Git in your PATH being out of date. Click "Close" if you do.

In the file explorer on the left (by default), you should see all of the files from the JuiceShop. Toward the bottom in the root directory you should see, "server.js". Click on the file to open it up on the right pane.

Scroll through the file to about line 115 (at least that's where Swagger is specified at the time of this writing in this file). We can glean that the URL endpoint for the Swagger document is "/api-docs". That'll be the URL we use (http://127.0.0.1:3000/api-docs) to see the Swagger file.

Let's run the JuiceShop through VSCode

On the left, click on the bug icon with the circle and line

In this new debugging context, you should see a green play button next to the word "Debug". Click that.

You should get an error saying that the launch.json file can't find an appropriate way to run the program. Click "Open launch.json" to delve into this file.

In "launch.js" we see a simple configuration file to run the app. In the current configuration, it's broken.

To fix this, add ".js" to the end of "app" to run our app.js file.

Click "File | Save" to save it

Click the "Explorer" icon (the top icon)

Click the "Launch Program" play button at the bottom to run JuiceShop from VSCode

We want to see the progress of launching the app through the "Debug Console". Depending on any number of factors, let's be sure we're looking at the same thing. At the top, click on "View" and select "Debug Console" to pull it up.

If everything is good (it worked on my machine!) you should see the application running as normal on port 3000 and the bottom bar should now be orange