Bug Bounties have given me a good chance to try out the few things i know, and learn the giant’s share along the way. I was able to meet some like minded people from my country like smokin-ac3z and fakejoker who have given me some great insights. I have been able to learn a couple of things and taken a good number of technical concepts, but the most important of them all is about communication and professionalism.
Sadly, not all journeys are perfect. Bug bounty most certainly isn’t either. From the report writing needed, i have developed a better way of writing articulate and concise reports. Nailing every needed hammer to showing impact and criticality, but most important of all, be professional and understandable.
It is very clear that misunderstanding and lack of proper communication have been the key to disagreements between researchers and programs/triagers. I must agree the memes that come with it are funny. Like the famous still meme below. LOL.
As much as programs expect the best of reports and proper behavior from researchers, some may not always return the favor in a couple of ways. From my previous experiences and online complaints, i have come up with a couple of ways programs lack professionalism and let down those holding the fort like bosses! Let’s dig in:
Poor communication
Probably the most annoying thing some programs do. I however have a fair share of experience on programs lacking this. No feedback about anything. The same level of communication expected when a researcher is asked to clarify on a report is the same when a researcher asks for clarification about progress and whatnot.
Receiving a report and going quiet while ignoring tons of messages then only responding while awarding a bounty is not cool. So not cool. Program managers should talk to their security team and emphasize the need for proper communication.
Not understanding a vulnerability
While researchers may try their best to explain an issue, experience on the receiving end is a necessity. If the security team does not understand the vulnerability or impact, it going to be a real hustle. I have witnessed cases where the security team claim an sql injection is not possible and closing the report just because they cant verify it. Only to reopen it later on after a mediation request. Security teams not understanding that different vulnerabilities that are solved differently but lead to the same level of compromise are to be handled differently.
A good way of approaching this sort of situation for programs with this sort of thought is reporting a vulnerability once the previous one is resolved. This will make more sense to them.
Fixing an issue before triage(and going silent)
Don’t get me wrong. In cases where a researcher sheds light on a critical vulnerability, it is logical to act fast and fix/remediate. However, when this is done before triage and the program team goes silent, this is a clear sign of unprofessional-ism. Leaving the reporter to explain to the triager how “the vulnerability was there a few minutes ago” is just not fair. Program teams should at least communicate that they saw the impact and acknowledge it as they do a quick fix.
If a program has a habit of doing this, you better “kazam” and do a screen recording clearly indicating the timestamp during vulnerability confirmation.
Reduced payouts
When the teams fail to understand a vulnerability impact and pay out less for its actual worth. Reducing an RCE impact just because the reporter used the commands “id” or “whoami” on the PoC instead of uploading an interactive web shell. Understanding impact makes for better judgement and more stable and well deserved payouts.
Developer/team mistakes
A memorable one was when i got hold of a subdomain and got hold of full project backup. An sqli followed shortly after. However i was slammed with a “The developer was to take this offline but forgot to do so” excuse.
This issues were later on fixed within an hour and the report severity diminished to a mere low. Just because it was meant to be offline. Personal data retrieved from the sqli dated a few minutes back, proving to be very recent and active. But hey, the program is always right, right?
Conclusion
Researchers and not always right. But neither are programs. Finding the common ground and adhering to some professional behavior will however make for a good relationship and increase chances of program loyalty and increased/better reports.
As i am aware not all issues have been highlighted. But only the most common. Its never that hard. Just a gesture of moral responsibility and obligation to be fair.
Stay safe, whom it may concern.