With the nature of our business, we at Offensive Security take our system security very seriously and we appreciate the benefits of having “the crowd” scrutinize our internet presence for bugs. For this reason, we recently started our own Bug Bounty Program, which provides incentives for researchers to inform us of possible vulnerabilities in our sites in exchange for cash rewards.
We already consider this program to be a great success as in less than 24 hours, it paid off for us when we received a report of an unauthenticated file upload vulnerability in our WordPress theme. Fortunately, file permissions on our servers along with other mitigations put in place prevented abuse of this vulnerability, however after a mere 24 hours we already saw the benefits of this program.
Saying this, the first few days of the program were a learning experience as we were flooded with dozens of false and dubious reports. Everything from “critical directory indexing vulnerabilities on http://cdimage.kali.org” to “Apache version disclosure” reports. Thankfully, this died down after a couple of days.
Up to this point, every time I’d read a story about bounty researchers not getting rewarded for their efforts, I would find myself automatically siding with the researchers. The mean greedy company should just pay the poor researcher and not just take advantage of free research, right?
This one researcher didn’t like our answers and insisted the vulnerabilities existed – to the point of tweeting his disapproval multiple times, all the while CC’ing news outlets almost as if he was hoping the “media would get wind of this”. The next day he took the time to write a blog post, describing his horrible experience with our bug bounty program. To an untrained eye his repeated vocal objections might seem legit – yet another case of the big bad company refusing to pay up. But apparently, perspective is everything.
In this case, all the researcher needed to do was verify his findings and see if a file upload could actually result in a vulnerability, or if the XSS could actually be used to steal session information. A simple document.cookie or document.domain would be enough to quickly convince us we were wrong in our analysis. By not being thorough and completing these tests, the researcher set himself up for failure.
Not surprisingly, bug bounties come with their own sets of issues. The “crowd” may not always read instructions to the fullest or have the necessary skills to test and verify vulnerabilities. Yet you need to deal with these individuals all the same, politely. The ones you disappoint may be vocal, sometimes to the point of extortion. Yes, bug bounties have their own trolls.
From our point of view, a bug bounty is a reward given by an organization to an individual for helping find previously unknown problems as a token of appreciation. In other words, a bug bounty is a reward, not an obligation.
As penetration testers, we have very strict rules of engagement. In bounty programs, these rules become fuzzy and boundaries can easily be crossed. In our case, the researcher seemed to think it was ok to spam our Kali Linux bugtracker with XSS attempts, with no regard to the fact that it’s a production system. In one of his tweets, he even expressed his surprise and frustration at being banned from this tracker. Go figure.
Although none in our team have participated in bug bounty programs, we’ve found our fair share of bugs and reported them responsibly. Here are a few tips to get good communications going back and forth when contacting an organization with a bug report:
The reason we have a bug bounty program is because we want to squash our bugs and are willing to reward people who point us to them responsibly. Saying this, not all types of bugs interest us. Check our bug bounty page for more information about this. You can expect: