In this walk through, we will be going through the OWASP Juice Shop room from Tryhackme. This room uses the Juice Shop vulnerable web application to teach you how to identify and exploit common web application vulnerabilities. So, let’s get started without any delay.
Table of Contents
Task 1 – Open for business!
Question 2 – Once the machine has loaded, access it by copying and pasting its IP into your browser; if you’re using the browser-based machine, paste the machines IP into a browser on that machine.
Task 2 – Let’s go on an adventure!
Before we get into the actual hacking part, it’s good to have a look around. In Burp, set the Intercept mode to off and then browse around the site. This allows Burp to log different requests from the server that may be helpful later.
This is called walking through the application, which is also a form of reconnaissance!
Question 1 – What’s the Administrator’s email address?
Question 2 – What parameter is used for searching?
Question 3 – What show does Jim reference in his review?
Task 3 – Inject the juice
- SQL Injection – SQL Injection is when an attacker enters a malicious or malformed query to either retrieve or tamper data from a database. And in some cases, log into accounts.
- Command Injection – Command Injection is when web applications take input or user-controlled data and run them as system commands. An attacker may tamper with this data to execute their own system commands. This can be seen in applications that perform misconfigured ping tests.
- Email Injection – Email injection is a security vulnerability that allows malicious users to send email messages without prior authorization by the email server. These occur when the attacker adds extra data to fields, which are not interpreted by the server correctly.
Question 1 – Log into the administrator account!
Payload: ' or 1=1--
Why does this work?
- The character ‘ will close the brackets in the SQL query
- ‘OR‘ in a SQL statement will return true if either side of it is true. As 1=1 is always true, the whole statement is true. Thus it will tell the server that the email is valid, and log us into user id 0, which happens to be the administrator account.
Question 2 – Log into the Bender account!
Target email: firstname.lastname@example.org
Payload - email@example.com' --
Well, as the email address is valid (which will return true), we do not need to force it to be true. Thus we are able to use ‘– to bypass the login system. Note the 1=1 can be used when the email or username is not known or invalid.
Task 4 – Who broke my lock?!
In this task, we will look at exploiting authentication through different flaws. When talking about flaws within authentication, we include mechanisms that are vulnerable to manipulation. These mechanisms, listed below, are what we will be exploiting.
- Weak passwords in high privileged accounts.
- Forgotten password pages
Question 1 – Bruteforce the Administrator account’s password!
Target account: firstname.lastname@example.org
Go to Positions and then select the Clear § button. In the password field place two § inside the quotes. To clarify, the § § is not two separate inputs but rather Burp’s implementation of quotations e.g. “”. The request should look like the image below.
For the payload, we will be using the best1050.txt from Seclists. (Which can be installed via: apt-get install seclists)
You can load the list from: /usr/share/wordlists/SecLists/Passwords/Common-Credentials/best1050.txt
Once the file is loaded into Burp, start the attack. You will want to filter for the request by status.
A failed request will receive a 401 Unauthorized whereas a successful request will return a 200 OK.
Once completed, login to the account with the password.
Question 2 – Reset Jim’s password!
Target Account: email@example.com
Security Question: Your eldest siblings middle name?
From Task 2, we know that Jim has an interest in Star Trek.
Task 5 – AH! Don’t look!
A web application should store and transmit sensitive data safely and securely. But in some cases, the developer may not correctly protect their sensitive data, making it vulnerable.
Most of the time, data protection is not applied consistently across the web application making certain pages accessible to the public. Other times information is leaked to the public without the knowledge of the developer, making the web application vulnerable to an attack.
Question 1 – We will download the acquisitions.md and save it. It looks like there are other files of interest here as well.
After downloading it, navigate to the home page to receive the flag!
Question 2 – Log into MC SafeSearch’s account!
Youtube Video Link: https://www.youtube.com/watch?v=v59CX2DiX0Y
Target Account: firstname.lastname@example.org
Password: Mr. N00dles
He notes that his password is “Mr. Noodles” but he has replaced some “vowels into zeros”, meaning that he just replaced the o’s into 0’s.
We now know the password to the email@example.com account is “Mr. N00dles“
Question 3 – Download the Backup file!
We will now go back to the http://10.10.82.154/ftp/ folder and try to download package.json.bak. But it seems we are met with a 403 which says that only .md and .pdf files can be downloaded.
To get around this, we will use a character bypass called “Poison Null Byte”. A Poison Null Byte looks like this: %00.
Note: as we can download it using the url, we will need to encode this into a url encoded format.
The Poison Null Byte will now look like this: %2500. Adding this and then a .md to the end will bypass the 403 error!
Why does this work?
A Poison Null Byte is actually a NULL terminator. By placing a NULL character in the string at a certain byte, the string will tell the server to terminate at that point, nulling the rest of the string.
Task 6 – Who’s flying this thing?
Question 1 – Access the administration page!
- Open up Develper Tools -> Debugger
- Find the path:administrator in main-es2015.js file
Go to Login and login with the earlier grabbed creds:
- Username: firstname.lastname@example.org
- Password: admin123
Type on path on the URL: http://10.10.231.178/#/administration
Question 2 – View another user’s shopping basket!
Login to the Admin account and click on ‘Your Basket’. Make sure Burp is running so you can capture the request!
- Change the parameter /rest/basket/1 to /rest/basket/2
Question 3 – Remove all 5-star reviews!
Task 7 – Where did that come from?
There are three major types of XSS attacks:
Question 1 – Perform a DOM XSS!
Note that we are using iframe which is a common HTML element found in many web applications, there are others which also produce the same result.
This type of XSS is also called XFS (Cross-Frame Scripting), is one of the most common forms of detecting XSS within web applications.
Websites that allow the user to modify the iframe or other DOM elements will most likely be vulnerable to XSS.
Why does this work?
It is common practice that the search bar will send a request to the server in which it will then send back the related information, but this is where the flaw lies. Without correct input sanitation, we are able to perform an XSS attack against the search bar.
Question 2 – Perform a persistent XSS!
It should say the last IP Address is 0.0.0.0 or 10.x.x.x
As it logs the ‘last’ login IP we will now logout so that it logs the ‘new’ IP.
Make sure that Burp intercept is on, so it will catch the logout request.
We will then head over to the Headers tab where we will add a new header:
Then forward the request to the server!
When signing back into the admin account and navigating to the Last Login IP page again, we will see the XSS alert!
Why do we have to send this Header?
The True-Client-IP header is similar to the X-Forwarded-For header, both tell the server or proxy what the IP of the client is. Due to there being no sanitation in the header we are able to perform an XSS attack.
Question 3 – Perform a reflected XSS!
First, we are going to need to be on the right page to perform the reflected XSS!
Login into the admin account and navigate to the ‘Order History’ page.
From there you will see a “Truck” icon, clicking on that will bring you to the track result page. You will also see that there is an id paired with the order.
Why does this work?
The server will have a lookup table or database (depending on the type of server) for each tracking ID. As the ‘id’ parameter is not sanitised before it is sent to the server, we are able to perform an XSS attack.
Task 8 – Exploration!
Question 1 – Access the /#/score-board/ page
Also Read: Tryhackme – Overpass
So that was “OWASP Juice Shop” for you. In this room, we have covered the OWASP Top 10 web application vulnerabilities. From Bruteforcing to SQL Injection and XSS we took the challenge to solve all of these. To be honest, OWASP Juice Shop is a very detailed and fun vulnerable VM to tinker with and this room scratches only the surface of it. That means, the rest is upon you to uncover and excel in the web application exploitation techniques and attacks. On that note, i will take your leave and will meet you in next one. Till then, “Keep Hacking”.