I’ve been increasingly using Bugcrowd lately, a platform that manages security bug bounty programs for its clients and allows security researchers to contribute to a number of such programs easily. Previously, I’ve mostly reported security issues in Mozilla and Google products. Both companies manage their bug bounty programs themselves and are very invested in security, so Bugcrowd came as a considerable culture shock.

First of all, it appears that many companies consider bug bounty programs an alternative to building solid in-house security expertise. They will patch whatever bugs are reported, but they don’t seem to draw any conclusions about the deficiencies in their security architecture. Eventually, even the most insecure application will have enough patches applied that finding new issues takes too much effort for the monetary rewards offered. At that point, almost no new reports will be coming in and for the management it’s “mission accomplished” I guess. Sadly, with security being an afterthought the product remains inherently insecure, even the smallest change could potentially open new security holes.

Actually, Bugcrowd makes it very easy to take that route. The majority of the bug bounty programs are private, meaning that not only are security researchers forbidden to discuss the issues they find, they aren’t even allowed to discuss the existence of the bug bounty program. So the vendors don’t have to fear publicity when their product (which is sometimes supposed to be a security product) turns out to be full of critical bugs.

Communication with security researchers is also remarkable. Recently, I reported a major vulnerability that allowed websites to inject code into a browser extension. I noted all the things that this code could potentially do, such as reading cookies from any website. But my proof of concept was limited to retrieving user’s data and showing their user name. Here is a reply that I received:

I was able to verify the issue. Can you create another poc, that reads some sensitive information(like passwords for example), so we can make a case for a higher priority? For now, this seems equivalent to a reflected XSS/ P3 to me.

I’m used to providing a minimal proof of concept, and this isn’t the first time that I was asked to demonstrate the issue “properly” on Bugcrowd. This comment finally made me realize the problem: with Mozilla and Google I used to communicate with developers. On Bugcrowd however, the triaging is often being done by people who cannot analyze a proof of concept and merely try to categorize an issue in terms of the vulnerability rating taxonomy.

With out of the box vulnerabilities and particularly vulnerabilities involving browser extensions that categorization becomes a very non-trivial task. It doesn’t help that many companies apparently outsourced the first contact to Bugcrowd’s “experts.” These might indeed have great knowledge of security issues, but occasionally they will have even less product knowledge than me. As a consequence, the important information in your report isn’t considered the line of code causing the issue but rather the proof of concept which shows exactly what harm one could do with it. There is a clear monetary incentive for that: you won’t be paid more if you can pinpoint the issue in the application or provide good recommendations, yet you will definitely get paid less if you underestimate or fail to communicate the scope of the issue you discovered.

The consequence for me (and others before me as well it seems) is that participating on Bugcrowd requires an attitude change. Normally, I report security issues because I want a product to be secure. So I will report all issues I notice no matter how minor, and I will occasionally provide recommendations on addressing this entire class of problems. With Bugcrowd, this approach doesn’t work. For example, the few clickjacking issues I reported didn’t go anywhere because the proof of concept wasn’t reliable enough. I could probably produce a reliable proof of concept, but for clickjacking this is lots of work. Yet clickjacking is a P4 issue that will typically be rewarded with $100. Investing so much time in minor issues just doesn’t pay off, and neither does writing recommendations that most likely won’t make their way to the developers. Worse yet, too many reports of minor issues will degrade my rating on Bugcrowd and prevent me from being invited to private bug bounty programs.

Now Bugcrowd isn’t the only platform in this field, HackerOne being the other big player. I don’t have enough experience with HackerOne yet, so I cannot tell whether the same issues are present there. If somebody knows, I’d love to hear.