Google’s bug fail is something to learn from
Web giant suffers embarrassing security incident and shines a light on vulnerability research
Google has been forced to admit a somewhat embarrassing security error - not one that affects the public directly, but one that in many ways illuminates the corner of the security world concerned with bug bounty hunting.
The Mountain View giant launched a targeted bug bounty programme called The Project Zero Prize on September 13, 2016 to some fanfare, but this week has shuttered the scheme, having received no valid entries at all. Google said in a blog post: “Throughout the contest, we did not receive any valid entries or bugs (everything we received was either spam, or did not remotely resemble a contest entry as described in the rules). We did hear from some teams and individuals who said they were working on the contest, but they did not submit any bugs or entries.”
One of the major stumbling blocks was highlighted at launch, as several people immediately pointed out, that an exploit fitting the competition’s fairly tight rules (a vulnerability or bug chain that achieves remote code execution on multiple Android devices, knowing only the devices’ phone number and email address, with no user interaction) would be worth far more than the $200,000 prize money. As one commenter pithily put it: “200k not worth for finding needle under haystack.”
It’s not long since Google raised their standard vulnerability bounties, in some cases raising them by an impressive 56.7 per cent, although it’s not clear whether the status of The Project Zero Prize fed into this rise, it seems likely it did.
Ilia Kolochenko, CEO of High-Tech Bridge commented at the time: “This potential ‘pay-rise’ for white hat hackers tells something for certain - that Black Hats are paying more for vulnerabilities, and even the highest bounties offered by Google and Microsoft are no longer competitive with what cybercriminals can offer now.”
“The rise in bounty clearly means that talented White Hat security researchers are too busy with their well-paid daily jobs to bother spending time hunting risky bounties (even if you find a flaw, but someone has found it one minute before you - you will get $0).”
Google agreed with the latter point, admitting that although their contest rules were designed to encourage participants to file partial bug chains in the Android bug tracker during the contest, as only the first finder could use a specific bug. However, participants chose to save their bugs for other contests that had lower prize amounts but allowed user interaction, and accept the risk that someone else might report them in the meantime.
“In designing these rules, we underestimated the impact of other contests on participants’ incentives”, said Google.
The Project Zero Prize failure demonstrates several things - firstly, that every company makes mistakes, which Google to be fair has been entirely self-critical about: “Overall, this contest was a learning experience, and we hope to put what we’ve learned to use in Google’s rewards programs and future contests”. If you make the competition too difficult, nobody will enter, thanks to human nature.
Finally, as Yahoo’s T-shirt-gate and Cloudflare’s Cloudbleed issue in particular have illustrated, simply having a bug bounty programme with t-shirts for incentives isn’t enough. In fact, having an in-house bug bounty programme that isn’t up to scratch is simply a PR disaster waiting to happen, an obvious signpost for post-breach finger-pointing.
Perhaps the most useful reading of this event for enterprises that don’t have the digital resources of Google is that an in-house bug bounty programme isn’t in any sense the cheap solution that it was once heralded to be. Outsourcing this time-sink and potential PR nightmare is making increasing sense, as the rise of ‘community’ bug bounty platforms such as Open Bug Bounty and HackerOne indicate.
Time to outsource your own Project Zero Prize?