An update to a security incident involving the popular team collaboration tool Slack – posted on Thursday – highlights several risks inherent to running the software.
For one thing, no infrastructure is bullet-proof and can be compromised through hacker attacks. These can result in breached databases and stolen user data, including, as in Slack’s incident that originated in 2015, usernames and passwords.
But the nature of the software tool itself, deployed nowadays in many enterprise settings, also highlights the pitfalls of putting all your eggs in one basket when it comes to often sensitive and confidential internal communications.
The wealth and nature of information exchanged on Slack by millions of users inside companies is extensive, thanks to the tool being used as a replacement for email, instant and direct messaging, and file sharing.
However, with great functionality comes the potential for great damage.
This should give pause to companies using Slack, making them aware of the risks and driving them to put rules in place around how the tool is used – but this doesn’t currently seem to be the case.
Lucky escape
The CEO of Keybase, a public directory used for cryptographically verifying identity across accounts, was one of those informed by Slack today about their update to the 2015 attack.
However, the first time Max Krohn realized the Keybase Slack account may be compromised was in January, when he received a notification about a potentially suspicious sign-in to the account.
Krohn, who is US-based, was notified that he had signed in from the Netherlands – which quickly dispelled any doubt about the nature of the sign-in.
Slack’s security team wasn’t overly helpful – they never pointed him in the direction of the 2015 attack that turned out to be directly related to the incident. And Slack also suggested the fault was on his end – despite his meticulous security practices.
This communication left Krohn uncertain if hackers had gained root access to his computers. And so the only solution was a dash to replace all the hardware and rotate all of his Keybase devices.
The effort was a costly one in terms of money but also time – with $5,000 spent on buying new computers and 60 extra hours of labor put in.
However, there was one critical component to Keybase’s use of Slack that made the nightmare a whole lot more bearable: the company only used it for notifications in case the service was down.
Krohn writes that the first thing on his mind back in January was precisely along those lines: luckily, no sensitive information had been exchanged on Slack, which could have led to dire consequences for the company, including extortion by those in possession of such data.
As the Keybase CEO put it: “What would have been way worse – immeasurably worse – is if our team had used Slack for anything other than what we did use it for, which was discussing outages of our own product. Had my co-founder and I discussed our company’s cap table, or business partnerships, or compensation agreements, or ongoing legal matters over Slack; or had our team traded API keys, or security-sensitive matters; or had we controlled mission-critical infrastructure via Slack-powered ‘bots’; we’d be sweating bullets to this day that our important company secrets were out in the open, about to resurface at the worst possible time.”
Slack security
In the email sent out on Friday, Slack informed its users, including Krohn, that their accounts may have been compromised in 2015.
The company said that the reason behind this notification, and the resetting of passwords of what they said were one percent of users, was the recent surfacing of compromised emails and password combinations used in Slack accounts.
However, in his blog post, Krohn takes issue with the claim that only one percent of accounts had been compromised without taking into account the portion of messages they had access to, and the unknown number of accounts compromised at the time.
Another highlight from the Slack email was that in addition to gaining access to usernames and hashed, i.e. securely encrypted passwords, the attackers also “inserted code that allowed them to capture plaintext passwords as they were entered by users at the time.”
Krohn writes that this scenario invalidates Slack’s claim that using two-factor authentication or any web-based solution would give customers more security.
Beyond compromised accounts
Slack has grown to into a veritable behemoth among collaboration software tools, both in terms of the number of users – and the number of features and functionality it offers.
And it is catering to enterprise customers, all the way to choosing not to implement end-to-end encryption because big businesses prefer convenience.
But poor user management practices coupled with the exchange of sensitive data constitutes a security crisis in the making – unless companies start creating and enforcing policies around what kind of information should be allowed on Slack, and do it quickly.
