Yesterday we shared how some of Bugcrowd’s top-ranked bug hunters fit bounties into their schedule and maximize payouts, and today we’re going to dive a bit deeper with one of those researchers. In today’s post, Brett Buerhaus, ranked 16 on Bugcrowd and experienced security researcher, shares his method for approaching new bug bounties and writing bug submissions.
Brett’s Methodology for Bug Hunting on new bounties
“This is every security tester’s ‘secret sauce.’ It takes time to develop your own penetration testing methodology and discover what works best for you. I’ll try to give a quick high-level overview of the process I go through for each bounty program.
For me it boils down to:
- Review the scope
- Perform reconnaissance to find valid targets
- Scan against discovered targets to gather additional information
- Review all of the services and applications
- Fuzz for errors and to expose vulnerabilities
- Attack vulnerabilities to build proof-of-concepts
For all bounty programs, I’m first going to review the scope of the target. There’s a big difference between a scope such as *.google.com versus a small company’s single application test environment.
If there’s a big scope for a program that accepts submissions for any of their servers, I’m going to start doing reconnaissance using search engines such as Google, Shodan, Censys, ARIN, etc. to discover subdomains, endpoints, and server IP addresses. This is a mix of Google dorking, reviewing certificate data, scanning IP ranges owned by companies, etc. Anything that gives me information on servers that may be owned by that company.
If it’s a smaller scope such as a single website that can only be accessed through a proxy, I’ll most likely skip doing most of the reconnaissance.
When I have a list of servers, I start to perform nmap port and banner scanning to see what type of servers are running. You may get some quick finds such as open SSH ports that allow password-based authentication. At this point I tend to stay away from reporting those smaller issues. I opt to spend more time looking for critical applications running on non-standard web ports such as RabbitMQ or Jenkins that may have weak default configuration or no authentication in front of them.
Before I dig into the websites too deeply, I first do a quick run through the web servers looking for common applications such as WordPress or Drupal. This is a mix of just browsing the sites manually, looking for sitemaps, looking at robots.txt, etc. This can lead to some quick findings if there are custom plugins being used. These open-source plugins are typically poorly made and with some source review can lead to critical findings.
Once I get through all of that, I start to dig into the applications made by the company by mapping out all possible endpoints. This is a mix of manually browsing through the website, reviewing the JS files for possible AJAX/XHR requests, looking for requests baked into flash/SWF media, etc.
All while I’m doing that, I’m trying to understand their infrastructure such as how they’re handling sessions/authentication, what type of CSRF protection they have (if any), if they have a WAF blocking requests, if they are filtering input versus encoding. This is important because it forces you to adapt how you fuzz and look for exploits.
I won’t dive into the intricate details of fuzzing endpoints, but I’ll say that’s the meat of my bug bounty hunting. I spend most of my time trying to understand the flow of the application to get a better idea of what type of vulnerabilities to look for. That’s not to say I’m not looking for everything, but certain types of vulnerabilities are going to have higher impact against certain types of applications.
Once I’ve done all of that, depending on the rules of the program, I’ll start to dig into using scripts I’ve built for wordlist bruteforcing endpoints. This can help with finding new scripts or folders that you may not have been able to find just using the website. This tends to be private admin panels, source repositories they forgot to remove such as /.git/ folders, or test/debug scripts.
I tend to stay away from using tools like Burp, SQLmap, etc. during my testing. There are plenty of vulnerabilities I have missed by not using these types of tools. It really comes down to how you like to hunt for vulnerabilities. This is just the methodology that I have built over many years of penetration testing that seems to work for me.”
The Value of writing quality Bug Submissions
“One suggestion I have for all researchers out there is to spend more time writing high quality reports. Consider yourself as the program owner and that you’re about to receive the report. Ask yourself some questions such as:
- Is it formatted in a clean way that is easy to read?
- Does it contain all the information they’ll need to fully understand what you discovered?
- Can you reproduce your finding without any knowledge of the application just using the steps in your report?
If you ask yourself these questions and improve your reports, I think you will find yourself gaining a lot more from your time spent. I’ve found focusing on writing high quality reports has done a few things for me:
1) It helps me better understand the vulnerability I’m reporting. Some of the people I have taught application security and bug bounty hunting to are capable of finding XSS vulnerabilities. But they really have no idea how to actually exploit with it. By fully explaining the vulnerability and how it’s exploitable, it forces me to thoroughly understand what I’m reporting.
2) I never assume the person deciding the reward fully comprehends the vulnerability or impact. If you better convey the possible impact with a solid proof-of-concept, it can lead them to better understanding the real impact against their company. This can translate into getting better rewards.
3) It builds a good relationship between me and that company. It never hurts to make great connections with employees at major technology companies.”
We share more tips from Brett and other top bounty hunters in our free “Inside the Mind of a Hacker” report. The report details the distinct types of researchers that participate in bounties, in-depth video interviews with researchers and best practices for bug hunters.
Many thanks to to Brett for sharing his insights, methodology and experience with us for this piece. Follow Brett on Twitter at @BBuerhaus.
