My First Valid Bug In Hackerone

Hello everyone, thank you for spending your time on reading my article. In this article I will explain you all the steps that I followed in finding the bug till reporting that. Without any due, let’s dive into story.

RECON:

Abraham Lincoln said, “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”

This line is very useful in Bug Hunting. After selecting the target don’t go blindly for testing the domain. Instead take sometime, may be a day or two, on gathering information which is also called RECON. Even in some cases it may take 4–5 days. If you have all the sub domains (*.redacted.com) in scope, then you can test all the subdomains. In my case I have permission to check all the domains.

First gather all the subdomains using tools like amass, findomain, sublister or any other tool. After gathering all the sub domains now filter them. Check which are live sub domains and which doesn’t give 200 OK response. For this there is an awesome tool called httpx . When I am doing my work on the target I don’t have idea on this tool. I used to use a tool called subzy which will show you which sub domains are vulnerable to Sub domain takeover.

The output of that tool will have 3 results:

1. Vulnerable
2. Http Error
3. Not Vulnerable

So when it shows http error it means the domain is not live. It means it won’t give you 200 OK response. If it shows not vulnerable, then it means that it is a live sub domain. So I gathered all the subdomains showing Not Vulnerable. It means I am gathering all the live domains

It’s weird right? Gathering which are not vulnerable

MANUAL TESTING:

Now it’s time for manual testing. Go through each and every subdomain and check the functionality of that and test it. I checked a lot but no use, didn’t found any :(

POINT TO REMEMBER:

SPEND MORE TIME ON ONE TARGET

I heard that you need to spend more time on one target even if you didn’t find at least one bug. So I didn’t stopped and I continued to test each and every functionality.

I shouldn’t disclose the name of the website, so let’s call it redacted.com . Let’s assume the subdomain as abc.redacted.com . That subdomain is similar to an ecommerce website. You can login, signup, logout, add to cart, buy … and lot more functionalities.

When there are more functionalities in a website you will have more scope. So as the attack surface is more it’s a bit easier to hunt. As usual I checked login, signup and all other functionalities again no use.

Without giving up, I tested reset password functionality. I requested new password by using forgot password functionality, and I clicked on the link that I received in my mail.

There are few social media icons on that page which will redirect you to their social media pages. I cannot show you the screenshot of the reset password page because I need to blur many, if I do so you can’t clearly see anything.

STEPS FOLLOWED TO REPRODUCE:

1. Clicked on any social media links and intercepted the request.
2. Observed the Refer header.
3. I can clearly see the complete password reset token being leaked to 3rd party sites.

The request looks like this:

Reset password token leaked

After few days of comments the report got triaged.

After two weeks the report was closed as RESOLVED.

This is my first valid submission to Hackerone program after several N/A’s and Duplicates.

I hope you liked my article. Feel free to contact me on social media, links given below

Instagram Twitter