Lately, I’ve been spending quite a bit of time learning web hacking and practicing what I’ve learned on bug bounty programs. For those of you unfamiliar with bug bounty programs, they are programs hosted by companies that provide payouts for vulnerabilities found on their platforms. Payouts vary depending on the criticality of the vulnerability and some companies may not even host programs that offer no rewards. Essentially, when you’re a bug bounty hunter, you’re a penetration tester that’s working for free until you submit a security flaw.
The main reason I decided to try my hand at bug bounty hunting is because I wanted to gain experience hacking to prepare me for a career in penetration testing. I also love learning techniques and picking apart web applications. However finding vulnerabilities was not as easy as I thought it would be. So, in the post I’m going to share some things I picked up while bug bounty hunting.
It’s tough…
Bug bounty hunting is hard. Sure, it’s fun to be able to dig through a web application and see things that you normally wouldn’t see when using a web page as intended. I had loads of fun finding developer log in pages and finding weird API routes. Finding bugs that were actually exploitable was another story.
You have to compete
When you join a public bug bounty program, you’re competing with hundreds or even thousands of other hackers who may be way more experienced than you. That means that the application is most likely to be picked clean of easier bugs that automated scanners can detect. I ran into my fair share of duplicates when I first started out which was definitely a disappointment. It’s not nice when you take the time documenting your submission only for it to be shut down by Hackerone because some other hacker beat you to it.
The competition factor definitely makes the experience more difficult. However, there are some ways to help limit the competitive aspect.
1. Choose a good target
Choosing a target really depends on you. Your preferences, what your strengths, are and what you are interested in can all be factors in deciding what target you should spend time on. But when you are just starting out there are some things that can help point you in the right direction. For example, choosing a target that has a small or no payout will make it less likely that tons of money hungry hackers aren’t going after it.
I would also recommend going after a target that has a medium scope. When you’re first starting out, something with a couple to a few wild-card domains is great. That leaves plenty of opportunity for you to find tons of sub domains and interesting corners of the application. Don’t go too big though. You can get quickly overwhelmed with the amount of information automated scanners pull up on the target. It also might take a long time for the scanners to process all of the subdomains it can find.
I experienced a similar situation when doing recon on ABB. They had 7 assets in scope (all wild card domains), which seemed like a small number at the time but I was quickly overwhelmed with the amount of subdomains and URLs returned to me. I also spent a lot of time waiting on scan results, which wasn’t exactly fun.
Most importantly, you should choose a target that interests you. Most likely, you’re going to have to spend a lot of time digging through an application to find any vulnerabilities. If you choose an application you’re not interested in, you might get bored before you do any deep digging that could lead to serious bugs.
2. Find programs with private invites
Programs like Hackerone, Intigriti, and Bugcrowd are fantastic because you have the option to join bug bounty programs that aren’t listed publicly. The way this is done for each program varies. In Hackerone’s case, all you have to do is a few CTF challenges and sign up for MFA and you get your first one. To get more, though, you have to submit your first valid bug.
I was able to get my first invite with Hackerone but quickly got bored of the small scope of the target I was invited to look for bugs. So, I’ve dedicated most of my time to finding bugs to get more interesting invites. At the time of this writing, my first submission is under the review of the company, so hopefully I get more invites soon!
3. Find login pages
Whenever I do my recon, I intentionally seek out login pages. If the company has a large scope, I look for login pages that differ from the overall application and use older technology. Then, I create an account and check out the application from there.
This gives me several advantages. For one, this web application is hidden from all the skids that solely rely on automated scanning to throw shit at the wall and see what sticks.
Number two, applications that require user accounts typically have more functionality than the front-facing application. You can do all sorts of fun things with user accounts like creating two and seeing if you can access anything from the other account (IDOR). It’s also more likely there’s more opportunities for user input and API routes that are worth digging into.
Don’t Give Up
Bug bounty hunting is going to be discouraging at times. You might go weeks or even months without being able to find anything. However, even if you spend time digging through a site, you’ll still learn and grow in the process. This is what I kept telling myself and is what kept me motivated to keep going.
Bug bounty hunting taught me several things that CTFs could never do, including how to do effective reconnaissance and what to look for when examining a web application. CTFs always have one (sometimes obvious) path to a flag. With bug bounty hunting you develop creativity and an intuition that is invaluable in the world of pentesting.
If your main goal for bug bounty hunting is to get some experience and learn, you’ll never be disappointed. On the other hand, if you’re just doing this for the money, you’re in for a quick burnout.
These are just a few things I picked up on digging through various applications. What works for me might not work for you. The only way you can find what works for you is by participating in programs, which leads me into my next piece of advice.
Just do them
I know this is the cliche Nike slogan part of every self-help guru’s utility belt but it rings true in this case. Bug bounty hunting is intimidating. It’s hard to know if you have enough knowledge to start diving into real-world applications. The hard truth of the matter is, you never will. Technology is constantly changing. Therefore, so is hacking. So, if you have the mindset that you need to learn a certain amount of topics before you dive into bug bounty hunting, you will forever be trapped in this way of thinking.
Before I started, I had it in my head that I needed to do all of Portswigger’s Web Academy’s courses, all of Hacker101’s CTF’s, vulnerable VM’s like OWASP’s Juiceshop…you get the idea. If I wasn’t able to do all of these CTF’s and labs with ease, how was I supposed to expect myself to find real-world bugs?
Then there was the YouTube spiral. I found all of these amazing hackers online like Nahamsec, Tomnomnom, and Jhaddix. They had some incredible methodologies that I wanted to adopt. I wanted to be just as good as them before even starting. Then, I’d find tons of bugs just like them! I cringed writing that… These guys are great because they have been doing it for years. You can’t start hunting for bugs and expect you’re going to be as good as the greats.
What also helped me dive into it was treating it as a learning experience. You learn as you hunt for bugs. So, I added bug hunting to my regimen of tutorials and CTFs and before I knew it, I was hooked! And I learned a ton! I learned how to do effective recon, how to reverse engineer API’s, practical fuzzing, and the list will only grow the more I learn.
It’s also worth reminding yourself that if you find yourself struggling hard, take that as a win. That’s when quality learning occurs.
Bugs are out there
It’s easy to doubt yourself when bug hunting. I mean the odds are pretty low you’ll find a bug. Most people have already found the easy bugs with automated scanners. All that’s left is the difficult bugs that are going to be nearly impossible to find because the application has already been tested thoroughly by the company’s team of engineers and security researchers. So, it’s pretty much pointless to even attempt looking for bugs.
This thinking is flawed and is known as a scarcity mindset. If you’ve ever worked in a software development environment, you would know that rolling out features and testing them never goes smoothly. Developers are constantly swamped with work and under pressure to meet strict deadlines. The same is true for testers.
I’ve worked as a Quality Engineer and have experienced cases where quick fixes are unavoidable. It surprised me how often people are willing to scrap something together just to meet a deadline.
At the end of the day, we’re only human. People are going to make mistakes and overlook obvious flaws. Bugs are actually plentiful. Don’t believe me? Just take a look at the stream of “Hactivity” on Hackerone’s site or any other bug bounty program for that matter. Even the big fortune 500 companies like Uber and Tesla repeatedly have flaws. Moreover, companies are rolling out brand new features every day, so the attack surface is constantly growing. That’s why a lot of bug bounty experts will familiarize and stick with a few companies when doing research.
Conclusion
If you’re reading this and are thinking about doing bug bounty programs, I highly encourage you to do so. It’s one of the best ways to get real-world experience without having to get a job. I’ve learned so much and have had so much fun in the process. That being said, my experience is my own. You may have a completely different experience than me, so the only way to know gauge whether or not bug bounty hunting is for you is to get out there and do it!
