Preforming recon is the most important step when it comes to bug hunting and security research. Recon just means using your knowledge about vulnerabilities to actually find one and that’s why it is so important skill for every hacker to have. In this blog post, I will showcase how I preform recon using Portswigger’s mystery lab. I also have a platform which will features some of my premium blog posts and stuff related to Bug Hunting. So check that out on the link here: https://hackrhub.com

Mystery lab is something like a CTF, there is a random vulnerability on a website and your goal is to find it and exploit it. This sharpens your recon skills and I definitely recommend you practice your recon skills on mystery labs. I used them when I was starting out with me security researcher carrier and it helped me a lot in becoming a successful bug bounty hunter that I am today. So let’s start with a random mystery lab and let me show you how I do it!

Follow me on:
Instagram: deadoverflow — — — — Youtube: deadoverflow

Mystery Lab Challenge

Once I clicked the “Challenge Me” button, I was greeted with a mystery lab that I now have to solve. To solve it, I will be having to find a vulnerability so let’s start by accessing what we can do on the webpage.

Currently there isn’t much to do besides a basic search functionality to search through all of the blog posts and functionality to open blog posts. However if you were to open a blog post, that reveals that there is also functionality for posting comments.

1. Search functionality

From the given functionalities, we can already tell what could go wrong. For example the search functionality cannot be nothing serious, maybe XSS but we will still test for command injection and or SQL injection. But for now XSS is our priority, then I will go down the list and test for other possible vulnerabilities.

2. Blog opening

For the blog opening functionality maybe there is an IDOR since you can manipulate the postId query. IDOR in this case could give us a way to maybe see some private or secrets blog posts that are not meant for public. Or it could be Command Injection vulnerability and even SQL injection.

3. Posting Comments

Finally, we come to last functionality which just gives users to post a comment. This also could be a variety of vulnerabilities depending on how its handled but for now I smell stored XSS. Then I would test for XXE and maybe some logic bugs.

Preforming tests

Once I have a clear picture of what could go wrong where, I will start to test and do my research. I will start with the search functionality since it is the first thing that I noticed. I will go down the list in case I don’t find a vulnerability.

So let’s start with the first vulnerability on the list, XSS. I will paste some stuff in the search field and just see how the application handles it. I will paste something like <><>”’\${}

Now I will hit search and open Chrome Developer Tools to inspect what has happened.

I will navigate to the “Sources” tab and then select the HTML file which has been loaded.

In here, I will just look for places where my search term was placed and see if there are any misbehaviors by the application.

I can see that my search term was placed inside of the searchTerms variable and from everything I have entered as a search term, only single quotes were not encoded.

Now I will just try to enter single quote (‘) in the search and see what happens.

So the single quote just gets escaped and nothing else. This kind of gave me an idea to enter \’ as a search term. My logic was if the application just adds \ to ‘ without proper checks, I could still escape out of the variable and inject code. So that’s what I tired.

After I have entered \’ as search term, this got reflected in the JS variable

There is obviously an error and now I know that the vulnerability is there. Now I can just enter \’; alert(1);// as search term and alert(1) will be called.

And as you can see, it worked the way I thought it would.

Here we can inspect how my payload got injected into the JS variable and hopefully it makes more sense now.

Why my payload executed?

Basically a variable cannot contain exactly three encapsulating symbols. For example:

This is not valid JS, and a correct way to do it would be to add a backslash \:

This was what the application was doing, however if there are two backlashes in a string like this, we are back at the beginning again.

The white single quote is interpreted as JS, that’s why \’; alert(1); // has been executed.

Programming is important

Without programming, it would be very hard to hunt for bugs, and even understand them. Understanding how a vulnerability works completely is crucial and you cannot do that without programming knowledge. You can understand some vulnerabilities but unfortunately some is not most. I recommend you learn HTML, CSS and JS, then move on to something new. It is really important and every successful bug bounty hunter knows how to code, including me.

Thanks for reading yet another article of mine, make sure to follow me on socials and here on medium. Thanks :)