Because I’m a little burned out from spending so much time on Leetcode of late, I recently reached out to a subreddit which focuses on infosec career advice (r/SecurityCareerAdvice) to ask more knowledgeable folks how I could demonstrate continued interest in cyber security without spending money I don’t have on a series of certifications. Both responses included suggestions that I write blog posts, with one going a step further and recommending that I write up walkthroughs for whatever I was working on (a huge thank you is in order for that person, who’s given me permission to post a link to their company’s website, https://securityps.com/).
The thing I’ve been working on most recently, which I’ve been picking at slowly but surely for the last few months, is OWASP’s Juice Shop (https://github.com/bkimminich/juice-shop). Juice Shop is an intentionally insecure web application which is designed to teach people like me how to find and exploit vulnerabilities in a realistic setting.
There are, at this time, 100 individual challenges organized by both vulnerability category and difficulty level, ranked from 1-6 stars with 1 being the easiest. There are, however, 15 challenges which are unavailable to me, as I’ve chosen to run the application locally with Docker and completing those challenges would present a security risk to my system. This leaves me with 85 different challenges to complete and write up.
Since I have this pesky computer science degree and lots of friends writing web applications for fun and/or profit, I am also going to write up how to prevent or mitigate each vulnerability I successfully exploit. We’re all better off with fewer vulnerabilities on the websites we visit, so I’d like to think that by explaining how to protect an application from each attack, someone somewhere will catch a vulnerability before it’s exploited in the wild. Every one counts.
To keep myself from writing meandering, difficult to follow posts, I’m going to build and follow a framework, which I may be updating as time goes on depending on what I learn about the walkthrough write-up process. Here is that framework being applied to the only listed challenge which differentiates white from black hat hackers:
Important Note:
One thing I want to highlight before beginning this series is that I’m very, very inexperienced. As of this writing, I’ve rooted 14 machines on hackthebox.eu, completed 20-30 of the Juice Shop challenges in the past, and worked through OverTheWire.org’s Bandit series, but have spent significant time reading tutorials and walkthroughs in the process. I will definitely find myself using the Official Companion Guide’s Solutions page to complete some of these tasks. I probably even used it to solve this challenge in the past. When I do so going forward, I will list that page in the “Resources” section. I will, however, also be writing these as if this is the first time I’ve completed the challenge, so as to make the walkthroughs easier to follow.
To be clear: I’m here to learn new things and reinforce what I already know, not demonstrate mastery.
That said, let’s get started!
Challenge:
Name: Security Policy
Description: Behave like any “white-hat” should before getting into the action.
Difficulty: 2 star
Category: Miscellaneous
Expanded Description: https://pwning.owasp-juice.shop/part2/miscellaneous.html
Tools used:
OWASP ZAP, FoxyProxy FireFox extension
Resources used:
Methodology:
First, as always, I tried to RTFM. The expanded challenge description contained within the Official Companion Guide frequently has links to recommended reading, so I started there. Having read and searched the suggested reading I found nothing of any great import. Because the suggested reading focused on privacy policies, and that there is a separate challenge for reading the privacy policy, I knew it must have something to do with a secondary privacy policy or security policy. Having never heard of a secondary privacy policy, I opted to search for a security policy.
There are a number of tools available to enumerate the file structure of websites, but because this is an OWASP product (and because Dirbuster and Gobuster kept running into errors) I decided to use OWASP’s Zed Attack Proxy (ZAP), supported by the FireFox extension FoxyProxy which manages the proxy for ZAP. By pointing the automatic scan to the url of the site (http://localhost:3000/#/ if using Docker), ticking the boxes for both traditional and Ajax spider tools, and clicking “Attack”, I was able to produce a tree-organized picture of the contents of this site. But there wasn’t a “security” to be found.
Somewhere in the recesses of my mind I vaguely remembered something about “security.txt”, but the word “security” didn’t appear anywhere in the spider search. So, like any good computer scientist, I googled it. The first link from my “infosec security policy location security.txt” search was a site called (naturally) https://securitytxt.org/. Reading about the proposed policy (for which there is an active RFC), I saw that there should be a hidden folder called “.well-known” which would contain the security policy.
What I found there was not a policy as much as contact and encryption information, but it did satisfy the conditions for completing the challenge.
Prevention and mitigation strategies:
None, in fact this is something which more sites would do well to implement.
Lessons Learned and Things Worth Mentioning:
- Don’t trust a spider to find everything. I’d have preferred to use Dirbuster or Gobuster, but they don’t seem to play particularly well with Docker. Even they, however, have blind spots depending on word lists used and extensions.
- I knew nothing of the “.well-known” hidden folder. I’ve only ever seen a handful of hidden folders on websites, so this also serves as a good reminder to search for them.
- RTFM isn’t always effective, even if it’s in the Official Companion Guide.
- Sheer dumb luck is pretty cool.
Curiosity Kills Colby 