Finding P1 Vulnerabilities: Tools & Resources
The second part of the ‘Finding P1 Vulnerabilities: A Step by Step Guide’ post. This one goes more in-depth about what to do in the actual steps rather than the concepts.
I decided to make another part mostly because there were a few questions on the first post, and because I wanted to provide some more information on best practices and tools to use at each step. If you haven’t already, make sure to read the first article →
It’ll help you understand some of the steps that I reference in this article, but it’s not required.
I assume by now you’re just looking for some steps to pen-test a site you’ve found, and you’ve come to the right place. We’ll skip past going over Step 1, which was determining if you want to pen-test a site and seeing if it might be vulnerable due to outdated libraries or Principle of Least Privilege not being implemented.
Step 2: Initial recon of the site, and low-level vulnerabilities →
This is where you’ll find low-hanging fruit and be able to dig deeper on certain aspects of the sites, vulnerabilities like multi-factor authentication, open redirection, that sort of thing. Here’s a few tools to use —
These are some great resources to use in order to find low-level, easier bugs. These bugs might be P5(informational), or P4(low). P5 is usually not eligible for monetary rewards, but you can still get recognized for it. You’ll be scanning subdomains with Gau, and then using some nuclei templates (which are all over Github as people usually design their own) to test these subdomains for vulnerabilities or sensitive information. Make note if you find anything on this step, as sensitive information might allow us to test even further.
Step 3: if (vulnerability || sensitive data == true) {dig deeper = true} else {step4()}→
If you found anything in the previous step, you’ll want to use that here. This is where you’ll do real pen-testing. Deep scans and manual tests are key here, and you’ve got to put in the work if you want the reward. It takes professional hackers days, sometimes weeks to find quality P1 bugs. You’ll want to use some of the tools that follow:
These two are going to be the most helpful for automation, but the key here is manually testing the website. Are there insecure requests being made? Are there possible login form vulnerabilities? Do you have more access or information than you need as a typical authenticated client? These are all questions to ask when manually testing. It’s helpful to go onto Burpsuite where they’ll scan each request you send in your browser if you use a certain proxy, and it’ll automatically detect vulnerabilities in that specific request or site.
Step 4: Profit $$$ →
This is an important step, so don’t skip over it. If you’ve already found a vulnerability, great. Exploited that vulnerability already? Even better. Don’t stop short though and just submit whatever P3 or P2 vulnerability you’ve found, or even P1. Do more tests, double check your manual requests and see if there’s absolutely anything else that you could use to chain your vulnerabilities.
Chaining bugs together might create an even more threatening exploit, and that may yield greater rewards. There’s no tool for this, as it’s all manually tested and none of the tools I’ve found will scan every single request and make connections between bugs. However, I’ve attached a few useful articles on chaining these vulnerabilities:
If you’re confident you’ve found everything you can on an app or website, here’s a template for your bug report from HackerOne (which I’ve modified slightly).
## Title:
[Title of bug, i.e. “[bug type] on [domain] leading to [list possible consequences]]## Summary:
[add summary of the vulnerability, what can it do to harm the company/website/app?]## Steps To Reproduce:
[add details for how others can reproduce the issue. The better you do this, the sooner you can possibly get a reward & it shows professionalism]
1. [add step]
2. [add step]
3. [add step]## Supporting Material/References:
[list any additional material (e.g. screenshots, logs, Burpsuite request/responses, etc.)]
* [attachment / reference]##IP Address:
[IP Address for identifying your traffic]##Timestamp:
[Date and time of testing]Use this template to submit bugs and you’ll be respected by the verifiers for that bug bounty program, and possibly get more money for your bugs.
Thanks for reading about some tools and resources, and I hope you were able to learn something and/or utilize one. If you enjoy computer science or hacking, check out more posts from The Gray Area. If you’re not already a Medium member and you’d like to support me, feel free to sign up using my referral. Thanks!
