The Dark Side of Bug Bounty Programs

Bug Bounty programs have transformed the security world for the better. Rather than pretending their software doesn’t have any bugs, software companies offer to pay people for finding and reporting legitimate software vulnerabilities which someone more nefarious could use to compromise customer data. Almost every big software company and now even the U.S. Government are directly rewarding people for hacking them. Some pay more than others (tip: Apple will pay up to $1 million, but the Government caps out at $5,000).

You Really Need to Have a Bug Bounty Program

Even startups should have such programs set up. They aren’t hard to put together or to administer. We manage ours with Google Forms and a web page giving the rules and rewards. Feel free to head over to our trust center and check that out (search for “bug hunters”).

Nicole Perlroth’s excellent book, “This Is How They Tell Me the World Ends: The Cyberweapons Arms Race”, does a great job of illustrating the before-and-after of bug bounty programs as well as showing the real dangers of not having one. These can be summarized as, if you don’t buy the bug, someone else will, and that someone else will use it.

Here’s Why It Hurts

So why do I say there’s a dark side? Because your average bug bounty hunter doesn’t read the rules first. They don’t pay attention to what is in or out of bounds. And that leads to noise and hassle and arguments.

I’ll give an example: we specifically exclude email systems from our program. We use a third-party provider for that. It isn’t really software in our control. Plus we have SPF and DKIM records set up (pretty much as good as it gets for email “security” these days). Yet we kept getting reports from people telling us that our domain’s policy wasn’t to enforce DKIM. Eventually we got tired of hearing about it and set it up so if something isn’t properly signed from IronCore, it will go to spam.

Oddly, Our Regular Email Deliverability Suffers

Now we don’t have to hear about it anymore from bounty hunters, but now we find that our mail isn’t as reliably delivered. Why? Because some companies have complicated email server setups where one server receives the mail, then some scanning or something happens, then they forward the mail on to an internal mail server. We pass the initial checks, but on re-send, the DKIM signature breaks or the SPF record saying which IPs can send mail on our behalf breaks or both and then our email goes to spam. Even though it was legitimate. This is why we can’t have nice things. For now we’re leaving the policy on to make it harder for someone to impersonate us, but it’s a tough trade-off.

But look, we welcome feedback even on the smaller things. We’re a security company and we want to get it right at every level, to the extent possible.

Our Sales Team Gets A Lot of Spam

But our poor sales team gets garbage chat requests all day as people put special characters into the chat bot to see if they can break it. That’s way out of scope. All of that code is a third party. They’re not even testing us. Sometimes they claim to have found a problem and we have to tell them to go to the vendor there, which they don’t like to hear at all.

Bug Bounty Programs Are Still Worth It

To be fair, we’ve received some really fantastic reports alerting us to real issues. Some have been minor like the person who reported that we had a link to a Facebook page, but we had taken down our Facebook page leaving an opportunity for someone else to come in and make a fake one. Others have been meaningful issues with session management around password changes and potential XSRF attacks. To anyone who has reported a real issue that we’ve fixed: thank you. And hopefully you got a reward or at least some swag (though boy do we have trouble getting t-shirts shipped to folks in India… why is that so hard?).

I wish it were all like that.

But You Have To Manage Annoying Situations

We’ve had incredibly combative folks who don’t like to hear that something is out of scope or comes from a third party that they should report to instead. We’ve been threatened and called names when someone reports something that their automated scanner told them was true, but which isn’t actually a bug – even when it’s easy to verify that. And almost every day we have bogus signups to our services with silly emails and names. Our reports on new signups are sometimes pages deep with garbage characters as someone tries to find a SQL injection or XSS flaw.

We’re Modifying How Our Bug Bounty Program Is Found

Apparently, we have very good SEO around the words “bug” “bounty” and “reward”. Our bug bounty page is our fourth most visited. So lots of people who are making their living finding security flaws are finding our website and hitting it. I’d guess that 99% of what each new person does was already done once already that day and 10 times already that week. The end result is that of the reports we get, very few of them are real or actionable. But we still have to wade through the reports and make sure our systems handle the onslaught of testing.

Moving forward, we’re going to keep our program. It’s the right thing to do and has produced some good results. But we’re going to remove our bug bounty page from search engines in the hopes that the amount of garbage traffic to our site, to our security team, and to our sales team falls to more tolerable levels. We’ll keep the page linked from lots of places, just with a request to the search engines not to link to it directly. We’ll see how that goes.