Cloud-based messaging service Slack has fixed a flaw that could have allowed a hacker to steal a user's private token.
In a blog post, Frans Rosén, a knowledge advisor at the Swedish web security firm Detectify, showed how he was able to create a malicious page that would reconnect a victim's Slack WebSocket to a hacker's own WebSocket to steal the victim's private Slack token.
The vulnerability was discovered last Friday and fixed by Slack five hours later.
The flaw was found after the researcher realised that he could manipulate code functions on Slack to control browser notifications or switch to another chat. He said that "none of the events was punchy enough".
The problem arose in how the service was failing to validate properties such as evt.origin or evt.source.
“These two are read-only properties that cannot be spoofed. Not validating them was a clear indication to me that I could start do fun stuff, like accessing the functions using postMessage to this window from another window I controlled,” he said.
He then could create a proof-of-concept exploit that could steal tokens. When a victim visits a malicious page, this starts a Slack call and starts a new WebSocket connection, which he interrupts and points to a malicious server.
With the token obtained, Rosen said he could log into different Slack accounts and fool it into thinking he was an authorised user.
Rosen earned $3,000 from the company's bug bounty programme by reporting the bug. Slack confirmed it had “resolved the postMessage and call-popup redirect issues, and performed a thorough investigation to confirm that this had never been exploited”.
Peter Kosinar, research fellow at ESET, told SC Media UK that the flaw 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,” he said.
“For web-based messaging applications, isolation using a separate browser should defeat most attacks of this kind,” he said.
“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,” added Kosinar.
Paul Ducklin, senior technologist at Sophos, told SC that while the flaw isn't quite the same thing as SQL injection, it does shares one aspect with a typical SQL injection: the code processing the malicious request didn't check the incoming request carefully enough.
“Sadly, input validation is boring to code and complex to test – and therefore it often gets forgotten,” he said.
"Generally speaking, testing that your software succeeds correctly is easier than testing that it fails correctly," he said.
"For example, testing that you can login with the right password is easy, but testing that you can never login with the wrong password is a much harder proposition: there's one correct password to try, but an essentially infinite number of invalid passwords."