[UPDATE]

An excellent article about the same issue has been posted by Detectify a few day after this one.

Unfortunately Detectify was not aware of our post

and had worked independently on this problem. Well they digged deeper and warned big webistes (Ars Technica, The Register, Observer, etc.) so the media impact has been very HUGE !

So huge that Slack listened to them and finally started to move by revoking public tokens. Very good but that’s not enough !

What about the tokens that Slack won’t / can’t find? Slack job is not to crawl the Internet for these tokens. In fact the answer of Slack is far from complete. Monitoring is cool but the main problems are still there, tokens are in all their web pages and above all this the tokens time to live is incredibly too high: many months ! OWASP says 60 minutes is ok.

[ORIGINAL POST]

We can read on Slack website:

We take security seriously here at Slack. And for good reason: every person and team using our service expects their data to be secure and confidential.

But…

A few months ago we found three tied vulnerabilities that could lead to session usurpation.

As they were offering a bug bounty through HackerOne we reported them, unfortunately they refused to correct these issues as they prefer to:

"_keep the functionality here as it is"_.

So even if we don’t understand why Slack don’t care of these issues we think Slack users should be warned.

1. API token written in web pages

After a successful authentication a session cookie is delivered by Slack to the client:

Set-Cookie: a-12036508307=kU8LEyIkF6GnQ7uDa5pwyQo1f7G%2B3JPzZCTI1C3vlZtfmTOL0oBrHhHPDUKWzgglM0v2xHO8Md7zPcfrkKbFvw%3D%3D; expires=Tue, 21-Oct-2025 16:07:02 GMT;

Another token, used to call the API is delivered too, directly in javascript in the pages sent by Slack:

// common boot_data
var boot_data = {
(...)
api_token: 'xoxs-6539866065-12036508317-12952420882-c33e84f243',
(...)
};

This token is used when accessing some functions, for example when Slack list the users of a team:

POST /api/users.list HTTP/1.1
Host: www.slack.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 56
X-ClickOnceSupport: ( .NET CLR 3.5.30729; .NET4.0E)
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

token=xoxs-6539866065-12036508317-12952420882-c33e84f243

2. Concurrent sessions allowed

By getting a valid token you access the team to which it was delivered, even with another device and/or another IP.

3. Session Timeout far too long

The validity of these API tokens is far too long, probably many months !

Consequently, if you find one of them (using logs, saved web pages or by any other means) you can hijack a user session and act in his place on his team.

By searching google, or even better: github, for:

"api_token: 'xoxs-"

you can find a few results:

If the user to whom the token was delivered is an active Slack user, it is possible that the validity of his token has been constantly updated and that it is still valid today.

In order to test the validity of these tokens after a relatively long “idle” period of time, we requested a few, keep them aside and didn’t use them.  After 2 months (well, exactly 59 days) we decided to use them and the tokens where still “up and going” even though they had  been idle during all that time !

Usually session cookies/tokens’ validity should expire after such a long period of time.

OWASP recommends to set the session timeout between 15 to 60 minutes:

"All applications should implement an idle or inactivity timeout for sessions. This timeout defines the amount of time a session will remain active in case there is no activity by the user, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID. The most appropriate timeout should be a balance between security (shorter timeout) and usability (longer timeout) and heavily depends on the sensitivity level of the data handled by the application. For example, a 60 minute log out time for a public forum can be acceptable, but such a long time would be too much in a home banking application (where a maximum timeout of 15 minutes is recommended). In any case, any application that does not enforce a timeout-based log out should be considered not secure, unless such behavior is required by a specific functional requirement."

Slack can optimize its session management security by:

• lowering session timeout to 60 minutes or less
• refusing concurrent sessions (one token/cookie per device)
• refraining from using API-tokens  in web pages

But, as they don’t want to fix that, take care of your tokens if you’re a Slack user !