Slack (and Microsoft Teams) revolutionized the way organizations collaborate efficiently, especially in the work-from-home era. At the same time, its adoption enables technical personas such as software engineers and IT and DevOps personnel to share AWS keys over Slack channels with little or no governance. This blog describes the root causes of this issue and demonstrates a fully automated and “on-demand” solution.
Slack allows users to create channels and set their visibility to either private (invite-only members) or public (anyone in the Slack workspace can join at any time, excluding guests). The Slack channel creation wizard sets the channel to public by default unless the user specifies otherwise.
From Slack’s official documentation:
“Public channels promote transparency and inclusivity. Any member of your workspace (but not guests) can view and join a public channel, giving everyone access to the same shared information. Messages or files posted in a public channel can be searched by other members of your workspace.”
“Private channels are for conversations that should not be open to all members. People must be added to a private channel by someone who's already a member of the channel. Messages or files posted in a private channel can only be searched by members of that channel.”
In reality, organizations have hundreds if not thousands of public Slack channels that their workspace members use daily to push the business forward.
Any file uploaded by any user to a public channel is now accessible and searchable by all members of the workspace (excluding guests). If I’m a frustrated employee or an attacker taking over an employee’s Slack account, I can easily scrape sensitive information from the company’s Slack workspace by simply searching for files based on sensitive keywords or PII.
From Slack’s official documentation:
“By default, Slack will retain all messages and files (including audio and video clips) for the lifetime of your workspace. If you’d like, you can adjust your retention settings to automatically delete messages and files after a set amount of time. You can also allow members to edit the message retention settings for individual channels and direct messages (DMs).”
Slack offers minimal granularity around data retention policies:
Enterprise Grid customers can create specific data retention policies for specific channels, but that requires maintaining these configurations on an ongoing basis as new channels are being created all the time.
A broad application of Slack’s data retention settings can harm business enablement in many ways. Some data will be deleted that should be kept indefinitely, such as:
Using only Slack’s native controls, it’s not possible to retain any of this data without also retaining everything else. As a result, any file uploaded to Slack will remain indefinitely by default, thus unnecessarily overexposing sensitive company information to potential threats.
In practice, employees from R&D, IT, and DevOps departments upload AWS keys to public Slack channels. As a result, these issues coalesce into a significant threat model:
In general, the best practice is to store AWS keys in a dedicated and secure environment. Slack or equivalents are not considered to be a secure environment – these tools are meant to drive communication, security is not a primary focus. Consider the downstream impact of exchanging sensitive credentials over Slack – what's the outcome when those credentials become leaked? There are better platforms to store those keys, such as a Secret Manager, where the solutions are designed for sensitive keys storage in terms of security and control.
Once integrated with Slack (any pricing tier is supported), the DoControl platform consolidates all metadata around Slack files (among other objects) and keeps it up to date based on ongoing user interactions (file uploaded, etc). As such, the Assets page clearly exposes all Slack files in a single place enabling quick searching, filtering, exporting, etc.
From there, you can simply take 3 actions:
This will trigger a security workflow deleting all the files and generating logs in DoControl for compliance evidence purposes.
DoControl’s integration with Slack is essentially a Slack Bot in Slack channels so that any user interaction in such channels will generate a webhook event pushed to DoControl by Slack in near real-time.
These webhook events can trigger security workflows within DoControl based on many various Slack event types:
The event we’re interested in is “File shared” which essentially means a user has uploaded a file to a Slack channel.
Once the event trigger is selected, we can then define a condition to narrow down this workflow to be triggered only when users upload .pem files (representing AWS keys):
Then, we can add several workflow steps:
The end result: we’ve created a security workflow that automatically identifies and deletes AWS keys from Slack!
The intention of this blog post is to raise awareness on this critical issue that so many organizations face worldwide, and explain our approach to preventing these types of activities that might seem insignificant, but can cause significant harm to the business. Slack is an outstanding collaboration platform that is here to stay. AWS keys will forever be used to access production. Let’s not mix between the two and prevent data breaches all together.
If you’re interested in seeing this in action, we’re more than happy to demonstrate.
This stat comes from the industry report we published earlier this year: The Immense Risk of Unmanaged SaaS Data Access. It’s a great read. We recommend you check it out.