滥用Slack的文件共享功能实现工作区成员去匿名化

本文展示了Slack工作区中的恶意成员如何利用Slack文件共享功能中的跨站泄露漏洞，在基于Chromium的浏览器中高效地去匿名化访问其恶意网站的其他工作区成员。

内容概述

• 我发现了一种抵抗SameSite=Lax的导航相关XSLeak技术
• Slack的Web客户端存在与其文件共享功能相关的跨站泄露漏洞
• 攻击者可在最多O(log n)次HTTP请求内去匿名化工作区中的其他成员
• 影响包括泄露受害者的IP地址和浏览器指纹，以及促进鱼叉式网络钓鱼攻击
• Slack暂无修复计划

跨站泄露

旁道攻击令人着迷。您可能还记得2014年MIT研究人员如何通过高速摄像机拍摄的薯片袋录像部分恢复语音。虽然在Web浏览器中进行的类似攻击通常不那么引人注目，但确实是可能的。

同源策略（SOP）作为浏览器安全的基石，确实在不同Web源之间提供了紧密的隔离，并且多年来已经实施了进一步的隔离机制；但安全研究人员一再证明，源之间的屏障实际上比看起来更具渗透性。绕过SOP从一个源向另一个源泄露数据的技术统称为跨站泄露，简称XSLeak。

泄露图像

几个月前，当我了解XSLeak的最新研究时，我注意到了TU Darmstadt的Staicu和Pradel进行的一些有趣研究，他们在2019年的USENIX上进行了展示。题为《泄露图像：Web中的定向隐私攻击》的论文展示了在某些条件下，攻击者如何滥用服务的图像共享功能来实现跨源用户的去匿名化。

Slack上的泄露资源

在阅读《泄露图像》论文时，我意识到它忽略了一个提供Web客户端并允许用户共享图像的流行消息服务：Slack。在我一个虚拟Slack工作区的简短调查后，我得出结论，Slack的Web客户端也容易受到泄露图像攻击——或者更准确地说，是泄露资源攻击，因为攻击者在Slack上与受害者共享的资源不必是图像。

绕过SameSite防御

制作概念验证的一个困难是，由于Slack的会话标识符由一个标记为SameSite=Lax的cookie（名为d）组成，共享资源只能通过顶级导航访问，而不能通过JavaScript访问。因此，攻击者必须仅依赖顶级导航，因为对该URL的其他跨站请求不会携带该d cookie。

但总有办法！攻击者的恶意页面可以简单地更新window.location变量并休眠一小段时间，以留出足够的时间让服务器响应。

针对多个用户

针对单个用户有点无聊。去匿名化攻击是否可以针对多个Slack用户，通过一次访问恶意页面就能去匿名化他们？

上述方法的一个问题是，在没有触发下载的情况下，会发生重定向，将受害者带走，并剥夺恶意页面发出进一步请求的机会。我需要一种方法来“取消”顶级导航。

一种新颖的XSLeak技术来救援

也许令人惊讶的是，基于GET的HTML表单提交算作顶级导航；因此，它携带标记为SameSite=Lax的cookie。此外，内容安全策略（CSP）提供了一种通过使用其form-action指令来定义表单提交允许列表的方法；并且，在基于Chromium的浏览器中（与Firefox和Safari相反），该指令甚至在HTTP重定向时也会强制执行。

将这些结合起来：第三方站点可以检测跨源服务器端重定向的发生，即使该重定向需要初始请求中存在某些SameSite=Lax cookie才能发生。

优化针对多个用户的去匿名化攻击

另一种更高效但更显眼的方法是可能的。Slack支持群组直接消息；换句话说，两个以上的人可以参与直接消息对话。如《泄露图像》论文第3.3节所述，攻击者可以利用此功能，通过共享不超过O(log n)个资源（确切地说是ceil(log(n)/log(2))）并从其恶意页面发送不超过O(log n)个HTTP请求，来去匿名化n个其他用户中的一个目标用户。

技巧在于为每个目标用户分配一个唯一的位向量——为匿名访问者和非目标用户保留零位向量。

向Slack负责任地披露和讨论

我通过HackerOne上的公共漏洞赏金计划向Slack报告了我的发现。可以预见的是，他们选择不奖励我的报告，但他们的回应（他们允许我在此披露）令人不满。

减轻情节

攻击的多目标变体确实存在一些限制：

• 它仅在某些浏览器中可行——最明显的是在Firefox和Safari中不可行——并且根本不适用于Slack的桌面客户端或移动应用程序，这些可能比Slack的Web客户端更受欢迎。
• 它要么产生大量通知噪音，要么无法优雅地扩展到大量目标用户。
• 可能有一种方法可以与其他用户静默共享资源而不触发任何通知，但我不知道任何方法。
• 它有些脆弱，因为它部分基于时间；不适当的延迟校准（在我的PoC中是ms）可能导致虚假结果。

成员之间的隐含信任

Slack可能高估了成员之间的隐含信任。电子前沿基金会（EFF）在一篇关于Slack隐私优缺点的文章中一针见血地指出：任何群体环境都只与参与其中的人一样值得信任。群体成员可以共享甚至截图内容，因此建立所有成员都同意的指南和期望非常重要。

低入门门槛

尽管攻击者必须是计划针对的Slack工作区的成员，但入门门槛往往很低。例如，默认情况下，任何非访客成员都可以邀请人们加入他们的Slack工作区。此外，尽管管理员可以将注册限制为电子邮件地址与允许域名列表匹配的人，但很少有人选择这样做，而当他们这样做时，他们的允许列表可能非常宽松。

工作区成员流动性

新成员加入；一些现有成员离开，无论是否自愿。甚至以前受尊敬的成员在一系列失误后也可能被禁止。事实上，Slack本身承认工作区的组成不是一成不变的，并敦促管理员出于安全原因精心管理其成员列表。

隐私对某些人更重要

在第三方跟踪泛滥和数据泄露无休止的时代，去匿名化的可能性可能只会引起普通人的无聊哈欠。但对其他人来说，隐私至关重要，不应以任何代价妥协。

用户无法防御

用户无法采取太多措施来保护自己免受去匿名化攻击。他们无法阻止攻击者安装“跟踪器”资源，因为任何工作区成员都可以向任何其他成员发送直接消息；而且，据我所知，Slack不允许用户阻止其他用户。了解攻击的用户可能倾向于静音与攻击者的直接消息对话，但这根本没有帮助。

修复指南

出于以上所有原因，Slack应该堵塞这个隐私漏洞。我可以想到两个选项。

Slack可以为访问共享资源生成用户特定的URL。一种无状态实现是让Slack的后端在URL中要求存在特定于查询用户和查询资源的某些HMAC值。不幸的是，这种方法可能难以改造而不破坏对已共享资源的访问，并且它也可能与缓存冲突。

或者，Slack可以利用称为Fetch Metadata请求头的隐私功能，该功能提供有关兼容浏览器（包括Chromium）发送的请求性质的有价值信息。

对Chromium的form-action实现的思考

form-action是否应在表单提交后阻止重定向是一个有争议的问题；甚至W3C也没有做出集体决定，并且该指令在重定向面前的行为仍未指定。相关GitHub问题中的对话迄今为止围绕表单数据泄露的风险以及严格性和可用性之间的权衡，但攻击者滥用form-action实现此处描述的XSLeak的可能性似乎被忽视了。

致谢

非常感谢Zach Edwards，他对我的发现提供了宝贵的反馈。还要感谢Alesandro Ortiz和@pixeldetracking，他们 kindly同意审阅本文的早期草稿。