Bug Bounty Program Insights

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.

One of these bogus reports included a couple of “critical vulnerabilities” in our Kali Linux bug-tracker, including persistent XSS and file upload vulnerabilities, which obviously caught our attention. Looking deeper into this report, we quickly realized that the reporter was uploading HTML files containing JavaScript to the public bug-tracker, downloading and opening these files in a browser (through an obtuse process), and calling it an XSS vulnerability. In this case, the JavaScript was executing locally and was not usable to obtain session information from the targeted site. A second, “more severe”, vulnerability entailed “upload and unauthenticated download” of files, which under the context of a public bug tracker full of public information, is expected behavior.

Perspective is Everything

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.

Demonstrating the Vulnerability

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.

Bug Bounty Trolls

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.

Rules of Engagement

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.

Advice for Bug Bounty Program Participants

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:

• Be courteous. You’re about to tell someone their security stinks. Be nice about it.
• Be descriptive. The more details you provide, the easier the bug will be to reproduce.
• Don’t be assumptive as you could be dead wrong.
• Read guidelines and communicate with the organization if questions arise.
• Maintain professional integrity and avoid burdening your target with your tests. They won’t like this.
• Maintain professional integrity and keep your private communications private, even if you disagree.
• Don’t be demanding. Signing off emails with “reply immediately” is a total turn-off.
• Respect the systems you’re testing. They are probably production.
• Be humble. That’s not a bad piece of advice for life, either.

What You Should Expect From Us When Joining Our Bounty Program

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:

• Quick replies. You’ll usually get answered in a few hours unless we think you’re trolling.
• Short replies. We don’t go to lengths to explain our decisions.
• Technical know-how. We understand vulnerabilities.
• Technical know-how. We quickly spot fakes and trolls.
• Prompt payment if your bug qualifies for our program.
• Extreme Gratitude from the Offensive Security team and a mention in our “heroes” section! (soon)