I’m sure others like myself in the community are asking if website vulnerability bug bounty programs a good idea to begin with and if such programs an anomaly or the start of a 2011 trend?
If we posed the first question to bug hunting masters Charlie Miller, Alex Sotirov, and Dino Dai Zovi there is no question how they’d answer. "No More Free Bugs." Not that all researchers must ascribe to this philosophy, it’s a personal choice, but there certainly shouldn’t be a stigma attached to those who do. The thing is the bugs these gentlemen generally focus on reside in desktop-based software developed by large ISVs. Software that can be readily tested in the safe confines of ones own computer where permission is not strictly required. Website vulnerabilities are in a word, different.
Website vulnerabilities reside in the midst of a live online business, on someone else’s network, where penetration-testing without permission is illegal and the results of which may cause degraded performance and downtime. Not that legalities ever really got in the way of a free pen-test. See the thousands of public cross-site scripting disclosures on XSSed.com. Still, I’d personally agree that while bug bounty programs can indeed be a good idea for a certain class of website owner, I think everyone would recommend thoughtful consideration before opening up the hack-me-for-cash flood gates.
What’s most interesting to me is understanding why Google and Mozilla themselves believe they need a bug bounty program the first place. It’s not like Google and Mozilla don’t invest in application security or would depend on such an initiative. In fact, from my personal interactions their level of application security awareness is top notch and practices represent among the most mature across the Web. They invest in source code reviews, security QA testing, penetrating tests / scans conducted by insiders and third-parties, developer training, standardized development constructs, threat modeling, and a collection of other Software Security Assurance (SSA) related activities. Activities most organization are still coming up to speed on.
So Google and Mozilla have already done essentially all our industry "recommends." Yet, as the multitude of negative headlines and unpaid vulnerabilities disclosures historically show, issues are still found by outsiders with annoying regularity. Personally I think that’s where the motivation for a bug bounty program comes from.
Google and Mozilla probably view their bounty programs as a way to remove additional missed bugs from the vulnerabilities pool, remediate them in a manageable way, foster community good will, and for the low low price of few hundred to a few thousand bucks. Check it out. In the first two months of Google’s program, it looks like they’ve paid out a few 10s of thousands of dollars to three dozen or so researchers. Said another way, the PR benefit is perhaps three dozen user confidence shaking news stories DIDN'T get published. All in all for that price, suddenly the idea of paying "the hackers" doesn’t sound as crazy.
It should be made crystal-clear that bug bounty programs are in no way a replacement for any part of an SSA or an SDL program, rather they are complementary and an opportunity to facilitate improvement. Also, bug bounty programs are not for everybody, and probably not even for most. Only those organizations that truly have their application security act together should even consider offering such a program.
For example, the organization should already have reasonably bug free websites or they won't offering attractively priced bounties for long. Budgets would run out fast and they’ll be forced to suspend the program, which would be quite embarrassing. The organization must also have a strong process in place to receive, validate, respond, act upon, and pay out for submissions. Next as Mike Bailey, a self proclaimed Narcissistic Vulnerability Pimp elegantly stated, "bounty program also involves an implicit commitment to fix bugs quickly." That’s right, no sitting on bugs for a "reasonable" amount of time -- like months to a year or more. Finally the organization will require a super-stable infrastructure capable of enduring sustained attack by hundred or perhaps thousands of entities.
In my humble opinion if an organization has all of this in place, then I’m confident in saying there is a correlation between bug bounty programs and website vulnerability management / SSA maturity.
Jeff Moss, the man behind Black Hat and Defcon, recently encouraged Microsoft, a firm long opposed paying for bugs, to offer a bounty program. "I think it is time Microsoft seriously consider a bug bounty program. They advanced the SDL, it is time for them to advance bounties." I’ve suggested the very same to Microsoft in person on more than one occasion. Veracode has that as a 2011 infosec prediction. Everyone I know of has received a response similar to the following:
"We do not believe that offering compensation for vulnerability information is the best way we can help protect our customers." - Dave Forstrom, group manager of Microsoft Trustworthy Computing.
And there you have it. Is the website vulnerability bounty program phenomena the start of a trend? Who can really say? Only time will tell.
I really enjoyed this post. It was well thought out and informative, but you appear to still be on the fence as to your final opinion of these programs.
One area I see tremendous potential is in the responsible disclosure of new attack methods. Bounty programs would incentivize a researcher to notify companies of an issue prior to publicly releasing the method.
What are your thoughts? Would you ever offer such a bounty?
At BayThreat, while I was talking to 12-year-old Alex Miller, he was asked if he was going to look for bugs in other programs/websites. He replied that Mozilla paid well, so he was going to stick to bug hunting Mozilla.
Since Microsoft has the Microsoft Active Protections Program (MAPP) where they give security product vendors early access to vulnerabilities and sometimes even exploits, maybe they can pass the bug bounty expenses onto the vendors through membership fees into that program.
@Anonymous: Your right in your observation, I'm very much on the fence. The big reason is the lack of evidence, because such bug bounty experiments are new, the true benefits and pitfalls are largely unknown. Would I have advocated such a program while back at Yahoo, more than likely. At WhiteHat, hmm, probably not. Still, couldn't give a compelling and coherent reasons why yet.
@Bil: ahaha, that's awesome.
I'm in two minds if it's a good thing.
First I think it's great.
I'm taking part in the Google Program and intend to look at some Mozilla sites in the near future. So I find bugs report them in a responsible way and users are more secure.
Now my other opinion. I find bugs in parts of their site that are not yet included in the bounty and I hold on to them in the hope that one day that site or app will be included. Now before the bounty offering I would have either declared it publicly meaning a fix would have been quickly done or I would have responsibly disclosed.
However now I guess there are many others who have many bugs in Google infrastructure and are holding onto them in the hope that the site or app gets included.
This makes their users less safe then not having the bounty scheme.
In all I'm in favour.
MS needs to get in on the act.
See below for example of holding on to XSS issue in the hope that they start a scheme.
No More Free bugs
@thetestmanager: yes, we ran into that same sort of issue with Google when submitting bugs on sites they technically owned, but were out of scope. The website owner just has to realize and be OK with those externalities.
Hi,its nice to read a useful article for beginner like me.Some of points from this article are very helpful for me as I haven’t considered them yet.I would like to say thank you for sharing this cool article.
@thetestmanager: you should send those bugs in instead of sitting on them. We've paid out for a few technically out-of-bounds issues since the program started. If your bug has a genuine "wow" factor, you might find that our researcher-heavy rewards panel is inclined to be generous ;-)
We get a lot of duplicate submissions. If you sit on the bugs, someone else may well report them and take a shot at the cash.
In your post of December 10th ("Spoofing Google search history with CSRF") you show how Google is vulnerable to CSRF. In this post you say about Google that "their level of application security awareness is top notch and practices represent among the most mature across the Web". I have a problem reconciling the two points. Is it because Google does not think that CSRF is a big issue, or that it is not a big issue in this case?
As you said, using CSRF you could force the Google user to search for something extremely damaging. So I think the CSRF vulnerability you demonstrated is a significant web application vulnerability. If you submitted the vulnerability as part of their bounty program, would they pay up?
I am interested in hearing your thoughts as it does puzzle me.
@Alexis: Good question. I don't think Google views this particular issue as "high risk." Secondly 'solving' the issue is probably not worth the effort it in terms of resources and loss of functionality. To which, I'm not inclined to disagree with their choice. Users are capable of taking action to defend themselves if they'd like to.
I previously knew that Google was very well aware of this issue prior to me posting it. Otherwise, bounty or no bounty, I wouldn't have published the details without first bringing it to their attention.
Hopefully this helps answer the question. While reasonable people can disagree with an appropriate course of action, I still maintain Google's awareness of webappsec issue is among the highest in corp Americal.
Post a Comment