Juice Shop Walkthrough - 2 Star

In today's post we will be talking about the Juice Shop walkthrough part two, and walking through the two star challenges.  The screenshot below is from the scoreboard we found in part one.  

The first challenge is to access someone else's basket.  The first step is to access our own basket to under more clearly how the authorization process is handled.  For this challenge fire up your BurpSuite interception proxy, and set it to intercept before clicking on Your Basket.  

The screenshot below shows the request being caught by BurpSuite.

Before forwarding the request try simply changing the /rest/basket/5 to /rest/basket/1.  As you can see from the screenshot below that was all it took to access someone else's basket.  

To find the Christmas special offer of 2014 we gather from a hint on the scoreboard that we must find out how the application hides deleted products from its customers.  As well, the hint mentions to try crafting an attack string that makes deleted products visible again.  In order to successfully complete this challenge you must get the product into your shopping cart and trigger the Checkout process.  With the aforementioned hints we need to find a place in the application that will allow us to look for the products.  Looking closer at the products it appears that the Products in the store are loaded from product in products.  This appears to be some sort of SQL(or noSQL) database.

This trick does not work in every situation, but in my experience one way that I can determine if the web application is using a backend database is to see if the results of a search are loading from the client side or the server side.  Set intercept in BurpSuite again and make a search.  

As you see it is requesting from the server side.  We can attempt to inject SQL commands in the search feature to see if the web application responds in an unexpected way.  

Typically an application will not have this added feature, but it is always a good idea to keep an eye on the JavaScript console to watch for error messages or console logging that a developer might leave on the application for debugging purposes.  In the instance of Juice Shop the JavaScript console will actually respond with our current SQL command that is being injected into the backend database.  

Utilizing this information disclosure we should be able to craft a SQL query that will allow us to dump the Products table.  Pay close attention to the clause in the SQL statement AND deletedAt IS NULL.  We can try to remove this clause by injecting a SQL statement to end before that string is processed.  

Not sure where to really look for this challenge therefore taking a look at the hint will help give us a slight nudge towards the goal.  The hint states that even though Juice Shop is a classic Business-to-Consumer (B2C) application, it was also built for some enterprise customers that might want to buy large quantities of product at a time.  It mentions that when deprecating the old interface, not all of its part were cleanly removed from the code base.  This hints at there is some functionality that might be commented out or possibly the button to activate the functionality is removed.   I will admit I used BurpSuite Pro for this challenge to spider and then retrieve all of the comments from the spidered pages.  This led us to the /#/complain page.

From here you should be able to just upload an .xml file and click submit, but for some reason my instance is throwing an Error status: 502 and then restarting the server.  Which cancels out my progress.  I will have to dig into this more.  It could potentially be a bug with the way the Nginx or the Docker container is behaving.  Hopefully this worked better on your end.  

Update: According to this link it appears there are some issues with the npm module libxmljs not getting updated accordingly.  As soon as it gets updated and pushed to the Docker container I will finish up this post.  

Update 2: Wow.  @bkimminich works so fast.  He already pushed an update to the Docker snapshot build, and has fixed the issue.  It was less than 3 hours to completion.

The next challenge is to remove all the 5 star reviews.  This challenge is not a challenge.  We have already found from the previous challenges, and post where the Customer Feedback lives.  Login into any user, and navigate to /#/administration.  See the red garbage can?  Click it.  Done.  

The next two challenges are very similar in that we need to login to the Admin account without the use of SQL injection.  There are several ways to complete this.  The first is to brute-force the password, and the second is to try and guess the user's security question and reset the password that way.  For this attack, I am going to demonstrate how to use BurpSuite to perform a brute-force attack of the administrator's password.  Before we can brute-force we need to find the administrator's email address.  Remembering from the previous blog post that when navigating to /#/administration ,while logged in as any user, there was a list of usernames that are registered to the web application.  

The first step is to capture the POST request being sent to the server side.  Once the request is intercepted simply right click and send to Intruder in BurpSuite.  

The first tab when you open the Intruder menu is the Attack target.  This will typically remain the same unless you need to force HTTPS.

Choose the Positions tab under the Intruder menu.  From there we can clear all of the suggested points of entry, and add a single item to the current password input under the password parameter.

Under the Payloads menu item BurpSuite offers many different options for payloads to use.  Such as, brute force with numbering, payload processing, or even loading wordlists.  You can also add passwords or payload options one-by-one.  Through trial-and-error, I attempted multiple commonly known credentials wordlists, and finally found a list that contained the correct password.  For this brute-force attempt I used the worst-passwords-2017-top100-slashdata.txt password wordlist.  

Now that everything is configured simply pressing the start attack will begin the brute-force attack.  Note:  If you are using the BurpSuite Free/Community Edition the Intruder module will be rate-limited.  This can cause a brute-force attack to take a very long time.  It is recommended to reduce your overall wordlist to a reasonable size or to utilize a different tool, such as Hydra.  

After waiting for a few minutes we can sort the Status codes in descending order, and we notice that we get one 200 Status code.  200 Status is a response code from HTTP stating returned successfully.  

Returning to the Juice Shop page in the browser and refresh the page will reload with the two completed challenges.  

The second challenge completed above says to login without using SQL injection, which makes me think that it is possible to bypass authentication with SQL injection.  Thus, I am going to walkthrough the process of testing SQL injection using BurpSuite's Intruder.   The screenshot below is showing the POST request intercepted in BurpSuite.  Next we will send it to Intruder, and add an entry point right behind the username.  

For Payload options I downloaded a SQL wordlist from Github, and loaded it into the Simple list input area.  

As mentioned before, the Free/Community Edition of BurpSuite will rate limit how quickly the Intruder attack runs.  It's all important when performing SQL injection to keep an eye on the Status codes.  As you can see below most of the injections are either 401 which is access denied, and 500 which means the server side had an error.  

We can click on an individual request of the 500 error, and inspect the response from the web server.  It appears that the SQLITE database is not processing our payload correctly.  

Looking at the Request that is being sent it should become apparent that BurpSuite is encoding the Payload with URL-Encoding.  When the request gets passed to the backend database the processing engine cannot understand the URL encoding.  

Luckily, BurpSuite allows us to easily turn off Payload Encoding.  I wanted to make sure to show this error, because when testing for SQL injection it is important to make sure to understand what BurpSuite is doing with your payload.  

Once the Intruder attack is started again there will be multiple Status code 200 responses.  We can then copy one of the payloads that worked correctly into the login field, and bypass the authentication method.  

For the next challenge the scoreboard instructs us to login with MC SafeSearch's original user credentials without applying SQL Injection or any other bypass.  Uh... who is MC SafeSearch?   http://bfy.tw/ItTo.  Just use the information gathered from the video below.  I'm not going to spoil this one for you.  

The following challenge is to behave like a White Hat would.  A white hat hacker is an individual who uses hacking skills to identify security vulnerabilities in hardware, software or networks. However, unlike black hat hackers, white hat hackers respect the rule of law as it applies to hacking.  So before we just jump into attacking the web application (whoops, little late) maybe we should find out if there are rules or restrictions to this web application.  Using some Google-Fu we were able to find a link to a site that is proposing a standard which allows web applications to define security policies.  The site is https://securitytxt.org/, and you can read more about the proposed standards there.  However, using this information we can navigate to /security.txt and find the security policies for Juice Shop.  

The final challenge for the 2 star category is to inform the shop about an algorithm or library that the web application should definitely not be using.   The challenge also provides a link to the /#/contact page so that must be where the message is supposed to be sent.  Looking into the hints there are four different possibilities of cryptography, but where can we find out what cryptos were used in the site.  Lets dig for some more information.  

The file package.json.bak is very suspicious.  Files labeled .bak are typically backups of current running configuration files.  This is how Linux sysadmins usually back copies of files.  The package.json is a file that is used by npm to define what packages will be needed in building the node application.  We need to download this package.json.bak file.  

It appears the web application will only allow us to download or upload .md and .pdf files.  Maybe we can make the web application think that the package.json.bak file is actually an .md or .pdf file.  This is where Null Byte Injection comes into play.  First we will attempt a simple request for /ftp/package.json.bak%00.pdf.  

Hmm...sometimes web applications will filter for %00, but not to worry you can even double encode a Null Byte Injection attack using %2500.  

Success!  The package.json.bak file has a subsection of required dependencies which are all of the installed packages of the web application.  

You should look through each of the packages to determine which one is vulnerable.  However, if you are short on time I have done the work for you and have looked through each one.  There are two in this list that have vulnerabilities associated with them.  For this blog entry I will use the z85 package.  

This wraps up the 2 Star challenges.  If you have made it this far I have to commend your patience and persistence.  From this point on it might be easier to move to subsets of the challenges.  That will prevent the blog posts from being too lengthy.