应用安全工程提升反钓鱼能力 - 案例研究

19 Sep 2024 - 发布者 Szymon Drosdzol

引言

近期 Doyensec 受雇于一家提供"通信平台即服务"的客户。该平台允许其客户通过多种渠道（电子邮件、网络聊天、社交媒体等）打造客户服务体验并与自己的客户进行沟通。

虽然这种服务无疑具有价值，但它也引入了独特的威胁模型。客户的用户每天需要处理大量来自外部（通常是匿名）用户的来信，这使得他们特别容易受到钓鱼和其他社会工程攻击。

虽然无法完全消除此类威胁，但可以尽量减少被利用的可能性。认识到这一点，客户聘请 Doyensec 进行安全审查，特别关注社会工程攻击，尤其是钓鱼攻击。今年早些时候进行的这次合作证明对双方都极具价值。最重要的是，客户利用审查结果大大提高了其平台对社会工程攻击的抵抗力。此外，Doyensec 的工程师也有很好的机会在标准安全审计中释放他们的创造力，关注那些经常被忽视或严重低估的漏洞（看看你，CVSS 分数！），并从蓝队角度审视应用程序的防御。

以下案例研究将讨论本次审计中处理的一些漏洞。希望这篇文章能帮助开发人员了解他们的平台中可能潜伏着哪些类型的漏洞。它也有助于展示这种有针对性的合作作为标准网络审计补充的巨大价值。

附件处理

对于任何客户支持组织来说，文件附件管理都是一个关键功能。一方面，用户需要能够与对话者共享文件样本、截图等。另一方面，共享文件始终是利用各种安全漏洞的温床，尤其是在接受来自不可信方的文件时。因此，加固应用程序的这一部分需要仔细考虑如何在不牺牲可用性的情况下确保机密性和完整性。

通过尾随句点绕过文件扩展名限制

测试平台采用了一个强大的系统，旨在验证允许的文件扩展名和内容类型进行文件上传，并具有全局禁止列表，禁止 inherently dangerous 文件类型，如可执行文件（例如 .exe）。这些措施旨在防止上传和分发潜在恶意文件。然而，通过利用某些浏览器的特性，发现了一个漏洞，允许用户只需在文件扩展名后附加一个尾随句点（“悬空点”）即可绕过这些限制。

通过制作一个带有禁止扩展名（如 .exe.）的上传请求，可以绕过此文件扩展名限制。这导致系统接受该文件，因为它表面上符合允许上传的标准 - 其中包括空扩展名。然而，Firefox 和基于 Chromium 的浏览器会移除悬空点（有趣的是，Safari 会保留它）。结果，文件以原始 .exe 扩展名保存在受害者的文件系统上：

![文件扩展名绕过示例]

这里的建议很简单。应从文件名中移除尾随点。在现实场景中很少有用，因此可用性权衡很小。

通过子域名制作规避内容来源限制

平台聊天创建时有一个限制，只允许来自客户子域名的链接附件。此安全控制旨在将图像和附件的上传和引用限制在预定义的一组来源，防止使用可能用于钓鱼攻击的外部来源。预期的验证过程依赖于域名白名单。

然而，当使用正则表达式验证（子）域名时，很容易忘记这种语法的复杂性，这可能导致难以发现的绕过。

Doyensec 观察到子域名使用类似于 /acme-attachments-1.com/ 的正则表达式白名单进行匹配。这样的正则表达式不强制字符串的开头和结尾，因此会接受任何包含所需子域的域名。攻击者可以创建一个类似于 acme-attachments-1.com.doyensec.com 的子域，尽管有此安全机制，它仍会被接受。

另一个常见（尽管在这种情况下不可利用）的错误是忘记点（.）字符在正则表达式中被视为通配符。当忘记在域正则表达式中转义点时，攻击者可以注册一个绕过此类限制的域。例如，类似于 downloads.acmecdn.com 的正则表达式会接受攻击者控制的域，如 downloadsAacmecdn.com。

值得注意的是，尽管这个漏洞看起来无害，但它实际上具有创建成功钓鱼攻击的巨大潜力。当受害者在受信任的平台上收到附件时，他们更有可能点击链接。此外，登录页面对受害者来说并不意外，进一步增加了他们泄露凭据的可能性。

反病毒扫描绕过

平台适当地对所有传入文件实施反病毒扫描。然而，攻击者可以通过创建加密存档来混淆有效负载的真实内容：$ zip -e test_encrypted.zip eicar.com。

没有简单的解决方案来解决这个问题。完全禁止加密存档是一种可用性权衡，在某些情况下可能不可接受。Doyensec 建议至少明确警告用户不要打开加密文件。通过创建适当的配置开关，允许客户选择哪种权衡对他们可接受也可能有用。

HTML 输入处理

在交换消息时，添加格式并给用户更多表达方式非常有用。另一方面，当消息来自不可信来源时，此类功能可以使攻击者制作复杂的攻击，涉及 UI 伪装，例如，在其消息中模拟 UI 元素。

我们的客户找到了一个很好的方法来平衡可用性和安全性。虽然受信任的用户有丰富的输入格式选项，但来自平台外部的不可信用户只能共享基本的纯文本消息。还值得注意的是，即使受信任的用户也无法将任意 HTML 注入他们的消息，因为 HTML 标签被正确解析和编码。然而，有一些特定标签是允许的，并且在某些情况下会转换为更复杂的元素（例如，链接标签转换为按钮）。

Doyensec 发现此解决方案在设计层面架构良好。然而，由于实现中的疏忽，公共消息 API 也接受了一个"隐藏"（前端未使用）参数，该参数允许某些 HTML 元素。Doyensec 能够利用链接到按钮的转换来演示使用此漏洞欺骗 UI 元素的潜力。

![HTML 输入处理漏洞示例]

通过完全禁用公共 API 中的此参数，只允许经过身份验证的用户格式化他们的消息，解决了这个问题。

链接呈现错误

数据呈现错误是一种特别容易被忽视的威胁。尽管它们有可能操纵或扭曲关键信息，但数据呈现错误在安全评估中经常被低估，在修复工作的优先级排序中被忽视。然而，它们的利用可能导致严重后果，包括钓鱼。

误导性 Unicode 域名渲染

要理解这个问题，重要的是理解两个不同的术语。首先，Punycode 是一种字符编码方案，用于表示域名中的 Unicode 字符。它使浏览器和其他 Web 客户端能够处理域名中的 Unicode。其次，我们有同形异义词，这些字符看起来非常相似，但具有不同的代码。虽然视觉上无法区分，但考虑字符 ‘a’（代码：0x61）和 ‘а’（代码：0x430）实际上是两个不同的字符，当用于 URL 时会导致两个不同的域。

这种威胁最突出的例子之一是由研究员 Xudong Zheng 创建的。该研究员创建了一个链接，看起来与广泛受信任的 www.apple.com 域非常相似。然而，链接 https://www.аррӏе.com 在展开 Punycode 字符串后实际上解析到 www.xn--80ak6aa92e.com。访问该链接显示它不受 Apple 控制，尽管其外观令人信服：

![Unicode 域名欺骗示例]

为了保护用户免受此类问题的影响，我们建议以 Punycode 格式呈现 Unicode 域。这样用户就不会被欺骗关于给定链接指向何处。

通过 RTLO 注入进行 URI 和文件名欺骗

使用从右到左覆盖（RTLO）字符是另一种操纵链接显示方式的技术。RTLO 字符更改连续字符的呈现顺序。当涉及到文件名和 URL 时，它们的结构是固定的，字符顺序很重要。因此，翻转字符顺序是掩盖链接真实目标或文件扩展名的有效方法。

听起来复杂？一个例子会澄清它。考虑指向攻击者控制域的链接：https://gepj.net/selif#/moc.rugmi 它看起来可疑，然而当在前面加上 RTLO Unicode 字符（[U+202E]https://gepj.net/selif#/moc.rugmi）时，它会以以下方式呈现：

![RTLO 注入示例]

显示的文件扩展名可以以类似方式操纵： 考虑一个名为 test.[U+202E]fdp.zip 的文件：

![文件名欺骗示例]

这里提出的解决方案很简单 - 更严格的过滤。当字符顺序更改时，URL 不应呈现为链接。类似地，应拒绝包含字符流操纵器的文件名。

不可信链接导航确认

即使链接始终正确显示，攻击者仍然有机会创建成功的钓鱼活动。毕竟，用户总是可能被胁迫点击恶意链接。这种风险无法完全消除，但可以通过额外的加固来缓解。检查的平台实现了导航确认插页式广告。这意味着，每当用户点击平台外部的链接时，会出现一个额外的确认屏幕。此类 UI 元素通知用户他们正在离开安全环境。这种 UX 设计大大降低了成功钓鱼攻击的机会。

总结

这个项目是针对特定威胁进行主动合作的一个很好的例子。鉴于该平台的特定威胁模型，这样的合作作为常规安全评估及其漏洞赏金计划的补充已被证明极其有用。特别是，专门关注钓鱼和社会工程的合作使我们能够制定一系列建议和加固想法，否则这些在常规安全审查中只是旁注。