A little note about Slack’s Bug Bounty program
abhartiya.wordpress.com
A little note about Slack’s Bug Bounty program
1–10 of 52 posts
Re: A little note about Slack’s Bug Bounty program
#2Combined with their recent hack and their exposing of team names a few months ago, I'm becoming wary of using Slack. They don't seem to have a security-focused culture, and that's a massive problem for a communication service.
Re: A little note about Slack’s Bug Bounty program
#3I read the PDFs of #39132 and #51179, and first, these are very clear and well written vulnerability reports. Props to the author for that, many times these reports can be extremely hard to follow and these are shining examples to the contrary. I found them easy to follow, enough details to reproduce, and quite valid issues.
Second, I'll put my neck out here a bit and say, I find myself agreeing with the author's stance. Namely,
1) Independently discovered vulnerabilities are not "owned" by the first to discover it. As a courtesy, you may defer to another researcher, or combine your efforts, but I don't think there's any requirement to do so.
2) 90 days notice is more than enough time to expect at least a cursory response when you say, "Has this bug been fixed? Shall I go ahead and disclose it?", and then again, "This is a heads up that I will be blogging about this on March 12, 2015 i.e 90 days after the initial disclosure unless I hear otherwise. Thanks!", and then AGAIN, "This is a reminder that this bug will be disclosed in 4 days :-)".
In Google's case, for example, it's not just 90 days notice, it's a 90 day deadline to fix. In this case, a simple, "no, we need more time, please don't disclose this" response on the 2nd issue could have avoided the whole problem.
Bug bounties, particularly a fully managed program through HackerOne, encourage Engineers to spend value time and resources investigating and writing up detailed reports of complex issues. If you sign up to run a bounty program, it's essential you give participants the time of day, like responding to their repeated inquiries about disclosing an issue.
It wasn't clear to me if the author was banned from HackerOne or just Slack's program. If the later, well, that's fine, Slack absolutely has the prerogative to invite whomever they like to participate in the program. I think they are missing out on a great contributor in this case though. If author suffered an outright ban on the platform, that would be distressing.
Lastly, if the 3rd vulnerability was unknown to Slack before author reported it, I think author should be properly compensated based on the terms of the program.
Re: A little note about Slack’s Bug Bounty program
#4Combined with their recent hack and their exposing of team names a few months ago, I'm becoming wary of using Slack. They don't seem to have a security-focused culture, and that's a massive problem for a communication service.
[deleted]
Re: A little note about Slack’s Bug Bounty program
#5I'm siding with the vulnerability researcher here. This is ridiculous. The spirit of a bug bounty program is for the company to incentivize a researcher to find bugs and work together to squash them.
Maybe this more telling of HackerOne as a platform.
Re: A little note about Slack’s Bug Bounty program
#6If a company is progressive enough to participate in bug bounty programs they need to be damn certain that they are doing everything possible to interact with their community in a clear and friendly manner. The Slack security team clearly dropped the ball here is regards to properly communicating with the researcher and responding to them in a reasonable amount of time. This type of behavior is unacceptable and goes against the spirit of crowd sourced security research.
Re: A little note about Slack’s Bug Bounty program
#7It feels to me that Slack is trying to be all high-and-mighty/"no you're wrong, we're right [even though you're right]"
Re: A little note about Slack’s Bug Bounty program
#8I read the PDFs of #39132 and #51179, and first, these are very clear and well written vulnerability reports. Props to the author for that, many times these reports can be extremely hard to follow and these are shining examples to the contrary. I found them easy to follow, enough details to reproduce, and quite valid issues. Second, I'll put my neck out here a bit and say, I find myself agreeing with the author's sta…
On point 1, how do they even expect a researcher to know that some other researcher has found the exact same bug if it's not disclosed yet? This seems like a fake rule whose only possible effect is to suppress disclosure.
Re: A little note about Slack’s Bug Bounty program
#9I'm currently in charge of answering reporters on a HackerOne program and I can tell that the way Slack is managing its own is completely unacceptable. Those reports were really high quality ones, whenever I receive a report like that I cry of joy. If you run a bounty program you should:
- Be ready to answer every single report on a short timeframe
- Be fair and provide feedback to the reporter
- Be nice, be thankful and reward the researcher if they deserve it
- Be patient with the duplicate reports and people just trying to get an unfair HoF
Otherwise it may backfire you and eventually it will.
Re: A little note about Slack’s Bug Bounty program
#10I'm siding with the vulnerability researcher here. This is ridiculous. The spirit of a bug bounty program is for the company to incentivize a researcher to find bugs and work together to squash them. Maybe this more telling of HackerOne as a platform.
The stats are right there on the homepage of HackerOne. $2,36m paid bounties and 7,662 bugs fixed. Sounds like a lot of willing participants.