Beginner’s Approach to Bug Bounties
Hi, this is my first blog post on Bug Bounties. As I am new to bug hunting myself, this post is basically a beginner’s advice for beginners starting on VRPs (Vulnerability Reward Programs). These are my views and it may or may not resonate with what you think!
Things I would cover in this article:
- Where to hunt?
- How to pick programs?
- Why stick with programs?
- What to Hunt?
- Reporting
- My initial findings
There are a lot of Crowd-Sourced Platforms and companies that host their programs on their websites.
and the list goes on…
As of now, I have only tried looking at programs from Bugcrowd, Hackerone, Intigriti and Bug Bounty Jp. My advice to a beginner will be to opt for Bugcrowd initially. This is because of the Bugcrowd support team. There are several channels such as chat support, discord group and hidden twitter support as the last option. If you feel violated and unheard only then opt for the last option.
Twitter hidden support is basically Bugcrowd legends like Hakluke, Vortex, Codingo, etc available with their DMs open where you can politely explain your issue with your bug report reference ID. I am sure someone will definitely help you out!
My reasons to initially avoid other platforms and company-hosted programs are:
- Might find the triaggers harsh and unfriendly.
- The zone-specific bounty programs might be in native languages (Japanese, Chinese, Danish, Swedish) which you might find hard to work on in the early days.
- The self-hosted programs are dicey, they may ignore your report or even fix the issue without replying you back and you won’t have anyone to complain.
Therefore going to a reliable crowd-sourced platform with friendly triagger support is important when starting and I will recommend to start with Bugcrowd.
2. How to pick programs?
There are different types of programs:
- Public (Points only and Rewards)
- Joinable
- Private invites
The initial goal is to cut the crowd as much as possible.
I am assuming that you have not yet been invited to a private program therefore the best option you have is to opt for joinable programs.
Go through all those programs (would be initially around 30) and sort them according to the payouts. Pick 8–10 joinable programs with the lowest payouts. Read the scope for all of those programs and even visit the applications that are in-scope.
These will be the probable choices:
- Thick-client applications
- API Testing
- Web Application
- Android Apps
Everyone has a liking for the type of applications they wish to hunt. I like API testing, so I further filtered them out to 4–5 programs that had API testing in-scope. Do check request-responses of the traffic and see which programs you are more comfortable with.
Further, check the scope and the validation time (lower the validation time, the better) and pick 3 programs.
Why pick 3 programs?
There would be times you are bored seeing the same interface, again and again, therefore keep on rotating between a limited set of programs.
3. Why to stick with programs?
Initially, everyone has the mindset “The program has X no. of resolved reports” and therefore they won’t find anything. You should completely avoid this mindset as the company has not halted its development cycle and is continuously pushing new code every day. Checking web archives for an application, you will understand that the structure might be completely different as compared to what it looks at present.
Approach it as:
Old Program → Less Crowd → New Code → New vulnerabilities → 💰💰💰
Therefore, avoid looking at other programs for atleast 2–3 weeks and only focus on these programs.
Once you stick on a program and have enumerated it multiple times, you will see changes in code, functionalities that have been recently added, stuff that has been removed and so on. This really helps to understand how developers are progressing with the application + you will have an advantage over new hunters (they won’t know the recent update timeline).
4. What to Hunt?
You might be good at CTFs or maybe practising on Juice Shop, etc but hey it won’t be that easy. Companies are paying you money for the issues that weren’t resolved after several rounds of traditional pentesting.
Firstly, read the VRT and understand what to ignore and what to report.
Next, opt for easy bugs such as:
- CSRF (Cross-site request forgery)
- IDOR (Indirect Object Reference)
How to Hunt for these bugs?
- Read about these bugs from Real-World Bug Hunting: A Field Guide to Web Hacking and watch InsiderPhD’s series: Finding your first bug
- Practice CSRF on Portswigger Academy.
- Read lots of bug bounty reports from:
https://github.com/devanshbatham/Awesome-Bugbounty-Writeups
https://pentester.land/list-of-bug-bounty-writeups.html
5. Reporting
This is the most important part while submitting your bugs. Keep it as detailed and simple as possible, so that it’s easier for the triagger to understand the impact and triage the bug as quickly as possible.
Few Key Points:
- Follow a structure on any type of bug you report.
Something like:
## Description
Explain the bug-type in 2-3 lines## Impact
Explain the damage in 1-2 lines ## Steps to Reproduce
Instead of writing a paragraph, add bullet points with screenshots of as many steps
as possible.
- Add curl commands if possible.
- Be humble to triaggers.
6. My Initial Findings
So I picked a program which was 2 years old with API-Testing in-scope. I started looking at the program on 20th June 2020. All the bugs found were on the main domain. No fancy recon tools were used to hunt these bugs. Simple community edition burpsuite and some basics were sufficient.
The report submissions are as follows:
First Bug:
Submitted a bug as soon as I saw something interesting (Don’t make this mistake, understand the problem completely before reporting it).
Second Bug:
I started understanding the application and got a duplicate. Yes, they are not fixing it but it is still a valid bug!
Third Bug:
Got my first bounty on Bugcrowd! I was able to downgrade an admin to a low-priviledged user. I used the trick explained in InsiderPhD’s API Testing video. At this point of time I had understood what I was doing and the structure of the main application.
Fourth Bug:
While testing a different approach I mistakenly made a payment of 10$. This provided me access to a broader scope on the main application. Ended up finding sensitive information disclosure.
Fifth Bug:
This was rather a conceptual and simple bug. I was able to make changes on my team-group (specific function on the program). Basically, I could generate tokens for new team members and make changes which would not traceback to my user, therefore should not be allowed. It was considered a low severity issue because I needed a priviledged user to conduct this attack.
To sum up, I opted for this specific program for 2+ weeks and I started getting results! I hope this helps you to find your first bounty.
Summary
This blog post was for beginners targetting how, where, what to do when starting with bug bounties. In the last section, I briefly explained how I used the same methodology to find some easy bugs.
If you like this blog post, follow me on Twitter. Do leave a comment if you found it interesting or made your first bounty with this approach.
Happy Hunting:)
