OWASP Juice Shop

What is the Juice Shop?

Finding public sites to practice hacking on can be difficult. Bug bounty programs are good place to your skills, but beginners will often be overwhelmed when being faced with an enterprise-level application. That’s where applications like Juice Shop come into play. Juice Shop is an intentionally vulnerable, open source web application designed to help teach beginners how to exploit various vulnerabilities and conduct a comprehensive web application penetration test while keeping it totally safe and legal!

Downloading & Setting Up Your Juice Shop

The Juice Shop GitHub page has installation instructions included, but from personal experience, installing from sources has been the easiest to set up and get going. Start by downloading the repo using the git clone command:

git clone https://github.com/juice-shop/juice-shop.git

Next we need to install NPM so we can run install and run Juice Shop. Luckily many Linux package managers make this nice and easy. In my Kali linux distro, we can do so by executing the following command sets:

sudo apt-get update
sudo apt-get install npm

Another option if you don’t want to execute things in a VM and you are running a version of MacOS, you can install homebrew and use their package manager to install NPM:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install npm

Once you’ve got everything setup, navigate to the path where you’ve install Juice Shop and execute the following commands:

cd /Path/to/JuiceShop
npm install
npm start

Note: You will only need to run the npm install command once. After the initial install, you just need to navigate to the Juice Shop folder and run the npm start command.

After the npm start command is executed, the web application will start running and you can navigate to it in a browser of your choice at http://localhost:3000

Level 1 – Nice & Easy

SCOREBOARD

Let’s knock out all the easy things first. But wait…where is all the easy stuff. Juice Shop has a scoreboard but we need to find it first! This should be fairly simple. We can use the built-in inspect element controls within most modern browsers to find a hidden endpoint. Let’s search “score” in the main.js file under the sources tab in the developer tools.

Navigate to the /score-board endpoint and boom! We’ve cracked our first challenge.

Note: You’ll see a challenge banner that appears up top. Don’t close it quite yet, we’ll need a couple for another challenge.

The score board contains a list of challenges, organized by difficulty, which we can complete to test our skills. Now that we’ve found the score-board we can sort to find all the 1-star challenges, which we’ll complete in this section.

Let’s Bully a Chatbot

Now we’re starting to take a look at the web app. First let’s pretend we’re an average customer and make an account. Nothing fancy, we can register with a fake email and name:

Logging into an account opens up some new side panel options. We can now speak with support chat.

When entering the support chat, we are met with a friendly little juice bot.

Let’s try to swindle ourselves a free discount code. The key to getting the code, is persistence. If we just keep asking, ol’ Juicy will crack.

Finding the Crypto

Similar to finding the scoreboard, we can solve the next challenge by the same method used to find the scoreboard. Navigate to the main.js file in the Sources tab in the bowser’s dev tools, search for ‘sandbox’ and cycle through the discovered options until you find the /web3-sandbox endpoint.

Hidden Blockchain

Just like these challenges that have us searching through the main.js file in the sources tab, we can search for a hidden crypto address which was not removed from the code. We don’t know what exactly to look for, so we should try a couple of keywords:

crypto, address, bitcoin, blockchain

Now all we have to do is search for these words in the main.js file and we’ve found a hidden crypto address!

We can navigate directly to this address, but the challenge states we must get the Juice Shop site to redirect us to the site. We can do so by visiting the following address:

http://localhost:3000/redirect?to=https://blockchain.info/address/1AbKfgvw9psQ41NbLi8kufDQTezwG8DRZm

And we’ve found the hidden blockchain address and solved the Outdated Allowlist challenge

Now We’re Scripting

Let’s do one more challenge before knocking out the ‘Mass Dispel’ challenge. We’re going to perform a Cross Site Scripting (XSS) attack on Juice Shop. Cross site scripting is an attack which exploit a flaw in web applications that allows a user to inject html code. The goal is the use the following payload to proc an XSS vulnerability:

<iframe src="javascript:alert(`xss`)">

But now we need to traverse Juice Shop to determine what allows user input to be reflected on the site, and more importantly where it’s persisted. Looking around on the site, there is a search function that allows users to search for products on the site. We can provide a basic query to see what the query looks like in the HTML code. We’re going to send the query with the <b> tags to test if we can inject HTML:

<b>TEST</b>

It looks like the application allows for HTML to be injected into the search field, which means we can drop our XSS payload here.

Bonus!

Let’s use the same search function to drop the following bonus payload:

<iframe width="100%" height="166" scrolling="no" frameborder="no" allow="autoplay" src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/771984076&color=%23ff5500&auto_play=true&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true"></iframe>

Strictly Confidential

Let’s see if we can find some confidential information. We need to traverse the site to see if we can find other endpoints that may allow us to view other sensitive information. Let’s check the about us page.

There seems to be a link that takes us to a legal.md file.

This legal document seems to be located at a /ftp/ directory on the web server. Let’s try accessing that parent directory by going to:

http://localhost:3000/ftp/

We see some files here, one listed acquisitions.md. Let’s see what’s in there. Oops! Looks like we found some confidential information:

❗️ Error ❗️

While we’re in this /ftp/ directory, let’s click some different file names. Let’s look at eastere.gg, huh that’s weird. We get a 403 error. And with that, we successfully get the web server to provoke an error!

Reading is Easy

One of the challenges is just to read the company’s privacy policy. To do this, you just need to be logged in as a user. Under the account drop down there’s a Privacy & Security option. Under this submenu we can view the shop’s privacy policy.

Where is the Cat?

Seems like our next challenge has to do with a missing cat. Let’s navigate to the photo wall of the application and figure out which image isn’t loading correctly.

We can take a look at code on the page by using inspect element.

We can see the src parameter path contains hashtags (#) or pound symbols for you fellow oldies out there. These characters need to be URL encoded. in order to properly render in a URL. We can use a basic url encoder to find what the value should be. You can also view W3School’s table to find single characters such as our hashtags here. Based on our quick search, it looks like the value of the hashtag needs to be replaced with %23. We can modify this value right in inspect element.

Closing the inspect element panel and we can fully see the properly loaded ferocious cat image.

Worse than 1 ⭐️

Now let’s see how we can leave a review of 0 stars. In the side panel we can select the customer feedback option, which takes us to the following page.

We can leave a nasty comment, leave the rating at 1 star, and input the correct captcha.

However, now we need to employ the use of a proxy tool. For this walkthrough, we’ll be using the community edition of burp suite, which is free. We need to use a proxy too to capture the web request sent to the server so we can modify things at the request level that we otherwise can’t modify at the user interface (UI) level.

Burp Suite has a built in web browser that we can use for this project, but you can also set up a proxy within your browser of choice which will allow Burp to capture the traffic. Drop a comment below if you want to see how to do that a few browsers, and we’ll make sure to include it in the next update on this article!

Below is the web request we capture using Burp Suite:

We see that there is a rating parameter which specifies how many stars. We can change this value to:

"rating":0

Note: Make sure to remove the parenthesis around 0.

We can forward the modified request and we’ve now left a devastating 0-star review!

Exposed Metrics

Our next challenge tasks us with looking for an exposed metrics endpoint. Within the challenge description we have a link which leads us to the GitHub page for the Prometheus tool

We don’t see much here other than a possible endpoint where the tool could be located:

/prom/prometheus

We can again, trial and error potential endpoints where the metrics endpoint could be located. Let’s try the following:

/sitemonitor /sitemon /prom/prometheus /prometheus /metrics

Sure enough, we’re able to find the metrics page here:

http://localhost:3000/metrics

Follow the DRY Principle!

Now we need to register a user following the DRY principle. The DRY principle stands for “Don’t Repeat Yourself.” In programming this extends to only prompting for information once, and using abstraction when possible. Let’s walk through the user registration process and see where we might find some repetitive areas.

We can see there’s 2 separate places where we can input a password. We can set the Repeat Password field to a different password than our initial one set in the Password field. This will successfully crack the DRY principle challenge.

Mass Dispel – Satisfaction!

By now you’ve probably racked up quite a bit of challenge notifications.

It would be tedious to close each one individually. Reading through the OWASP Juice Shop companion guide we can find a note which states we can close multiple notification by holding the Shift button when clicking the x out. Doing so the first time will solve the Mass Dispel challenge and conclude all the 1-star challenges!

Level 2 – Spicing Things Up

Are We Allowed to Do This?

Our first challenge we take on is to read the security policy of the site. This one is a bit more difficult to find than the privacy policy in the first set of challenges, but not as hard as you might think. Clicking through the side panel there’s a link to the Juice-Shop GitHub.

Once assessing the GitHub we scroll down to a file named SECURITY.MD

At the top of this file lists a website to which we can find the location of the security policy running on any instance of Juice-Shop.

Upon visiting

https://tools.jetf.org/html/draft-foudil-securitytxt-06

We are greeted with information about the security.txt file. Scrolling down we can find a table of contents with a section about the location of the file.

We can scroll down to the section where it states the security.txt file is located under the ./well-known/ subdirectory. The preceding period in front of a directory or file means it’s hidden. These can be discovered in file systems by using the -a flag or the windows equivalent in the command line.

We can access the file on our instance of Juice Shop at

http://localhost:3000/./well-known/security.txt

Leading to the solution to the challenge.

Hardcoded Failure

Our next challenge states there’s a hardcoded credential left in by the devs. We can find it by searching through the main.js file in the sources tab of our inspect element tool. We can use ‘username’ as a keyword to search for any instance of a variable used to store some kind of user. Sure enough, we find a variable called testingUsername with the values of:

testingUsername = "testing@juice-sh.op";
testingPassword = "IamUsedForTesting";

Reflect that XSS!

Our task is to find a reflected cross-site scripting (XSS) vulnerability using the following payload:

<iframe src="javascript:alert(`xss`)">

Should be simple enough. We know that there exists an XSS vulnerability in the search function of the site. However this is a DOM XSS vulnerability, so we need to look elsewhere. To find this we’ll need to do a bit of recon and find something within the normal set of operations which could be susceptible to this. We can find the potential location in the order ID parameter after creating an order.

We need to URL encode our javascript payload from

<iframe src="javascript:alert(`xss`)">

<iframe%20src%3D"javascript:alert(%60xss%60)">

Once we’ve got our encoded payload, we can replace the order ID with our payload in the URL and bam! We’ve XSS’d…ourselves!

Well Then…I Guess We’re Admin

Now we’re challenged to login as the administrator account, but there’s a twist. We’re not allowed to use any sort of credential modification or SQL injection in order to take over the account. We’ll switch tactics to utilize a brute force attack, but first we need to find some information about what the admin’s email might be. There’s an “About Us” page which lists partial email addresses on the reviews.

We can see there’s a suspected admin email

***in@juice-sh.op

We can assume the full email is

admin@juice-sh.op

From here we can head to the login page and use a proxy tool, such as Burp Suite or OWASP ZAP to capture the login POST request

Set up a brute force attack using Seclists default credentials list to attempt cracking the admin’s password. This method will take a while if using Burp Suite’s community edition, but with a little patience we’re able to find the admin’s password.

Now all we have to do is login using the admin’s credentials…

And now we’re admin.

Just Admin Stuff

Now that we’ve cracked the admin account, let’s see what stuff we’re not suppose to know about. One of the next challenges is to access the administration section of the store. After a brief look around we can guess what the administration page would be by using some common admin names. After some trial and error, we can find it at the following address:

http://localhost:300/#/administration

Bad for Business

Continuing on with our rampage as admin, our next challenge is to delete all the 5 star feedback on the site. We can see the feedback other users have left on the administration page.

Next to each review, there’s a little trash can that we can assume would delete the review.

Now it’s just a matter of methodically (or not so methodically) removing any review that has 5 stars, and we’ve successfully dropped Juice Shop’s reputation and solved our challenge.

MC Not So Safe

After logging in as the test user, we need to crack MC SafeSearch’s login. The hint takes us to a YouTube video about a password conscious rapper. We can determine the suspected password, or at least a few variations, by listening to the song and identify his email address within Juice Shop from the administration page we found earlier.

With some trial and error with variations of his password we can crack the login.

Note: You will need to use a proxy tool to submit the password, otherwise the application will URL encode the white space and the password will be incorrect

Maybe next time don’t use your pet’s name for your password…or at least rap about it on the internet.

Your Account Went for a Stroll

Our next challenge is to reset John’s password through exploiting the forgotten password functionality. This challenge requires a bit of OSINT and some tools built into Kali linux. First we need to find John’s email in the admin panel that we exploited earlier. Sure enough, after scrolling through the users we find his email on page 2 registered to:

john@juice-sh.op

We need to find something that provides some more information as to the answer to his security question. Navigate to the login page and use the forgotten password function to identify the question:

We need to figure out his favorite place to hike. The challenge hinted at using a photo from the photo wall to pull the geographical location from the image’s metadata. First we need to download the photo that we think could contain this information. Hint: it’s pretty obvious

After downloading the photo we can use the exiftool in conjunction with grep to identify the photo’s metadata using the following command:

exiftool favorite-hiking-place.png | grep GPS

Exiftool has extracted the longitude and latitude where the photo was taken. Using google maps and other online tools we can get an exact location, but we may need to pull back further to find some more prominent places. We can look around, compiling a list of places where he may be and send the forgot password request to the Burp Intruder to attempt to crack the question.

Note: Ensure the encoding of special characters is not checked, otherwise the attack will return no 200 OK responses

Once we execute the intruder request we get a 200 OK response from the phrase “Daniel Boone National Forest” and when we hop back to the web application we see a banner signifying we’ve successfully reset John’s password.

That’s Weird

Taking a second look at the response after resetting John’s password, we see a password hash. We’re not sure which hash it is, but we can use a tool called hash-identifier to get an educated guess as to what hash it may be.

hash-identifier <john's hash>

MD5 is considered an outdated cryptographic algorithm, so we can submit it through the customer feedback page and solve the Weird Crypto challenge.

200 OK: User Not Found

We’re now tasked with registering a user with an empty username and password. We can log out of MC Safe Search’s account and click the “Not a Customer Yet?” option at the bottom of the login page. The web UI doesn’t allow for us to register a user with an empty email and password. We can generate a legitimate request first and capture it using Burp.

We can remove the username and password from the post request and forward it onto the web application.

The challenge banner may not pop up, but navigating to the scoreboard, you will see the Empty User Registration challenge has been solved.

Bad Guy to Business

We’re now tasked with finding a deprecated B2B (business to business) interface that was not properly shut down. First we start searching the main.js file to figure out which function the challenge could be referring to. By Searching ‘b2b’ within the code we find a sentence explaining the file upload function under the complaint function.

Let’s navigate to the complaint section, which is available after logging in with a user, and select a file type to upload. In this case, a test.txt file.

We can see that in the code, XML is listed as an accepted filetype, but when attempting to go through the UI, it’s not listed. This indicates an area where our deprecated function may exist. To exploit this, we can create a file through the linux command line using the following command:

touch test.xml.pdf

We’ll upload this file to the complaint form, where it will be accepted before capturing the complaint request using Burp Suite.

Remove the .pdf extension from the file and forward it onto the web application. This will successfully upload a .xml file and complete our b2b challenge.

Kinda Fungible Token

The last challenge is to take over the official Juice Shop NFT (non-fungible token). To start, we need to find where the NFT is located. We can return to the main.js file in the inspect element window and do a search for “nft” within the code. After a bit of scrolling, we find a potential endpoint called juicy-nft.

The page located at:

http://localhost:3000/#/juicy-nft

We’re greeted by Juicy Chatbot informing us that we should never share our private keys or passphrase with anyone.

The page requires a private key, which we don’t have and are impossible to brute force. However, if we circle back to the administration page, there was a comment on the feedback section which was asking something related to crypto.

We can assume this seedphrase is used to access the juicy-nft page. However, we’ll need to figure out which type of crypto key we need to generate. To do so, let’s pass a test key to see if the page will provide us some information.

We need an Ethereum private key. Luckily since we have a possible seed phrase, we can generate keys using a mnemonic code converter from iancoleman.io. Copy and paste our seed phrase:

purpose betray marriage blame crunch monitor spin slide donate sport lift clutch

Selecting ETH and scrolling down to select the first private key generated.

Once we copy and paste our newly generated private key

0x5bcc3e9d38baa06e7bfaab80ae5957bbe8ef059e640311d7d6d465e6bc948e3e

We can successfully solve this challenge and conclude all the 2-star challeneges.

More to come, happy hacking!