My name is Brett Buerhaus. I usually go by the handle bbuerhaus for everything security related but my online alias has been ziot for a long time. I currently live in California in the US.
I got into web development as a hobby when I was about 10 years old. I started with managing online forum communities and creating modifications for them. I discovered my first critical security vulnerability (remote code execution) while reviewing the phpBB source and quickly discovered that I had a love for application security. I’ve been hacking for around 15 years now.
I started with the Facebook and Google bounty programs. Nowadays I mostly hack on HackerOne, but I’ve also spent some time on Bugcrowd, Synack, and Zerocopter.
I currently have a full time Red Team job with past roles in game security, web penetration testing, and application security.
It’s a lot of late nights staying up until 3 AM to stay active in bug bounty
Bug bounty is a part time hobby of mine, somewhat for the money but mostly just to stay relevant. It’s a good opportunity to see how other companies operate. I get to look at applications/infrastructure I might not see at my company. This helps me be prepared for anything I might see in the future or may have overlooked in the past.
On average probably 2-3 hours a night during the week, definitely more on the weekends. I aim for 10 decent bugs minimum a month with at least 1 critical a month. I try not to go for number of reports and instead look for interesting vulnerabilities.
I found a decent XSS on admin.google.com after my first few months of hunting in bug bounty that paid a fair amount.
There was a target on Zerocopter that had been around for awhile and no one had submitted anything to them. I challenged myself to hit all of the active programs on ZC that I was invited to and see if I could close them out. I struggled with this company for a day or so and could not find a single vulnerability.
I decided to dive a bit deeper and found hints of the CMS they were using. Looking at some of the JS files, I discovered some keywords that led me to believe they were using the framework seneca.nl. I kept digging through the JS files and discovered a dev endpoint that had a textbox on it.
After a bit of testing on it, I discovered that it evaluated Viper script code for the Seneca framework to determine if the code was valid or not. Spending a few hours on their docs, I discovered methods to get responses out via response headers. Using that I was able to get the full filepath out. I was able to achieve remote code execution using a function to write code to files on the box once I knew the filepath.
This one was particularly fun for me because I went into it blind, had to research a new framework, and made wild assumptions that paid off in the end. This embodied everything I love about bug bounty hunting.
I already had a past in security and hacking, so none of this was new to me. Hacking has always been a hobby of mine, so getting involved in bug bounty just seemed natural.
The first time I heard about bug bounty was through Facebook’s bounty program. One of my friends linked it to me and I wasn’t aware bug bounty was a thing at the time. I assumed finding a decent vulnerability on Facebook would be a really difficult challenge. I told myself the best hackers out there are probably looking and I wasn’t sure how I stacked up against them.
I spent a month or so looking without finding much. This was probably the biggest hurdle I had getting into bug bounty, but it was not something foreign to me due to my past in security. The vulnerabilities usually exist even if you aren’t finding them. Persistence is the key to succeeding, you just need to keep looking and not give up. I eventually landed on two decent vulnerabilities within the same hour.
It was such an adrenaline rush to finally find something after failing for awhile. I really enjoyed the feeling of the hunt and the rewards you gain from it. This is what made me dive into Google’s program next. Finding a vulnerability on both Google and Facebook hooked me in and made me realize I could do this.
Primarily Blogs, Slack, and Twitter. The security and bug bounty scene have been great at sharing everything. Building a strong network of people in various niches of the security industry usually means getting coverage on everything interesting.
I collaborate with @nahamsec almost entirely. I occasionally seek insight from smart people like @patrikf, @smiegles, and @jobert.
I could list dozens of people that have helped me out at one point or another in the past year alone. One of the great parts about the Bug Bounty Forum slack is that everyone there is happy to help you if you ask.
I covered my methodology from a high level on Bugcrowd’s blog: - https://blog.bugcrowd.com/tips-from-top-hackers-bug-hunting-methodology-and-the-importance-of-writing-quality-submissions
My initial recon process involves collecting a list of servers, subdomains, open ports, and services running on ports (banners).
Initial Recon:
I initially look at what services are running before I dive into applications. You can sometimes come across services such as dev panels, unauthenticated Jenkins, ElasticSearch, etc. These are all services that lead to quick wins after you have some experience finding them.
Once I have a list of websites, I’ll start to look for:
At this point I feel comfortable enough with the information collected and will dive into the web applications to start hunting for vulnerabilities.
Initially, yes.
As I learn more about the target, I may find that certain vulnerabilities no longer make sense. E.g. If I determine that the templating is Django and I have ruled it out for vulnerabilities, I may no longer be interested in template injection. If it’s ASP.NET with the built-in XSS detection, I will alter my XSS payloads and instead look for specific types of XSS.
This is why persistently hitting the same target for a long period of time is going to help you find higher severity vulnerabilities. You are going to better understand the target, notice things you missed before, and focus in on certain types of vulnerabilities.
I primarily use tools for reconnaissance as I prefer to do most of my application hunting manually.
One thing I spent a few years working on was building infrastructure to automate kicking off scans, parsing the results, and displaying it in a nice format. At the moment I can just input a domain or IP CIDR and collect subdomains, screenshots of websites, web banners, port data, and more.
I did some really fun stuff with AWS that I don’t think anyone else is doing. I just submit a CFP to Blackhat for it. Hopefully I will be able to share that with everyone soon.
This is a fairly broad question that I think goes back to what I was saying about persistence. Getting RCE on an application can range from template injection, deserialization, auth bypass into admin panels, etc. There are many ways you can achieve it, it’s just a matter of understanding the application and the types of vulnerabilities that can exist in it.
A lot of this comes down to reading and researching that application, language, or framework. If you’re hitting a Ruby/Rails app, there are rails specific vulnerabilities that you may miss if you don’t know anything about rails. There are certain types of nuances in Ruby that you could abuse to find vulnerabilities if you know more about how Ruby works.
Spend time learning about what you are testing, research it, and you’ll find things that others are missing.
For SQL injection I mostly test it manually with simple payloads such as “‘ or 1=’1”, “-1 or 1=1”, “‘+sleep(1)+’”, etc. The initial injection into a SQL query is usually basic enough making discovery trivial, the complexity typically comes from overcoming hurdles while extracting data. This is a good thing to takeaway if you’re struggling to find these kinds of vulnerabilities. Don’t rely on tools like sqlmap or crazy polyglots. You’re going to miss vulnerabilities if you’re passing in strings without understanding why they might be failing or why it might be getting blocked by a WAF or application.
I think most bug bounty hunters can say they do this regularly because most programs, even private ones, are going to have a handful of solid hackers on them. I don’t think you should ever approach a program with the mentality that you are not going to find anything because other people have looked first. You should always go in with the mentality that it doesn’t matter how many people have looked at it.
Regardless of rank or skill, some researchers are going to be better at finding certain types of vulnerabilities than others. It’s very possible to find something low-hanging and obvious that a decent hacker missed.
Also keep in mind that big companies are pushing out code changes on a daily or weekly basis. They are also pushing out patches for all the vulnerabilities reported. Vulnerabilities will come with code changes. You can find vulnerabilities that may not have even existed when the hordes were looking at the program.
I think it’s essential to approach hacking from the technical side if you want to be good at it. I spent some time putting together training courses for people to get involved in bug bounty. I quickly learned that it’s hard for people to grasp web vulnerability concepts without a basic foundation in web development.
My recommendation is always the same to people new to web hacking. Learn the basics of web development and program all the vulnerabilities you learn about. Look into how people are exploiting the vulnerabilities and reproduce it in your sandbox. Spend some time learning how to fix them. Once you have built the vulnerability, played with it, and fixed it, you’ll have a decent grasp on what to look for in the wild.
All of these things are essential for understanding how a website is responding when you start manipulating requests. A vast majority of the time you aren’t getting meaningful responses. If you are triggering a generic 500 response, it may mean absolutely nothing to you and you may miss a vulnerability. You need both that hacker intuition and developer experience to make guesses on what is occurring behind the veil.
Having the experience of actually exploiting the vulnerability will help you better understand the true severity of an issue and deliver quality reports. You never want to undersell or oversell a vulnerability - providing proof-of-impact and an explanation of it can lead to higher payouts.
Depends on the mood, but usually heavy metal.
I think equal to hacking is my love for video games. The constant struggle with my free time is whether to play a video game or hack a bounty program.
I think one of the bigger impacts is the doors it has opened for me. I’ve had the opportunity to work with many companies, blog about interesting write-ups, travel to hacking events, and collaborate with a lot of researchers. Some of the companies I have reported to have even expressed interest in hiring me. Bug Bounty is a great way for people new to the industry to break into it.
Most importantly, it’s helped provide me with enough additional income to buy my first home in SoCal. As much as I do this out of passion and interest for hacking, I also do it to provide for my family.
Writing a high quality report is almost as important as discovering the vulnerability itself.
If you don’t provide enough information, have a bad attitude, or don’t demonstrate impact, you may not get the reward you deserve for the effort you put into it.
Assume that you are reporting a vulnerability to someone that doesn’t understand the issue or the impact. Question whether you would understand the report without knowing the application at all. Provide enough information that it is easily reproducible the first time they walk through it. You can relax on this a bit as you grow a stronger relationship with the team and know what they expect from the reports.
I wish I had spent more time learning assembly, binary exploitation, and reverse engineering when I was younger. It’s a skill that requires a steep time investment and has a lot of depth to it. I don’t have as much time now as I used to!
I plan on spending more time on this area because I find browser hacking super interesting and it would be fun to build a fuzz farm.
1.) Earlier I talked a bit about programming vulnerabilities in a sandbox. I recommend this as the number one thing to do before you start hunting for them. Get a strong grasp on the technical details. A good hacker is almost always a good programmer.
2.) Try to discover and exploit vulnerabilities on your own before seeking help from others. This is an industry where there is strength in finding solutions to your problems. Most of your questions early on will be answerable with a single Google search. It doesn’t hurt to ask for direction, but it may hurt to have people handing you all the answers. You will eventually get to a point where you may have no one to ask and need to rely on yourself.
3.) Read write-ups from public vulnerability disclosures. Seek blog posts that tell the entire story, such as how they discovered the issue and not just the vulnerability itself. Getting a narrative from successful discoveries will help you find what people looked at and why.
Toast? I’m all about that bagel life.
hmm….
Given the chance, I would love to sit down and work with filedescriptor and see how he tackles the discovery of JavaScript vulnerabilities. There are times when I’ll be trying to reverse through obfuscated JavaScript on Google and give up because I’m overwhelmed. Getting some insight into his processes would be a great experience.
Collaborative reporting so that multiple researchers can be on the same ticket. There are times when I’ll discover a vulnerability with a friend and only one of us will get the rep/recognition for it.