Grafvision - Fotolia
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.)
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
Dig Deeper on Web authentication and access control
Related Q&A from Matthew Pascucci
Understanding the differences between sandboxes vs. containers for security can help companies determine which best suits their particular use cases. Continue Reading
Troubleshooting VPN session timeout and lockout issues should focus first on isolating where the root of the problem lies -- be it the internet ... Continue Reading
What sets web roles and worker roles apart in Microsoft's Azure Cloud Services? Here's a look at how they are different. Continue Reading