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.
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.
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.
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.
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.
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 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)
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
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.
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.
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!
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')
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.
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.
144 comments
[ 3.6 ms ] story [ 209 ms ] threadIt'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.
I'd like people do be responsible when they discover a serious flaw in my programs, so I'll try to be responsible when discovering one in theirs.
Also Linus basically insults anyone for being alive.
Real people work at Slack, and very few of them were likely responsible for this oversight.
OP could still pat him/herself on the back after disclosing and waiting for a fix.
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.
Note that elsewhere in this thread you can see that it was reported to Slack, but they responded saying it wasn't a bug.
How about next time you stop generalising?
You are under absolutely no obligation to do work for free that these companies should have been doing in the first place.
Here is a cached version [1]
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)
[1] http://cc.bingj.com/cache.aspx?q=http%3a%2f%2fwww.tanay.co.i...
2) Any email address, valid or not with a valid domain name works
http://webcache.googleusercontent.com/search?q=cache%3Awww.t...
I wouldn't want to trust any business use to something that doesn't provide a documented API that I can use from my own code.
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.
- amazon - ebay - facebook - apple - google
http://imgur.com/a/eWLEf
[1] https://news.ycombinator.com/user?id=homakov
Edit: I wonder how Github distinguish their own "internal" email doing.
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.
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.
http://imgur.com/a/wLShq
Made a little script[1] that generates a screenshot and outputs the groups formatted like this:
microsoft.com groups: Yammer, Mihafa, Somex, iOS Team, China South CAM-S, DSE-Ireland, FUSE Labs, GroupMe, MozTeam, OCS Design Studio, OSS Studios, Priya's Team, FAST, Office PM, DMX, UK Apps, Bobbyk test, ExPGTeam, Team Wolf, BD&E, BingTV, OS Services, DMX, Kudu, EE COE, web, UI Team, Office BP, OneNote, VOX, CPG, India LRP, FooBar, Capture, Capptain, RoleClarity, asterix, Dragonslayers, SignalR, Office Mix, patterns & practices, DX, XD, TEDCOM, Exchange Ecosystem, CSI, PowerBI-ng, ODP, Compete, My Life & Work - China, Azure Active Directory, Census, MeetingsHVS, APEXOutlook, [FUN]CTION, Tempe, Arcadia, OEM, SharedPlatDev, #hashtag, Universal Apps, Modern Attachments, DLDW, Windows client, ESocialGP, MEA HQ Windows, Azure CAT PMoR, OneDrive, Azure Compute, QuestPersonalization, The Size 7 Italian Team, MMCOM, DLTC, ATMS, TED Strategic Engagements, Async Media Distribution, MAW team, APLD
[1] http://pastebin.com/raw.php?i=NgTeseN1
[1] http://pastebin.com/raw.php?i=NgTeseN1
https://gist.github.com/anonymous/4e34a10f1552dd8ede96
Got this error though:
phantom stdout: TypeError: 'null' is not an object (evaluating 'element.value = text')
https://hackerone.com/slack
[1] https://slack.com/signin
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!
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.
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.
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.