Security researchers have disclosed a concerning vulnerability in popular chat client Slack that allowed attackers to hijack your account and take control of your entire communication line. The flaw, which was initially spotted and documented by Frans Rosén from cybersecurity firm Detectify, basically allows ill-intended individuals to snatch your Slack token by tricking you into opening a malicious page. IT security experts from AlienVault and ESET commented below.
Chris Doman, Security Engineer at AlienVault:
“The exploit involves postMessage – a useful javascript function to send data between two pages. Slack weren’t verifying that these messages were originating from pages on domains they control. Through a couple of other clever tricks that meant if an attacker crafted a malicious page, and got a victim to visit it whilst in Slack, they could gain access to their Slack account.
There are a number of potential security issues using postMessage that developers need to be aware of – but this isn’t of the same scale as something like SQL injection. SQL injection is a whole class of common security issues that effects many platforms, whereas this type of vulnerability is more limited to funky web-apps. Still, a vulnerability that put the millions of Slack users at risk has to be taken seriously.
Kudos has to go to Slack here – Slack responded to Frans’s report on a Friday evening within 30 minutes, and had a fix out within 5 hours.”
Peter Kosinar, Research Fellow at ESET:
“This has nothing to do with SQL injection; the actual problem is a completely different class of errors. Moreover, SQLi is mostly relevant for server-side, whereas in this case the vulnerable piece was the client — which could have been fooled into talking to an untrusted party.
As described in the blogpost, if the user was connected to Slack and clicked on the malicious link, their Slack token could have been compromised. This might have allowed the attacker to access the Slack account in question.
For web-based messaging applications, isolation using a separate browser should defeat most attacks of this kind. Also, in many cases apps which have separate clients, as opposed to general browser-based ones, might be better protected against this specific class of attacks since the two roles (browsing untrusted content vs. communication with the messaging app) are isolated from each other. Of course, these kind of clients might bring other problems the browser-based ones might not be facing. Also, depending on the messaging application and trust model it uses, the authentication token used for *messaging* might be insufficient for other account-related activities — but verifying whether this is the case is usually beyond (even skilled) users’ knowledge.”
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.