
A little note about Slack’s Bug Bounty program - wwarneck
https://abhartiya.wordpress.com/2015/03/16/a-little-note-about-slacks-bug-bounty-program/
======
zaroth
I 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.

~~~
anshuman_bh
I was banned from reporting any bugs to the Slack Bug Bounty program on the
HackerOne platform after reporting the 3rd bug. What's worse is that I wasn't
even notified of this? Even HackerOne didn't think it was necessary to do
that.

~~~
Retr0spectrum
I guess that means that you will be forced to publicly disclose any more
vulnerabilities that you find... /s

~~~
StavrosK
Why the sarcasm? That's exactly what this means.

------
jorge_leria
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 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.

~~~
womitt
Not a surprise they got hacked...

These two issues (the hack and how they treat bug reporters) challenges the
way I see slack as a company...

------
smt88
Combined 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.

~~~
ethanbond
I _accidentally_ signed into another organization's channels on Slack. Had to
delete and re-make an account to get into my organization's channels.
Apparently there were already concerns about Slack not taking security
seriously, so it wasn't really all that shocking to me. Currently not using
Slack, obviously.

Sorry other organization – I hope you guys move off some time soon.

------
meritt
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.

~~~
SwellJoe
_" 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.

~~~
meritt
I'm not saying nor worried about statements which are hateful, sexist, racist,
etc. Like most mature non-brogrammer companies, we don't have those sort of
issues in the first place.

I'd be worried about company strategy, vision, intellectual property,
keys/passwords, system infrastructure or other details leaking which could
hurt our competitive edge, lessen our valuation, or expose our user's PII.

------
jtchang
I'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.

~~~
anshuman_bh
I think HackerOne as a platform failed here as well. I understand they try to
leave themselves out as much as they can and just collect the fees for the
bounties paid. But, in cases like this, I feel they should have been a little
more proactive about it. I received an email from HackerOne shortly after I
wrote this blog saying they will investigate but I haven't heard a word till
now. Soon after that, I found out myself that I have been banned from
reporting any bugs to Slack without any notification. HackerOne could have at
the very least sent me an email out of courtesy but no, never happened. I even
sent them a follow up email asking for clarification but haven't heard a word
till date.

------
earless1
If 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.

------
joshmn
It 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]"

~~~
anshuman_bh
I definitely got a very bad attitude from them. I was really trying to be nice
and report bugs with detailed reports including detailed PoC videos
demonstrating everything. But, it was disappointing to see their responses
honestly.

------
fweespeech
[http://slackhq.com/post/114696167740/march-2015-security-
inc...](http://slackhq.com/post/114696167740/march-2015-security-incident-and-
launch-of-2fa)

[http://valleywag.gawker.com/slack-is-letting-anyone-peek-
at-...](http://valleywag.gawker.com/slack-is-letting-anyone-peek-at-their-
competitors-1643790919)
[https://news.ycombinator.com/item?id=8425799](https://news.ycombinator.com/item?id=8425799)

Tbh, at this point I wouldn't be surprised if these "problems" occurred after
someone discovered the bug and reported it.

------
jamiesonbecker
More (or less?) shocking here is the total lack of an official Slack response
to this thread. Does not bode well..

~~~
bigiain
In case you hadn't seen yet, I suspect everybody at Slack in a position to
comment on the company's behalf in pubilc is probably kinda busy with more
pressing matters right now:

[http://slackhq.com/post/114696167740/march-2015-security-
inc...](http://slackhq.com/post/114696167740/march-2015-security-incident-and-
launch-of-2fa)

(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?)

------
patcon
I've been a big fan of slack since the beginning, but this seems pretty
scathing. The folks at Slack should really address the contents of this post.

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.

------
shasts
Funnily, I was looking at the requirements for a Security Engineer at Slack.
[https://slack.com/jobs/dfd75111/security-
engineer](https://slack.com/jobs/dfd75111/security-engineer) The secure coding
practices or protection against attack part of the job is minimal. Compared
that to Google Information Security Engineer.
[https://www.google.com/about/careers/search#!t=jo&jid=29144&](https://www.google.com/about/careers/search#!t=jo&jid=29144&)
Well, job descriptions in advertisements are not indicating much. But one gets
the reason.

------
homakov
While i agree that reports are high quality and slack should've handled it
better, I don't see any security risks in both reports. They would close it as
N/A one way or another. Just rude response though.

------
SwellJoe
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 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?

~~~
lawnchair_larry
You generally wont get professionals unless they're feeling charitable.
They're busy with paid work and don't need credit. You also won't insult
anybody if you're a non-profit. It's for-profit companies who offer t-shirts
that get criticism.

------
jscheel
I would assume that there wasn't any technical issue such as Slack not
actually getting notifications of his messages. If that's not the case, this
seems like a pretty low way for Slack to have handled the issue.

------
rhuber
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

~~~
raesene9
Good to see a response on this from someone at Slack. However I'm now somewhat
confused.

If you accept that Anshuman should have been updated on the 2nd bug and it was
only after multiple unanswered requests that he blogged about it (a completely
reasonable reaction I'd say), why did you then (I'm guessing you're the same
Rhuber as the one commenting on the 3rd bug) say that he had gone against the
spirit of the site and had him removed from your bug bounty programme?

~~~
rhuber
There are a few reasons for my comment about going against the spirit:

1) [https://hackerone.com/disclosure-
guidelines](https://hackerone.com/disclosure-guidelines) states:

"If 180 days have elapsed with the Response Team being unable or unwilling to
provide a disclosure timeline, the contents of the Bug Report may be publicly
disclosed by the Researcher. We believe transparency is in the public's best
interest in these extreme cases."

2) He set an arbitrary 90 day disclosure checkpoint.

3) We explicitly asked for more time in dealing with the bug.

4) We had an extremely negative experience with him during his first report.
He was unnecessarily adversarial when we patiently explained that he had not
found a vulnerability.

\---------

Within the HackerOne interface, a "Duplicate" is actually listed as a
Closed:Duplicate issue, and doesn't appear in the Open issues tab at all.
Perhaps a method of attaching duplicates to the original and allowing
communication between all involved is useful? ¯\\_(ツ)_/¯

~~~
raesene9
Good point about the Hacker One disclosure timeline, sounds like the reporter
should have waited for that to elapse prior to disclosure.

Not sure I'd say 90 days is entirely arbitrary as some of the big boys (i.e.
Google Zero) seem to have come to a conclusion that that's the appropriate
delay between disclosure and fix (whether that's always reasonable is another
matter).

I'd guess that the more time thing he may have felt didn't apply as he wasn't
getting any more communications about the bug status...

And sounds like a good feature request for Hacker One on dupes, this won't,
I'm sure, be the only instance where this kind of mis-communication happens!

~~~
anshuman_bh
considering the fact that they were unresponsive and dismissive and some
feedback about slacks bug bounty program from other fellow researchers, I
really didn't think 180 days was worth the wait so yeah I chose my own. I am
at the liberty to do that just like how slack has the liberty to ban me from
their program. So yeah your guess is good!

And it's not only me who has had such a terrible experience with their
program. I know atleast 3 different researchers who have reached out to me to
tell me that they have gone through the same experience. They prefer not to
speak out. I did. Period.

------
hobarrera
Given how slack doesn't care at all about security, looks like one more reason
to migrate and contribute to Let's Chat[1].

(Note: I'm not related to letschat or sdelements in any way)

[1]: [https://sdelements.github.io/lets-
chat/](https://sdelements.github.io/lets-chat/)

------
yeukhon
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 can tighten up the code and run more security
checks before deploying to production...

~~~
prettyrandom100
What's your idea of BIG ? This is not at all helpful if you don't state the
amount.

------
pbreit
I'm having a hard time sympathizing with the filer since he seems to envision
a team of people sitting on the other side waiting for him to press submit.

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).

