Grafvision - Fotolia

How did a Slack vulnerability expose user authentication tokens?

A Slack vulnerability exposed user authentication tokens and enabled hackers to access private data. Expert Matthew Pascucci explains how and why this hack was successful.

A security researcher found a bug in the popular cloud messaging app Slack that allowed attackers to steal users' authentication tokens and reuse them to gain access to private channels and data. How does this exploit work, and why were these authentication tokens exposed?

Frans Rosen, a security researcher at web security company Detectify, discovered a Slack vulnerability that essentially enabled attackers to gain access to another Slack users' chats, messages, file content and more. The vulnerability would have enabled an attacker to gain complete access to another user's account by accessing a malicious page that would redirect the Slack WebSocket to the malicious site, stealing the user's session token in the process.

Rosen originally found this Slack vulnerability on the browser version of the application. He submitted the bug to Slack, and it was fixed within five hours. Slack's bug bounty program paid him $3,000 for the vulnerability submission.

The major reason this Slack vulnerability could have been successfully exploited was due to the fact that the application wasn't properly checking messages when using cross-origin communication. With this flaw in place, an attacker could create a malicious link that abused this trust, and directed the user to a page of the attacker's choosing. This site would then be configured to steal the authentication token from the user who assumed they were logging into Slack. The proof-of-concept attack also abused the postMessage function and the WebSocket protocol on which the application relies for communication.

Essentially, this Slack vulnerability would have enabled attackers to listen for tokens directed to a web server that the attacker would have configured for this very purpose, and dumped the token that was used to authenticate the application. The attackers would then be able to use these tokens to impersonate the user that clicked the malicious link. The lack of origin validation enabled this redirect and token theft to occur.

It's interesting to note that the encryption of the session didn't do anything to stop this potential attack. Encryption didn't protect this token theft because it was as if the users themselves were logging in successfully. From the application's standpoint, nothing went wrong, and the authentication was performed properly. It was the lack of validation that would have allowed attackers to gain access to this token and pass it off as their own.

It's important to note that Slack acted extremely fast when this flaw was disclosed, and fixed the bug within only a few hours. Slack promotes the security of its offering, since it hosts some sensitive information within the platform, such as the chat logs of projects and companies.

Moving as fast as it did when the bug was submitted continues to build user confidence on the security of Slack's offering. Using a bug bounty alone is a good way to have an application stress tested by the white hat community. Because of this set up, the Slack vulnerability in cross-origin communications was found, fixed and rewarded before attackers could use it for malicious gain.

Ask the expert:
Want to ask Matt Pascucci a question about security? Submit your question now via email. (All questions are anonymous.)

Next Steps

Learn about the evolution of multifactor authentication tokens

Find out how a full access OAuth token was issued to the Pokémon GO app

Read about Microsoft's response to the growth of the Slack application 

This was last published in May 2017

Dig Deeper on Identity and access management