31–40 of 52 posts
As it stands, if I'm ever in a place considering using Slack, I would be coming back to this HN thread to see how this particular issue was resolved.
More (or less?) shocking here is the total lack of an official Slack response to this thread. Does not bode well..
http://slackhq.com/post/114696167740/march-2015-security-inc...
(And I can't help but wonder if these two issues aren't connected somehow. Someone may have been sitting on a 0day trying to do the right thing in expectation of a bug bounty program reward, only to discover exploiting or selling it was the only avenue likely to actually pay out... Surely this isn't just coincidental timing?)
But there's simply no excuse for the mediocre treatment of what by all accounts appears to be an authentic bug and genuine submission (and with quite a bit of care and energy behind it).
We'd love to have a way to encourage security researchers to focus on our software and give us reports, but we're Open Source and our budget is miniscule. What is considered "insulting" as a minimum reward? What will actually get professional people looking at it with a critical eye? Is its popularity (~1 million users and a pretty well known Open Source project) enough to compensate for not paying very well for disclosures?
I was awarded for a big bounty for finding a big hole last summer (and it is a BIG one). I had a pleasant experience. Maybe the folks who were managing the program are gone. But it is sad to see that some people had negative experience. In general, Slack is full of security holes, if you look at the number of bounty awarded. On the other hand it's great they do pay people for finding security bugs. I just hope they c…
Keep their attitude toward security flaws and the disclosure today in mind when you consider what would happen if your entire company's private chatlogs suddenly became public. Same goes for Hipchat too. User accounts and passwords are easy to reset and fix. Credit cards are easy to reset and fix. Years of private company discussion showing up in the wild? You're unlikely to ever recover.
I'd be angry but my company wouldn't be ruined. The worst thing I ever say in internal communications is to poke fun at a couple of our grumpier or more entitled users. I also probably curse slightly more than is entirely prudent. But, that'd be mildly amusing to have exposed, not ruinous.
Perhaps if you're saying stuff that you would be "unlikely to ever recover from" if it were shared with people outside of your company, maybe that's not the kind of thing you should be saying.
This is somewhat unrelated, but maybe folks here have some experience with disclosure programs like HackerOne, which is something that I don't have much familiarity with. We'd love to have a way to encourage security researchers to focus on our software and give us reports, but we're Open Source and our budget is miniscule. What is considered "insulting" as a minimum reward? What will actually get professional people…
I'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…
These two issues (the hack and how they treat bug reporters) challenges the way I see slack as a company...
Hi, this is Ryan. I work at Slack.
Bug bounties are great, but managing them can be a challenge. Like many companies that run a popular bounty program, we receive quite a few vague reports, invalid reports, and reports generated by automated scanners. We work through these daily to ensure we are focused on the bugs that can have an adverse impact on our users.
We have positive interactions with the people who report bugs, and we appreciate the hard work involved in uncovering issues. If you find a bug, report it via HackerOne and we will reward your work. We have rewarded researchers for over 300 bugs found so far!
Anshuman sent us the first report in December. At a glance his report appeared to be well written and detailed. When triaging bugs, those two things are especially helpful. (We appreciate well written POCs!) We reproduce every report received, so below I will convert his report into a description of the problem and a series of steps needed to reproduce it (original report quoted).
------------
From the report:
“Slack users are allowed to share files (posts, snippets) with other users and within channels.”
True
“When a file is shared in a channel and unshared again, it is clearly mentioned on the website that: Un-sharing the file will not remove existing share and comment messages, but it will keep any future comments from appearing in the channel.”
True. This is what the un-sharing feature does. As stated above, files.unshare is in no way an access control feature.
“This makes it obvious that on sharing and then unsharing a file within a channel, it will still remain shared and can be viewed by others on that channel. This is the way it is supposed to be.”
True. Again, this API call is used to stop new comments about a file from appearing in a channel, not to remove the file from a channel. (Deleting is done by the files.delete method) So far no bug, just things working as expected.
“Now, when a file is shared with a Slack user, currently, there is no way to unshare it again from the UI.”
True.
“But, this can be easily done by sending a request to the .slack.com/api/files.unshare" rel="nofollow">https://.slack.com/api/files.unshare end point instead of the .slack.com/api/files.share" rel="nofollow">https://.slack.com/api/files.share end point.”
The reporter is proposing that the victim call files.unshare to utilize a “hidden feature”. The reason a user might do this is left to the imagination.
“It is as simple as that.”
There is no instance of files.unshare being called this way in the UI, because that is not what it does. Calling an API method that is not documented is never guaranteed to do what you assume it does.
------------
What Anshuman has created is a scenario where the “victim” must:
1) Use Slack via the Web, Mobile or Desktop Application. 2) Share a file with another user 3) Observe API calls (or read the javascript). 4) Make an assumption about what api/files.unshare is used for. 5) Call that API method directly. (curl, js, whatever..). 6) Expect that the method does what you have guessed. (it doesn’t, because the reporter's guess was incorrect.)
------------
Testing this report involved working with multiple developers to review the nature of files.share and what the impact of this bug would be. At the end of our investigation we replied to the reporter saying that we appreciate his effort, but this is not a vulnerability, because files.unshare is never used in this way. Unfortunately, we then received this message from Anshuman:
“I am giving you a heads up that I will be blogging about this sometime today. Thanks for your time.”
So after hours spent reproducing this and then explaining to Anshuman why it isn't a vulnerability, his reaction was to create a blog post titled “Hidden Feature in Slack leads to Unauthorized Information Leakage of Files”.
I believe that HackerOne is a valuable platform, and outside of this instance our experience has been extremely positive. We will continue to use it and look forward to working with new people.
Btw, I’m not off the hook, because I did something wrong too. I failed to keep Anshuman updated on a second report he filed in December. I absolutely agree that bug bounty participants should receive timely replies to their queries. This oversight is regrettable and this mistake will not be made again. My apologies to Anshuman for not keeping him updated on the status of the bug, which would have allowed proper coordination and disclosure.
Good Hunting,
Ryan