While I'm unable to comment on the content of the article, I really have to applaud HostGator's error page marketing strategy here.<p><i>We've met with a horrible fate</i> (status code 500) <i>while generating what appears to be a static page. This site is hosted by HostGator! Get yours now!</i>
My response to all the people who says it is nothing just the team names<p>Check this screenshot of google teams <a href="http://m.imgur.com/a/eWLEf" rel="nofollow">http://m.imgur.com/a/eWLEf</a>. There is a team name called viber and google doesn't own viber.<p>Check this news that came 2 days back:<a href="http://www.jbgnews.com/2014/10/google-looking-to-rival-whatsapp-viber-with-their-own-mobile-chat-software/222512.html" rel="nofollow">http://www.jbgnews.com/2014/10/google-looking-to-rival-whats...</a><p>Connect the dots. You can infer a lot.
It is information disclosure at the finest.<p>Smart thing is to accept it is a problem and address it. Defending to say it is nothing doesn't make the problem go away. The fault is on both slack and the companies who are using it.
This is something that could definitely have been reported to Slack before disclosing it publicly. Maybe he did that, but it's not mentioned in the blog post so I assume he didn't.<p>It's just a nice thing to do and they might reward you for it. You can still post it on your blog after they released a fix.
Sorry that the site was down for long. The site was on poorman's hosting (hostgator) that could not take HN traffic and bogged down.<p>Cloudflare, along with flatfile caching by Drupal's Boost module came to the rescue. Hope that stays alive for a while now.<p>Regarding not having disclosed this one discretely to Slack:<p>* I have considerable experience in a couple opensource projects including Drupal and have reported multiple vulnerabilities on various occasions for various modules discretely (though mostly of lesser significance and a very narrow/rare attack vector) to the right teams through various channels meant for this purpose. As such I am aware of the SOPs for the righteous to follow in case of discovering a vulnerability.<p>* I don't think this one is a security issue that would take a professional security expert to crack. Nor could this have been not noticed when Slack tested their product. This is an issue with 'common sense'. I am pretty sure that Slack designed it this way. It is just the customers that are surprised now. Not Slack.<p>Also, it looks like this was reported earlier to Slack by <a href="https://twitter.com/rootlabs/status/499723782244675584" rel="nofollow">https://twitter.com/rootlabs/status/499723782244675584</a> a couple of months ago and it was rejected by Slack as "Not a bug". However I do acknowledge that I was not aware of this report when I first published the post and hence can not say that I disclosed it only after being rejected by Slack. I would say it was not a security vulnerability to report but just bad design that Slack had put in being totally aware of what it means.
The site seems to be down at the moment.<p>Here is a cached version [1]<p>The gist of it: the slack mac client seems to ask you for your groups before properly authenticating you - hence if you put in the email address of a competitor (or famous person), you can see which groups they belong to, which might be valuable information.<p>(haven't tried it myself, just summarising the post)<p>[1] <a href="http://cc.bingj.com/cache.aspx?q=http%3a%2f%2fwww.tanay.co.in%2fblog%2fwanna-know-what-product-your-competitor-working-try-slack.html&d=209021454366&mkt=fr-FR&setlang=en-US&w=jBvUCoMsbckf6gBacpPmVHzRptKPbtw4" rel="nofollow">http://cc.bingj.com/cache.aspx?q=http%3a%2f%2fwww.tanay.co.i...</a>
<a href="http://webcache.googleusercontent.com/search?q=cache:7u-bEJPVOAkJ:www.tanay.co.in/blog/wanna-know-what-product-your-competitor-working-try-slack.html+&cd=1&hl=en&ct=clnk&gl=uk" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:7u-bEJP...</a><p>cache version as link broken.
I just realized that any facebook user can signup on <a href="https://facebook.slack.com/" rel="nofollow">https://facebook.slack.com/</a> with his fb username.
This is ugly, and probably much more of a disclosure than most of these companies were expecting.<p>That being said, everyone railing about "unreleased product names" seem to have forgotten this is exactly the purpose of code names: they're pretty much expected to be leaked at some point, but it's okay since the stakes are intentionally low. Use code names!
Seriously, just the idea of keeping ALL your company internal conversations on a 3rd party server is quite crazy, but to get access without even hacking anything.. I wonder if situations like this will result in business customers more carefully evaluating SaaS solutions that deal with sensitive data, because "in-house" solutions may be old school, but at least a) no one will suddenly terminate the service and b) all data is kept locally.
You don't have to use the mac client: <a href="https://slack.com/signin" rel="nofollow">https://slack.com/signin</a> and test@microsoft.com yields the same result.
Here are the ones for:<p>- amazon
- ebay
- facebook
- apple
- google<p><a href="http://imgur.com/a/eWLEf" rel="nofollow">http://imgur.com/a/eWLEf</a>
I haven't tried the hack, but it's something that had occurred to me for a while. We're using Slack internally and I've been wanting to get everyone in our larger organization to use it. Anyone with an email using our domain would be able to join. Which is ok with me. The only real flaw here is showing which groups are available (many of which can be client names or project names or product names that have yet to be launched). This is a serious lapse on their part
This seems like one of those things that was intentionally a 'feature' and not an oversight. The oversight was probably not making it clear to users that the team names were effectively public.<p>I think the "this is why not startups|cloud" posts are a bit heavy handed given the actual details of what we're talking about here.
Sometimes the site isn't available, so voila:<p><a href="http://webcache.googleusercontent.com/search?q=cache%3Awww.tanay.co.in%2Fblog%2Fwanna-know-what-product-your-competitor-working-try-slack.html&oq=cache%3Awww.tanay.co.in%2Fblog%2Fwanna-know-what-product-your-competitor-working-try-slack.html&aqs=chrome..69i57j69i58.1317j0j4&sourceid=chrome&es_sm=91&ie=UTF-8" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache%3Awww.t...</a>
Fun to scan down this list: <a href="http://www.siliconvalley.com/SV150/ci_25548370/" rel="nofollow">http://www.siliconvalley.com/SV150/ci_25548370/</a>
Naturally the biggest companies have the most teams.
It's not just the mac app, even the website signin[1] is affected. Also any email address works, it apparently just checks the domain.<p>[1] <a href="https://slack.com/signin" rel="nofollow">https://slack.com/signin</a>
Even if they fixed this flaw, you could still reverse this technique by using a dictionary attack against {{ name }}.slack.com (e.g. eng.slack.com), and parse out the given domain name.
As previously stated, this isn't listing the rooms or groups inside a slack account, it's listing the slack accounts that you might potentially be trying to login to.<p>IMO, this seems like more a security issue of the individual creating slack accounts for, a) naming the accounts for a specific (potentially revealing) sub-set of their company, and b) turning on the feature that allows anyone to create an account if their e-mail matches the domain.<p>The company I work for uses Slack but has this second feature turned disabled and our company is not listed when you try and sign in with a bogus e-mail account.
Its difficult to balance ease of use with vulnerabilities like this one. Our product Sococo requires a moderator to enter email addresses of invitees to a group. This is more secure, but slows down our adoption rate. We've resorted to a more direct marketing approach to overcome this, but in the end our clients are more secure.
I can see that both Microsoft and Google have tried Slack at least. This doesn't mean they are still using it (vice versa).<p>Since Skype is not really light-weight anymore and Google chat did not really take off, It looks like that Slack found himself a good spot in between.
We use Slack and I always thought this was an odd behavior. We're a part of a major university so our domain is quite large and we can see dozens of other departments and projects using Slack just by putting in our email.
Slack has a setting that allows anyone with an email address in your domain name to join without being invited. I imagine if you turn that setting off, this problem goes away.
Slack is on HackerOne, better report to them next time :)<p><a href="https://hackerone.com/slack" rel="nofollow">https://hackerone.com/slack</a>
Therefore I prefer using encrypted platforms like <a href="https://telegram.org/" rel="nofollow">https://telegram.org/</a> or <a href="https://stackfield.com" rel="nofollow">https://stackfield.com</a> - they really take care of privacy and data protection.
While I understand how disclosing group names of customers is a bad idea, everyone here jumping on how serious of a security vulnerability this is is missing the fact that it is a feature, not a bug. It's not disclosing anything that was ever intended by the Slack UX designers to be undisclosed, they clearly thought about it and decided to make this tradeoff. This is arguably bad judgement, but it's far from the gross incompetence and negligence that most comments here seem to be frothing at the mouth to proclaim. These are <i>group names</i>, not any internal communication or private data. In a world of Shellshocks and 8-figure credit card thefts direct from PoS systems, there is simply no way this qualifies as a "serious security vulnerability".