Connect the dots. You can infer a lot.
It is information disclosure at the finest.
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.
I'm one of the people saying it is just the team names. I'm not doing that to defend Slack - I've always been unhappy with their sign-in process and this is one of the reasons. However, a lot of people are saying that you can list channels, and that's not correct and would be far more concerning.
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.
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.
This is hardly an exploit. Since no authentication is required in order to see the chatroom listings for any domain, we must assume that they meant for their chatroom directory to be public information. This may not be what their customers are expecting, though...
It's not listing chatrooms, it's listing teams. Very different. For example, at the company I work we have two teams on Slack: Engineering and Marketing. Not really a problem if people find out that! The channel listing would potentially be more interesting, and this exploit does not allow you to see that (spoilers: it's "general", "random", and "cats").
It's information disclosure at its finest. Something you _really_ want to avoid in a sensitive environment - which company internal comms certainly is.
The way companies handle security disclosures lately (i.e. laughing it off, or paying $6 reward), it seems like shaming them would work much better. Plus, this is truly a beginner-level failure, the kind you'd get insulted for by Linus.
Well considering other people posted a tweet about someone trying to report it as a vuln on August 13th and getting told it's a feature, I'd say he's not exactly generalizing in this specific instance.
I'm not generalizing, and I don't really care about Slack. I'm just putting forward a hypothesis about what might be going on in a security researcher's brain when they stumble upon a vulnerability.
Slack has a Reporting Security Vulnerabilities page on its site: http://slack.com/whitehat. Seems like something they would have taken seriously if it had been brought to them first.
Shaming Slack is one point. This guy just exposed the confidential information of who knows how many of Slack's customers. In my opinion that's douchery of epic proportions.
This. That was exactly a kind of vulnerability that is meant to be publicly disclosed. Nothing of matter will happen to anyone because of that vulnerability, but people might remember it and next time they'll think twice about how they handle authentication.
This was about the most minor kind of information leak you could imagine. I doubt anybody is going to feel any real 'hurt' from this.
In this case the information seems unlikely to contain anything sensitive pertaining to customers. If it had though then the companies that had negligently put sensitive information on untrusted servers would be held liable and could face significant fines (violating the Data Protection Act 1998 in the UK can lead to fines of up to £500,000 and similar legislation exists in other parts of the EU). That more serious kind of breach is the one we are trying to avoid by advising companies not to use cloud services.
The lesson can be had independently of the intent of douchery. Shit happens, and learning from your mistakes (by admitting them) is a fine way to get better at what you do.
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.
Cloudflare, along with flatfile caching by Drupal's Boost module came to the rescue. Hope that stays alive for a while now.
Regarding not having disclosed this one discretely to Slack:
* 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.
* 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.
Also, it looks like this was reported earlier to Slack by https://twitter.com/rootlabs/status/499723782244675584 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.
I also want to add on that I do not view this as a security issue. There are a myriad of things that should be done:
1) Your company should not be using SaaS services for sensitive projects w/o codenames. (Codename FishSauce = Viber M&A) -- obviously just obscurity, but still solid opsec.
2) I'd love to see your write-up on HipChat uploading all files directly to an S3 bucket accessible to the world.
3) Every user w/ that companies domain sees this each time they sign-in.
4)I just think it's overhyped and not a big deal.
5) It only impacts companies who have multiple slack TEAMS (not the same thing as channels, no channel names are disclosed)
As far as I know, the teams the user has already joined will also show in that listing, not just the ones they are authorized to join. Even with the auto-auth setting turned off, then, anyone can get a listing of the teams to which a known email address already belongs.
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.
(haven't tried it myself, just summarising the post)
Well, this flaw is one example: Slack assumes that someone with an @facebook.com email address must be a Facebook employee. However, Facebook issues @facebook.com email addresses to regular users, too.
Facebook might have a directory of employees, ldap or something.
Too bad slack doesn't support any of this. This is the price they have to pay for reinventing username and password authentication and requiring everyone to register.
It is also bad since employees quit or are fired, and you don't want to have to maintain a directory of employees on every application you use.
Shameless plug, I work for https://auth0.com and we make this easier.
This is ugly, and probably much more of a disclosure than most of these companies were expecting.
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!
Except it will forever be called that. A quick example is where I work we have a 'new product x billing' system and it is still called the 'new' one five years later when it is also the only one.
There is some debate internally over whether 'new' refers to 'new as in old' or 'new' as in the opposite of 'renewal'. No one knows why it is called what it is called.
This reminds me of so many times doing ad-hoc manual ETL with co-workers, e-mailing back and forth files with names like "accounts-final.csv", "accounts-really-final.csv", "accounts-this-is-the-last-one-for-sure.csv", and inevitably descending into obscenity.
Not as long as you replace it with a new name. Your "new" problem doesn't sound like a problem of stickiness, it's a problem of never giving it an actual name in the first place, or when it was rolled out.
Look at the Orbis and Durango for names widely used in when the press was rumor-mongering that went away as soon as the devices were revealed. We've even changed our internal code names on projects without much fanfare, as long as the name change represents a milestone in the project or a difference in audience it's easy to cut over.
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.
It beats me to see so many Microsoft and google teams. Don't they have their own tools to do this securely.
Leaking of business conversations can have serious implications on many areas from financial to legal. If an employee leaves the company how that will be handled.
They are leaking potentially confidential information to a third party company running the service, in this case Slack. For all you know they could be doing stock trades based on all the insider info they can glean from their chat traffic as their business model.
If the communication includes material insider information, like companies/products they are considering buying, and they are flinging it all over the internet so third parties can read and act on it the SEC can charge them.
If you use cloud services for company communication then you at least need to have provably secure encryption so only the people you want to see the conversation can.
Of course this criticism applies to all the suckers who use Google and Microsoft cloud services for their business.
>For all you know they could be doing stock trades based on all the insider info they can glean from their chat traffic as their business model.
From the Slack TOS:
>Your acceptance of this TOS gives us the permission to do so and grants us any such rights necessary to provide the service to you, only for the purpose of providing the service (and for no other purpose).
They _could_ be breaking the TOS (and thus the contract between you and the them), but I doubt it.
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.
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.
Here's a streaming version that runs through the top 1m Alexa sites. It looks like it gets throttled after a while though, but you can fix it with some trial and error by dialing down the concurrency in concurrent-map-stream and by introducing pauses.
phantom stdout: TypeError: 'null' is not an object (evaluating 'element.value = text')
phantomjs://webpage.evaluate():3
phantomjs://webpage.evaluate():4
phantomjs://webpage.evaluate():4
TypeError: 'null' is not an object (evaluating 'element.value = text')
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.
Skype is actually pretty good for teams. I used to work at a company where it was our primary medium of communication, and we were almost forty people. It's extremely easy to create a group chat in Skype and destroy it with IRC OPs like features. It is also tempting to use since Skype provides a way to initiate a voice call right there from the chat. And one can always access the chat history as well. People have also written Skype bots.
Skype is a resource hog - especially on mobile. Plus, no API, no thank you! (Disclaimer: I'm actively using Skype as work, just because everybody's so used to it.)
There are many businesses that still use Excel as their CRM software, even though there are purpose-built apps that work better.
My point is that Slack, Hipchat, and others are specifically targeting businesses. Having an API with integrations to other software (CRMs, issue trackers, PM, etc.) is one huge advantage over Skype, just as an example.
Hangouts and Skype are good for instant connections to somebody for a quick video chat. Slack is for long-length conversations which require a good historical record. They're aiming for different use cases.
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.
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.
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.
My 'Open Source Strategic Engagements' team at MSFT is totally using it. Slack is awesome. It has a good Skype integration, which is how we can call each other. It's the best chatroom solution I've seen in a while. Skype and Lync are trying to do something else and we're very happily using all of them!
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 super dogfood in the sense that it was built and used internally while building another product, and only productized when the original idea failed (like the founder's previous project Flickr).
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 group names, 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".
We've met with a horrible fate (status code 500) while generating what appears to be a static page. This site is hosted by HostGator! Get yours now!