Slack Security IncidentJeff Atwood September 6, 2019
From mid 2014 to January 2018, Discourse used Slack as an internal chat tool.
In February 2015, Slack had a security incident, and notified any accounts of “suspicious activity”:
As part of our investigation we detected suspicious activity affecting a very small number of Slack accounts. We have notified the individual users and team owners who we believe were impacted and are sharing details with their security teams. Unless you have been contacted by us directly about a password reset or been advised of suspicious activity in your team’s account, all the information you need is in this blog post.
We were not notified of any suspicious activity for any of our Slack accounts at that time. In July 2019, Slack posted an update and revealed important new information:
In 2015, unauthorized individuals gained access to some Slack infrastructure, including a database that stored user profile information including usernames and irreversibly encrypted, or “hashed,” passwords. The attackers also inserted code that allowed them to capture plaintext passwords as they were entered by users at the time.
We were recently contacted through our bug bounty program with information about potentially compromised Slack credentials. These types of reports are fairly routine and usually the result of malware or password re-use between services, which we believed to be the case here.
We immediately confirmed that a portion of the email addresses and password combinations were valid, reset those passwords, and explained our actions to the affected users. However, as more information became available and our investigation continued, we determined that the majority of compromised credentials were from accounts that logged in to Slack during the 2015 security incident.
Our Slack workspace was permanently deleted in January 2018, and as of that date we no longer use Slack in any capacity whatsoever. We were not notified by Slack of any potential compromises of our old Slack Workspace.
About 3 days ago, we were contacted by an individual who provided excerpts from Slack chat logs from a specific non-management Discourse team member that span dates from July 2015 to March 2017.
Please note that access to Slack, by itself, confers absolutely no access to Discourse systems. We’ve closely analyzed the old Slack chat logs provided by this individual, and any credentials listed in those chat logs.
We only identified one set of credentials in the Slack chat log that was still valid — a Digital Ocean droplet that we used for external HTTP ping monitoring, but was no longer in active use. This droplet had no internal access to Discourse systems. We destroyed the old droplet and rebuilt it.
Based on our analysis of the Slack logs provided by this individual, we believe the risk to our hosting customers is low, and there is no risk to the Discourse public codebase.
However, out of an abundance of caution:
- We directly and privately contacted all our enterprise hosted clients within 24 hours of discovery, and provided them a draft of this blog post.
We ensured that all internal Discourse credentials, of any type, have been cycled since January 2018.
On our hosting, we are now deleting Discourse API keys that have not been used in 4 weeks.
We are also moving up two security related features that are now planned for the current beta release, Discourse 2.4:
- Any unused API keys will always be deleted after 6 months of non-use.
We will automatically send reminders to admins when sensitive secrets in your Discourse instance have not been rotated for 2 years.
Feel free to contact us at email@example.com if you have followup questions.
We apologize for this incident, and we will certainly use this as a lesson in how to further improve our security hygiene.