Wanna know what product your competitor is working on? Try Slack | Hacker News Reader

Wanna know what product your competitor is working on? Try Slack

tanay.co.in

273 pointstangoalpha141 comments

While I'm unable to comment on the content of the article, I really have to applaud HostGator's error page marketing strategy here.

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!

If they're generating 500 errors while serving up static sites, someone is doing something very wrong.

Is there a HTTP code for when you've taken the piss with your cheap as dirt shared web host?

402 Payment Required? :P

There will be other layers (routing, caching, WAF, etc) that could generate 500 errors in between you and the software serving the static site.

This page is broken! That doesn't mean yours will be! HostGator.

My response to all the people who says it is nothing just the team names

Check this screenshot of google teams http://m.imgur.com/a/eWLEf. There is a team name called viber and google doesn't own viber.

Check this news that came 2 days back:http://www.jbgnews.com/2014/10/google-looking-to-rival-whats...

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.

How is this the fault of companies using Slack? That's nothing more than victim-blaming.

Victim-blaming? This isn't an assault or a crime, it's a shortcoming of the service. It falls well under the umbrella of "caveat emptor".

Is caveat emptor something they sold the company when trying to land that enterprise contract? Or did they sell them security of their information?

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.

It was reported to them before, they said it's not a bug:

   @rootlabs: Got the expected "not a bug" from @SlackHQ so
   feel free to see names of MSFT, Google chats via login
   info leak. http://t.co/kldKXN7NTf

https://twitter.com/rootlabs/status/499723782244675584

13th August? man, someone messed up.

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.

It's a minor degree of information disclosure -- hardly at it's finest.

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.

Completely untrue about the people at Slack. I disclosed a pretty trivial vulnerability to them and got a $100 reward.

How about next time you stop generalising?

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.

Pretty sure the going rate for a pen-tester is much, much higher than 100 usd an hour - and they would get paid even if they didn't find anything.

Why assume the worst about Slack just because some other companies have handled disclosures badly?

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.

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.

Apparently it was, see: https://twitter.com/rootlabs/status/499723782244675584

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.

Maybe this kind of exposure is the only way we will teach people to stop trusting fly-by-night cloud startups with their confidential data?

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.

So hurting people in order to teach them a lesson about not getting hurt?

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.

How about responsibly disclosing to the victims/users before going public?

I don't see how that would be possible unless Slack has a full list of their customers available somewhere.

Note that elsewhere in this thread you can see that it was reported to Slack, but they responded saying it wasn't a bug.

True, but it still feels like the right thing to do.

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.

Responsible disclosure serves is nothing more than a cover for bad software venders.

You are under absolutely no obligation to do work for free that these companies should have been doing in the first place.

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)

Also, this is a decision Slack admins make: http://imgur.com/FCUE1mY

> I also want to add on that I do not view this as a security issue

This is absolutely a security issue. What companies I do business with is protected under NDA.

Deleted comment

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 site seems to be down at the moment.

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

1) The slack web sign up seems affected too

2) Any email address, valid or not with a valid domain name works

http://webcache.googleusercontent.com/search?q=cache:7u-bEJP...

cache version as link broken.

I just realized that any facebook user can signup on https://facebook.slack.com/ with his fb username.

And this is why you should silo customer domains from internal domains as github did (smartly)!

I am curious. Could you elaborate on this?

Edit: I wonder how Github distinguish their own "internal" email doing.

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.

Github has already faced this issue and homakov[1] pointed that out.

[1] https://news.ycombinator.com/user?id=homakov

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.

In their defence, Slack does have that as a "coming soon" for their enterprise version.

Don't Facebook employees use @fb.com addresses though?

Yes, they do.

Signup confirmation mail doesn't seem to arrive, maybe Facebook was quick to add a filter for mails coming from Slack.

You first have to enable your facebook email address from facebook email settings.

I'm too scared to try it - I have all my photos and stuff like that on my Facebook account. So tempting though!

If you trusted Facebook with that, you aren't scared enough.

You should backup those off facebook. However consider carefully if you wish to keep that backup in the cloud. (and which cloud).

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.

The solution is to use a name that will never get pass legal, like a trademark of another company.

That's what Sun did with Swing, which was originally called Kentucky Fried Chicken[0] internally.

[0] https://blogs.oracle.com/thejavatutorials/entry/why_is_swing...

In this case, it is an internal project so it never would have touched legal.

That's why you give it a nonsense name. Windows XP was codenamed 'Whistler'. Nobody calls it Whistler (except when reminiscing about the warez scene). https://en.wikipedia.org/wiki/List_of_Microsoft_codenames https://en.wikipedia.org/wiki/Code_name

I came very close to including a "Longhorn" example in my original comment.

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.

Except it will forever be called that.

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.

What conversations are being leaked? It's a list of team names.

By using slack or any other external chat system, you're leaking metadata and comms content.

Leaking to where? By using the internet you're leaking [meta]data. It's a question of degrees and trust.

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.

https://sandstorm.io/ seems to aim for the best of both worlds - web apps trivially easy to deploy locally.

Productivity trumps those concerns.

for startups yes. For big companies, in my experience, no.

You don't have to use the mac client: https://slack.com/signin and test@microsoft.com yields the same result.

Here are the ones for:

- amazon - ebay - facebook - apple - google

http://imgur.com/a/eWLEf

Nice XSS try on the 3rd image.

Bad thing is that every facebook user has email id `fbusername@facebook.com`. So you can easily get into any team you want.

Facebook employees use @fb.com

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

Private channels could help with this. I believe they aren't visible unless you're explicitly invited.

This doesn't list channels at all, private or public, it only lists teams.

This issue actually seems to be even worse: You don't need a valid email alias to get a list of all teams. Just the domain name.

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.

Sometimes the site isn't available, so voila:

http://webcache.googleusercontent.com/search?q=cache%3Awww.t...

Fun to scan down this list: http://www.siliconvalley.com/SV150/ci_25548370/ Naturally the biggest companies have the most teams.

I wrote a node script[1] you could use for this.

[1] http://pastebin.com/raw.php?i=NgTeseN1

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.

https://gist.github.com/anonymous/4e34a10f1552dd8ede96

Cool idea to use the alexa top 1m.

Got this error though:

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

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.

[1] https://slack.com/signin

Wow. This is a very serious security flaw. You should never assume that usernames (especially email addresses) are unknown to attackers.

It doesn't even require a valid email address. It's an obvious side-effect of Slack's completely weird account system.

Somebody already posted some screenshots:

http://imgur.com/a/wLShq

It was fun guessing who each company was based on the groups.

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

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.

I reported that issue to Slack 6 months ago. Their response was "This is an intentional part of the product design.".

This is a capitulation - even Google uses Slack instead of Hangouts (although just a few teams); even Microsoft instead of Skype.

Neither Skype nor Hangouts are intended to compete with Slack. They're consumer products, while Slack is intended for business teams.

I'm sure way more businesses use Skype and Hangouts than Slack and HipChat.

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 bots that have to be hosted with someone clicking the buttons in the UI, or that get broken every time Skype updates, no?

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.

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

You're right. So what?

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.

Visa does as well :)

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.

I can see that both Microsoft and Google have tried Slack at least. This doesn't mean they are still using it (vice versa).

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.

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!

Microsoft have a hell of a lot of teams (separate Slack instances). I'd be surprised if none of them are being used.

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.

So this is just IRC with lipstick it didn't need?

Talk about reinventing the wheel.

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.

I suspect channel names would be much more damaging than team names. This isn't really a big deal as long as people know it's out there.

WTF - "that matches your domain". Big ouch.

Slack is on HackerOne, better report to them next time :)

https://hackerone.com/slack

Nice, they eat their own dogfood http://imgur.com/Xs2QRZa

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

Interesting that they have what appears to be 2 XSS tests in there:

  Signup for "><img src=x onerror=prompt(document.domain);>

BatCave is a good team name

In the US that could be probably prosecuted as "hacking a computer system". Very similar to what Aaron Schwartz did.

Wow, certainly a big punch on the company face

Metadata collection at it's finest!

Seriously this is very interesting and could be valuable. Expect that it will get fixed soon though.

random@company.com also works. (╯°□°）╯︵ ┻━┻

Yes, even test@example.com works!

Actually, is Microsoft really using Slack if they have Lync and Skype?

With that many employees, they probably use and experiment with a variety of products

How can someone use this to their advantage?

Depending on the group names, it could reveal product features or business activities these companies expected to remain confidential.

The issue seems to be solved

Do you have any link to an announcement?

try cal.henderson@slack.com

link is dead

I cannot believe the incompetence.

THIS SITE IS TAKEN DOWN..... THE LINK IS NOT PRESENT EVEN IN CACHED SITE..... WONDER WHY...........

Therefore I prefer using encrypted platforms like https://telegram.org/ or https://stackfield.com - they really take care of privacy and data protection.

Encryption avoids a lot of problems, but this has _nothing_ to do with encryption

Encryption has nothing to do with this.

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

Reply on news.ycombinator.com