背景

拥有超过1000万的日常活跃用户，Slack 是业界采用最广泛的聊天平台之一。 在我们的安全研究过程中，我们已经看到许多不同的组织使用它来完成一些业务关键功能，例如：

· 为 CI/CD 管道建立警报

· 通过 Github 更改生产代码库

· 密码重置请求到 IT

· 威胁狩猎/IR（应急响应） 频道协作进行积极调查

· 全员通告

· 具体项目的合作

· 求助台故障排除

Slack 还通过集成 Active Directory Federated Services (ADFS)、双重身份验证服务(MFA)和日志，在 IRC 等老式聊天程序上提供了一些安全增强功能。 尽管 Slack 没有一个基于商业的解决方案，但它在许多业务用例中被广泛接受。 所有这一切使得它成为一个非常诱人的攻击目标，相对于电子邮件收集等更传统的方法而言，它是一种实时感知机制。

当 Slack 客户端安装在计算机(macOS 或 Windows)上时，它作为用户级应用程序安装。 Slack 将所有信息存储在它自己的应用程序目录中，位于以下位置：

· 在 Windows 主机上，这些数据存储在用户的 AppData 文件夹中:%AppData%\Roaming\Slack

· 在 macOS 主机上，这些数据存储在用户的 Application Support 文件夹中:~/Library/Application Support/Slack/

安装 Slack 客户端的用户以及 SYSTEM 或 root 上下文都可以读取所有数据。 为了防止要求用户重复登录到每个 Slack 工作区，Slack 利用了 sqlite 数据库中的 Cookies。 因为一个用户可以在一个 Slack 客户端中登录多个 Slack 工作区，所有这些信息都存储在同一个区域中。

攻击性指导

n0pe_sled， Lee Christensen，和我已经在一系列攻击活动中利用了 Slack 的一些特性，所以我们想要分享这是如何工作的。 从攻击性的角度来看，我们希望按照我们所想要实现的目标进行递增顺序来做一些事情：

· 列出用户在 Slack 客户端中注册的所有 Slack 工作区(即查看用户在其应用程序的左侧可查看的 Slack)

· 列出用户通过 Slack 下载的所有文件

· 以用户身份登录(如果他们知道该特定工作区的用户密码)

· 如果用户不知道密码，则以用户身份登录工作区

· 如果用户不知道密码并且启用了 MFA，则以用户身份登录工作区

以下所有内容都假设你至少在中等完整性上下文中可以访问用户的计算机，或者你可以远程访问文件系统，以便访问 Slack 文件夹。 从这里开始，一些特定的文件将有助于实现大多数这些目标。

列出用户在 Slack 客户端注册的工作区：

Slack/storage/slack-workspaces 或 Slack/storage/slack-teams

· 该文件包含一个 JSON 字典，其中包含关于每个团队的信息，如团队 ID、用户名、用户 ID、团队名称、团队 url 和主题信息

列出用户通过 Slack 下载的所有文件：

Slack/storage/slack-downloads

· 该文件包含有关每个下载的 JSON 字典信息，例如团队 id、文件 id、下载文件的 url (包含原始文件名)、 下载状态、本地下载路径以及开始 / 完成下载的时间

如果你知道用户的密码(而且没有 MFA) ，就以用户身份登录：

· 您可以使用Slack/storage/slack-teams来获取特定Slack工作区的团队url和用户名，然后使用你的密码通过web界面或从一个新的Slack客户端进行登录

这确实会导致一个新的登录事件，并且可能会触发电子邮件通知和日志警告。

不知道密码实现登录

所有我们已经实现的其他目标都是通过一些文件和最少的工作量的组合来实现的。 下载以下两个文件(大约40KB) ：

· Slack/storage/slack-workspaces

· Slack/Cookies

Cookies 是 Slack 客户端用来验证回 Slack 域的 sqlite 数据库。 这些 cookie 通常不会过期。

当程序需要在文件系统中存储敏感数据时，它们可以使用内置机制来保护这些文件。 在 Windows 中，这通常是通过 DPAPI 完成的。 在 Windows 上使用 DPAPI 的好处是，即使你可以远程访问这些文件(比如使用另一个用户的凭据挂载一个共享) ，你通常仍然需要在用户的上下文中对文件内容进行解密。 在 macOS 中，这通常通过在 Keychain 中存储凭证来完成。 在 Keychain 中存储凭证材料(如应用程序特定密钥)的好处是，攻击者需要知道用户的明文密码，或者让用户输入密码才能成功地取出密钥。

Chrome 就是这种保护方式的一个很好的例子，因为它遵循了这两个过程。 至少在 macOS 中，这意味着攻击者不仅需要获取用户帐户的访问权限，还需要知道用户的明文密码来解密登录密钥链以访问相应的密钥。 然而，Slack 将所有这些信息存储在未加密的磁盘文件中，因此攻击者只需对上面提到的两个文件进行读访问。 这意味着也可以远程检索这些文件，并且仍然可以利用这种技术。

一旦你拥有了这两个文件，只需按照下面的步骤模拟他们的会话：

· 安装一个新的 slack 实例(但是不要登录任何东西)

· 关闭 Slack 并将自动创建的 Slack/storage/slack-workspaces 和 Slack/Cookies 文件替换为你从受害者电脑上下载的两份文件

· 启动 Slack

你现在将自动登录到所有具有有效 Cookies 的 Slack 团队(即使他们在账户上设置了 MFA)。 你不会将用户踢出他们当前的 Slack 实例，也不会触发新的“登录”电子邮件或通知，因为你的恶意 Slack 实例使用的 Cookies 已经过验证。 下面我将演示一个示例，我会一步一步窃取“秘密爱丽丝”的 Slack 信息，读取她的信息，甚至以她的身份在频道里发消息。

Slack 攻击模拟演练

重要的是要记住，你在他们的 Slack 中扮演的是这个用户的角色，所以为了保持隐秘，你应该尽量避免点击他们的未读消息。 同样，如果你在 Slack 中搜索与你的业务相关的关键词，他们也能看到这些搜索，所以一旦你完成搜索，一定要清除痕迹。

披露

我们就这个问题联系了 Slack，要求他们至少利用内置的操作系统级功能以任何方式加密或保护信息，但我们得到了以下回应：

在与我们的内部团队进行了一些讨论之后，我们最终决定在这个时候不做更改。 虽然我们同意加密这些存储的文件是一个很好的建议，但攻击者仍然可能需要直接访问受害者的计算机才能利用它们。 此外，即使不能访问这些文件，如果攻击者设法访问受害者计算机上已安装的 Slack 实例，那么攻击者也可以利用相当多的攻击手段实现目标。 我们赞赏这一建议，并可能在今后考虑执行这一建议，但由于上述原因，我们将暂时以”信息”评级结束你提交的报告。

希望将来能解决这个问题，但是目前，即使使用 Slack 的最新安装版本，本文阐述的攻击方法也是可行的。 虽然不是开创性的，重要的是要知道，这可以绕过 MFA ，并且就我们所知，这些 cookie 从来没有设置过期时间或进行轮换。

防御方面的考虑

当防御者试图阻止或发现这种攻击方法的使用时，有一些不同的潜在的解决方案。

Slack 记录

如果你有标准、附加或企业网格计划让所有者或管理员检查他们的成员，Slack 确实提供了一些关于登录的深入了解。 如果个人用户担心，他们可以检查自己的任何层级(甚至免费)访问日志并下载它们。

Slack 的个人访问日志

查看工作区的访问日志

访问日志是检查任何不寻常或可疑的登录活动的简单方法。 

查看你的帐户的访问日志

担心有人登录了你的账户？ 或者你在使用共享设备时忘了注销 Slack。

在 Windows 中，系统访问控制列表(SACL)可以应用于本文中提到的文件，以便在 Slack 以外的进程访问文件时生成事件。

活动目录集成

我们只看到过这种技术完全停止的一个实例——与单点登录(SSO)的ADFS集成。 我们无法完全追踪它是与SSO一起严格使用的ADFS，还是与SSO一起使用的另一种机制。然而，当我们遇到这种情况时，所涉及的Slack工作空间要求我们在登录之前重新进行身份验证。

报告时间线

正如SpecterOps致力于透明化一样，我们也承认一旦攻击者的新攻击技术公布于众，他们会迅速采用这些新技术。这就是为什么在发布新的bug或攻击技术之前，我们会定期通知相关的供应商，提供充足的时间来缓解问题，并通知选择的、可信的供应商，以确保能够尽快将检测结果传递给他们的客户。

· 2019年7月9日: 通过 HackerOne 向 Slack 报告漏洞

· 2019年7月10日: Slack 要求提供更多关于漏洞的信息

· 2019年7月12日: 收到 Slack 调查报告

· 2019年7月22日: Slack 以“信息”评级结束了这个报告

本文翻译自：https://posts.specterops.io/abusing-slack-for-offensive-operations-2343237b9282如若转载，请注明原文地址：