This post is a review of my bug hunting journey so far, from when I just started, to the point where I made it into the Top 200 bug hunters on Bugcrowd recently, after two years on the platform.
The Beginning Phase
Like anything else in life, you must start somewhere, or you will never make it. The worse way to fail is to never even get started.
As I have also mentioned previously in my post last year, “A Review of my past one-year in Information Security“, when I first heard about the concept of bug hunting, I was so excited and participated on the various bug bounty platforms, such as Bugcrowd and HackerOne.
However, the amount of enthusiasm does not necessarily get translated into capability, as a result, I reported the most absurd things that one could think of.
Indeed, these are the kind of issues that we would usually raise in a penetration testing report, to let our clients know that such issues do exist in their applications. However, they are not exactly considered as an accepted bug in the industry of bug hunting. I will address this topic later in this post.
Why am I sharing these?
Some people might be thinking, why am I sharing these embarrassing reports? Most people would just keep quiet and never ever mention them again.
Well, I just want to proof two things:
- No one knows how to hunt for bugs the moment they are born. In fact, this applies to anything in life. You have to keep learning and improving.
- Everyone makes mistakes. The most important thing is that you learn from them. If you learn from your mistakes, then you have not actually failed. The real failure is when you made a mistake, but you never learn.
The Confused Phase
There will always be a point where you reported bugs that you think is an issue, but the interpretation may not be mutual.
This could be related to the topic of a Managed bug bounty program, where your reports will be triaged by the security analysts employed by the platform, versus an Unmanaged program, where your reports will be triaged by a representative from the program’s company). I shall leave this topic to another day.
If you ever run into a situation where you are so sure your report is valid, but the security analyst (be it a managed or unmanaged program) insists that there is no risk or the risk rating is much lower than what you have calculated, my advice to you is to stay calm and reassess the situation again.
It could be their mistakes, but be nice and be kind
Look, the security analysts are also human, and human makes mistakes.
Let alone the fact that their job is to read a bunch of reports all day long and triage them. A number of these reports may not even be reporting a valid bug, just look at the statistics of Facebook’s bug bounty program in 2018, only 3.93% of the submitted reports were valid!
Some of these reports might be so badly written that it doubles up their job. For example, when there are no steps provided to reproduce the reported bug, or when the steps provided are extremely unclear.
The most important thing here is to be polite, be nice, be kind and understanding towards their situation. Stay calm and try to ask them to explain why they made those decisions and have a proper conversation with them. It doesn’t do you any good by scolding them or typing in “CAPS”.
To be honest, I tend to feel frustrated when I read full disclosure reports where the researcher typed in “CAPS” to simulate “shouting” at the security analysts because their report was not rewarded.
It could also be your mistakes, be open-minded and accept feedbacks
Yes, it could also be your mistakes. Learn to be more open-minded and accept the feedbacks from the security analysts. The fact is that they have most likely triaged more reports than you have ever reported (especially if you are just starting out).
Maybe you are just missing out on something that they see but you don’t. I am pretty sure that most of the security analysts are more than happy to explain to you the reason why your report is not rewardable and/or why its assigned risk rating has become lower than what you have previously indicated.
If you are still not sure, ask someone, or start a discussion somewhere
That’s right, you can always ask someone for their opinions or start a discussion with fellow bug hunters in the industry.
You could consult some of the more experienced bug hunters in the industry. Be polite and ask them for their opinions about the situation that you are facing. Unless it is a super tricky situation, most of the time, based on their experience, they should be able to point you the right direction or resources to read up more.
Bugcrowd Vulnerability Rating Taxonomy (VRT)
Earlier in the article, I mentioned how some valid bugs were not accepted or rewardable in the bug hunting industry. This is a pain point that bothers me until today, which is also the reason why I am slightly less active on HackerOne – every program has a slightly different list of bugs that they accept, and the people who triage your report could varies from a HackerOne staff, a client’s employee or even a fellow researcher.
It’s not wrong, just a different way of doing things. I still like the platform very much, just that I usually choose to participate on Bugcrowd instead, due to their VRT which allows me to have a good idea on what to expect on the platform.
Based on my experience, 95% of the time, the programs on Bugcrowd would abide strictly to the technical severity listed on their VRT.
This means that I could spend lesser time reading a wall of text on each programs’ brief to know what bugs they accept and whether they are considered low risk or high risk.
Definitely a Good Guideline for Starters
It also acts as a very good guideline for people who are new to bug hunting. For example, they immediately know that if they reported a valid subdomain takeover bug, they can be rewarded a bounty within the P3 technical severity. The exact amount is dependent on the program, but at least you get an idea for a start!
You will also know what kind of bugs are rewardable. A common example of a non-rewardable bug is the username enumeration via brute-forcing. It is classified under P5. Even if the report is valid, you won’t get rewarded with any bounty, and it affects your profile’s average severity.
What is the Average Severity and why is it important?
Your average severity is important because if you want to receive invitations to participate in private programs, your last 90 days performance must include the following 3 criteria:
- Reported a valid vulnerability on any program
- Maintained an accuracy of above 50%
- Submitted vulnerabilities with an average technical severity of below 4.0
A P5 bug equates to a 5.0 technical severity, which could jeopardise your chance of getting an invitation to a private program.
The Learning Phase
I can go on forever, but I think I will keep this section as short as possible, since this section is an ongoing process.
That’s right, I am currently still in the learning phase, where I am still exploring things and keep learning new things every day.
Recently, I encountered my first Java Deserialisation bug on a private program. Unfortunately, I did not manage to exploit it successfully. The good thing is that I have learnt many new things during the process of attempting to exploit this bug. At the end of the day, I felt contented even though I did not receive any reward for it.
My Performance on Bugcrowd so far
To share a better picture of my journey so far, here’s a graph showing the trends in volume of submission reported on my Bugcrowd profile:
As shown above, on alternate quarters, I reported slightly lesser bugs as I was attending school classes.
Yes, I have recently completed the final semester of my course in the Master of Computing (Infocomm Security Specialisation), which explains why I was able to submit a higher-than-usual amount of reports in 2018 Q4.
I am sure 2019 will be a far more awesome year for bug hunting, as the industry is now becoming more mature and accepted by companies. There seem to be many more bug bounty platforms appearing as well, so you guys can expect me to occasionally appear there too. I don’t know which ones to try out yet, so if you guys have any opinions on this, please feel free to share them down below at the comments section.
The following list of resources are fantastic and has helped me a lot during my learning journey to become a competent bug hunter:
If you have more useful resources to share too, please post it in the comments section down below.
As promised on my LinkedIn post, this is my bug hunting journey so far as of 2018, I hope it has managed to motivate at least one other person to keep improving and never give up in whatever things they like to do, be it bug hunting or anything else.
If you don’t believe in yourself, who will? Some things may seem impossible to achieve at first, but if you don’t try and if you don’t believe in yourself, then you can never make it.@kongwenbin
If you have also been participating on bug bounty platforms so far, please share your experience and your journey down below in the comments section, I am sure many of us would be interested in reading about it.
On the road to success and happiness, the rule is always to look ahead and keep going forward. May you reach your destination, and may your journey be wonderful too. Stay awesome. Happy New Year 2019!