The end of AWS keys in Slack channels
SaaS Security

The end of AWS keys in Slack channels

It’s time for security teams to enforce stronger controls over the sharing of AWS keys in Slack

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.

What’s the problem?

Slack channels are public by default

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. 

Files in public channels are accessible by all workspace members

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.

Slack’s data retention is forever by default

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:

  • Important files used for internal collaboration
  • General company guidelines that should be public to all members
  • Customer-related information used to drive the business

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. 

Employees upload AWS keys to public Slack channels

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:

  • AWS keys are available to all Slack workspace members (excluding guests)
  • By default, these AWS keys remain available forever 
  • Suspicious employees or attackers taking over employees’ Slack accounts can easily search, download, and use these AWS keys
  • From there, unauthorized individuals can access your AWS production environment

This attack model was involved in a number of high profile data breaches, such as the Twitter breach and more recently with Okta.

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.

How can DoControl help?

On-demand remediation

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:

  1. Search for “.pem” files
  2. Select them all
  3. Click to delete

This will trigger a security workflow deleting all the files and generating logs in DoControl for compliance evidence purposes. 

Automated remediation

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:

  1. Delete the file to remediate the issue automatically
  2. Notify the security team via Slack webhook with fully customizable message
  3. Open an incident on Datadog (or any other SIEM/SOAR via https API call)
  4. Open a ticket on Jira (or any other ITSM via https API call)

The end result: we’ve created a security workflow that automatically identifies and deletes AWS keys from Slack! 

Conclusion 

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.

Related Posts