Abusing Slack for Offensive Operations

Malware News
1

1024×411 50.9 KB

Background

With more than 10 million daily active users, Slack is one of the most widely adopted chat platforms in the industry. Throughout our operations, we’ve seen a large variety of organizations use it for several business critical functions such as:

  • Build alerting for CI/CD Pipelines
  • Changes to production code bases via Github
  • Password Reset requests to IT
  • Hunt/IR channels collaborating on active investigations
  • All-hands announcements
  • Project-specific collaboration
  • Helpdesk Troubleshooting

Slack also provides some security enhancements over the older-school style chat programs like IRC by providing integration into Active Directory Federated Services (ADFS), Multi-Factor Authentication (MFA), and logging. Despite Slack not having an on-premise solution, it’s widely accepted for many business use-cases. All of this together makes it a very enticing target for attackers as a real-time awareness mechanism over more traditional methods such as email collection.

When the Slack client is installed on a computer (macOS or Windows), it’s installed as a user level application. Slack stores all of its information inside its own application directories located at the following locations:

  • On Windows hosts, this data is stored in the user’s AppData folder: %AppData%\Roaming\Slack
  • On macOS hosts, this data is stored in the user’s Application Support folder: ~/Library/Application Support/Slack/

All of the data is readable by the user that installed the Slack client and by the SYSTEM or root context. To prevent requiring the user to repeatedly sign into each Slack workspace, Slack leverages Cookies in a sqlite database. Because a single user can be signed into multiple Slack workspaces in a single Slack client, all of this information is stored in the same area.

Offensive Guidance

n0pe_sled, Lee Christensen, and I have leveraged Slack on a bunch of engagements now, so we wanted to share how this works. From an offensive perspective, we want to do a few things in ascending order of desirability:

  • List out all of the Slack workspaces a user has registered in their Slack client (i.e. see which Slacks a user has viewable on the left-hand side of their application)
  • List out all of the files a user has downloaded through Slack
  • Log in as the user (if they know the user’s password for that specific workspace)
  • Log into a workspace as the user if they don’t know the password
  • Log into a workspace as the user if they don’t know the password and the user has MFA enabled

All of the following assumes you have access to a user’s computer in at least a medium integrity context or you have remote access to the file system so you can access the Slack folder. From here, a few specific files will help achieve most of these objectives.

To list out the workspaces a user has registered in their Slack client:

Slack/storage/slack-workspaces or Slack/storage/slack-teams

  • This file contains a JSON dictionary of information about each team such as Team ID, username, user_id, team_name, team_url, and theme information

To list out all the files a user has downloaded through Slack:

Slack/storage/slack-downloads

  • This file contains a JSON dictionary of information about each download such as team_id, file_id, url of file downloaded (with original file name), downloadState, local download path, and when the download started/finished.

To log in as the user if you know the user’s password (and no MFA):

  • You can use the information from Slack/storage/slack-teams to get the team url and username for the specific Slack workspace, then use your password to log in via the web interface or from a new Slack client

This does cause a new login event though which can potentially trigger email notifications and logging warnings.

To log in without knowing the password

All of the others are achieved at once through a combination of a few files and the lightest amount of work. Download the following two files (about 40KB in size):

  • Slack/storage/slack-workspaces
  • Slack/Cookies

Cookies is a sqlite database the Slack client uses to authenticate back to the Slack domain. These cookies don’t typically expire.

When programs need to store sensitive data on the file system, they can use built-in mechanisms to protect these files. In Windows, this is typically done with DPAPI. The nice thing about DPAPI on windows is that even if you can remotely access the files (such as mounting a share with another user’s credentials), you still typically need to be in the user’s context to decrypt the contents of the files. In macOS, this is typically done by storing credentials in the Keychain. The nice thing about storing credential material (like application specific keys) in the Keychain is that the attacker needs to know the user’s plaintext password or get the user to type in their password to successfully pull the key.

Chrome is a good example of this style of protection since it follows both of these processes. At least in macOS, this means that an attacker doesn’t just need access as the user account, but also needs to know the user’s plaintext password to decrypt the login Keychain to access the appropriate key. However, Slack stores all of this information in unencrypted files on disk, so all an attacker needs is read access to the two files mentioned above. This means that these files can be retrieved remotely as well and still leveraged for this technique.

Once you have both files, simply follow the next steps to impersonate their session:

  1. Install a new instance of slack (but don’t sign in to anything)
  2. Close Slack and replace the automatically created Slack/storage/slack-workspaces and Slack/Cookies files with the two you downloaded from the victim
  3. Start Slack

You will now be automatically logged into all of the Slack teams that have valid Cookies (even if they have MFA set up on the accounts). You won’t kick the user out of their current Slack instance, and you won’t trigger a new “logon” email or notification because the Cookies your malicious Slack instance uses are already validated. Below is an example walking through step-by-step to steal “Secret Alice”’s slack information, read her messages, and even post as her into the general channel.

<a href=“https://medium.com/media/5aca0a373fea38580728e2c01b3df297/href”>https://medium.com/media/5aca0a373fea38580728e2c01b3df297/href&lt;/a&gt;

It’s important to remember that you are acting as this user in their Slack, so in order to remain stealthy you should try to avoid clicking their unread messages. Similarly, if you’re searching within their Slack for keywords related to your operations, they can see those searches as well, so be sure to clear them out as soon as you’re done with your search.

Disclosure

We reached out to Slack about this issue and requested that they at least leverage the built in OS level functionality to encrypt or protect the information in any way, but we got the following response:

After some discussion with our internal teams, we have ultimately chosen not to make a change here at this time. While we agree that encrypting these stored files is a good suggestion, an attacker would still likely need direct access to their victim’s computer in order to exploit them. Additionally, even without access to these files, there are quite a lot of attacks available to an attacker, should they manage to access an installed Slack instance on a victim’s computer. We appreciate the suggestion, and may look into implementing this in the future, but for the reasons mentioned, we will be closing this report as “Informative”, for now.

Hopefully this will be addressed in the future, but at the moment, even with the latest install of Slack, this is possible. While not groundbreaking, it’s important to know that this can bypass MFA and as far as we can tell, these Cookies never expire or rotate.

Defensive Considerations

There are a few different potential solutions for defenders when trying to prevent or detect this offensive usage.

Slack Logging

Slack does provide some insight into logins if you have Standard, Plus, or Enterprise Grid plans for the Owner or Admins to check on their members. If an individual user is worried, they can check their own access logs for any tier level (even free) and download them.

1024×316 49.9 KB
Slack personal access logs

In Windows, system access control lists (SACLs) can be applied to the files mentioned in this post to generate events when processes other than Slack access the files.

Active Directory Integration

We’ve only seen one instance where this technique was completely stopped — ADFS integration with Single-Sign-On (SSO). We were unable to fully track down if it was strictly ADFS with SSO or if there was another mechanism used in conjunction. However, when we encountered this situation, the Slack workspace in question required us to re-authenticate before logging in.

Reporting Timeline

As committed as SpecterOps is to transparency, we acknowledge the speed at which attackers adopt new offensive techniques once they are made public. This is why prior to publication of a new bug or offensive technique, we regularly inform the respective vendor of the issue, supply ample time to mitigate the issue, and notify select, trusted vendors in order to ensure that detections can be delivered to their customers as quickly as possible.

  • July 9th, 2019: Vulnerability reported to Slack via HackerOne
  • July 10th, 2019: Slack requested more information about the context around the vulnerability
  • July 12th, 2019: Slack looking into report
  • July 22nd, 2019: Slack closed the issue as “Informative”

Abusing Slack for Offensive Operations was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

Article Link: Abusing Slack for Offensive Operations | by Cody Thomas | Posts By SpecterOps Team Members