4 ms·

Notes on “a little note”. 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 popu

by rhuber 12y ago

Notes on “a little note”. 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 https://<domain>.slack.com/api/files.unshare https://<domain>.slack.com/api/files.unshare end point instead of the https://<domain>.slack.com/api/files.share https://<domain>.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

Mithaldu 12y ago
Notes on “Notes on “a little note”.” First off, spare us the advertising. Nobody here cares. -- this is not a vulnerability 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 he reported a bug. You think it's not a vulnerability. This means to any reasonable human that you're literally giving him free reign to talk about it in whatever forum he prefers, including his blog, since there is no vulnerability and as such no danger to you or any of your users. Further, if you feel he misrepresented, he let you know he'd blogged so you were in a position to present your disagreeing position there. This leaves us with one question, which you didn't even bother to try and address: Why is his doing that "unfortunately"? Now, you've admitted that all of the blame for the fallout of the second bug report falls in your hands because you failed to communicate in a reasonable timeframe. The HackerOne FAQ does state: "No. It is unacceptable to share the vulnerability with anyone without the explicit consent of the Response Team." However this following sentence from you remains due to the facts of the matter, and your own admission, simply wrong: You have twice gone against the spirit of a bug bounty program by disclosing things without consent. The first disclosure may have been of a bug of some kind, but not of a vulnerability (as determined by yourself) and is as such not covered by the FAQ. In the second case, as per your own admission, you failed to honor the implicit contract of the situation, which unbound him further from the rules. So you'll be hard pressed to argue in any way that your claim of him having gone against the spirit of the bug bounty program twice is correct. This leaves the issue of his banning from your program, which is doubly by your admission, based on wrong claims. -- I will not speculate on your real intentions here, but i will let you know that everything you have done looks like you have ulterior motives. The post you made, while wordy, utterly fails as an excuse or even apology, the last of which you are due for. Now have your upvote so people can see what kind of behavior they can expect from Slack.
- konklone 12y ago
  > I will not speculate on your real intentions here, but i will let you know that everything you have done looks like you have ulterior motives. The post you made, while wordy, utterly fails as an excuse or even apology, the last of which you are due for. This is hyperbole, unnecessarily accusatory, and counterproductive. Nothing above made it look like Ryan/Slack had ulterior motives. You disagree with how they interpreted things.

by rhuber 12y ago

Mithaldu 12y ago

Notes on “Notes on “a little note”.” First off, spare us the advertising. Nobody here cares. -- this is not a vulnerability 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 he reported a bug. You think it's not a vulnerability. This means to any reasonable human that you're literally giving him free reign to talk about it in whatever forum he prefers, including his blog, since there is no vulnerability and as such no danger to you or any of your users. Further, if you feel he misrepresented, he let you know he'd blogged so you were in a position to present your disagreeing position there. This leaves us with one question, which you didn't even bother to try and address: Why is his doing that "unfortunately"? Now, you've admitted that all of the blame for the fallout of the second bug report falls in your hands because you failed to communicate in a reasonable timeframe. The HackerOne FAQ does state: "No. It is unacceptable to share the vulnerability with anyone without the explicit consent of the Response Team." However this following sentence from you remains due to the facts of the matter, and your own admission, simply wrong: You have twice gone against the spirit of a bug bounty program by disclosing things without consent. The first disclosure may have been of a bug of some kind, but not of a vulnerability (as determined by yourself) and is as such not covered by the FAQ. In the second case, as per your own admission, you failed to honor the implicit contract of the situation, which unbound him further from the rules. So you'll be hard pressed to argue in any way that your claim of him having gone against the spirit of the bug bounty program twice is correct. This leaves the issue of his banning from your program, which is doubly by your admission, based on wrong claims. -- I will not speculate on your real intentions here, but i will let you know that everything you have done looks like you have ulterior motives. The post you made, while wordy, utterly fails as an excuse or even apology, the last of which you are due for. Now have your upvote so people can see what kind of behavior they can expect from Slack.

konklone 12y ago
> I will not speculate on your real intentions here, but i will let you know that everything you have done looks like you have ulterior motives. The post you made, while wordy, utterly fails as an excuse or even apology, the last of which you are due for. This is hyperbole, unnecessarily accusatory, and counterproductive. Nothing above made it look like Ryan/Slack had ulterior motives. You disagree with how they interpreted things.