The End of AWS Keys in Slack Channels

This blog was originally published by DoControl here.

Written by Adam Gavish, DoControl.

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.

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 has been used 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 such as a Secrets Manager. However, the ease of collaborating via SaaS communication tools like Slack and Teams makes this kind of exposure difficult to avoid completely.

Conclusion

The intention of this blog post is to raise awareness of this critical issue that so many organizations face, and explain our approach to preventing these seemingly-insignificant activities that 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 prevent data breaches together by not mixing between the two.