Mark-of-the-Web 与安装程序固定至站点

# Mark-of-the-web 与将安装程序固定到站点 来源：https://blog.randomoracle.io/2026/06/20/mark-of-the-web-and-pinning-installers-to-sites/ 能否创建一个根据下载来源网站而行为不同的应用程序？乍看之下，如果严格解释这个问题，这似乎不可能实现：下载的内容必须在字节级别完全相同（如果允许每个站点修改内容，那就太简单了）。成功标准可以总结为： - 从原始 URL #1 提供应用程序。 - 复制下载的文件，并从另一个 URL #2 镜像。 - 从镜像站点下载时，应用程序的行为与原始位置不同。 ## 回顾：Web 安全的黑暗时代与 Mark-of-the-web ### 天真的区域划分 在 20 世纪 90 年代末，随着 Web 开始起飞，微软的网页浏览器 Internet Explorer 的安全模型基于一种过分简化的世界区域划分，显得可笑。虽然用户可以定义自定义区域，但有 5 个内置区域： - 本地计算机 - Intranet - 受信任的站点 - Internet - 受限站点 浏览器安全策略随后根据区域进行配置。以 ActiveX 控件为例：这些是任意的、不受约束的原生 Win32 代码，以用户的全部权限运行——在大多数 Windows 安装中这意味着管理员权限——并且可能对机器造成严重破坏。如果用户访问一个试图运行 ActiveX 控件的网页，会发生什么？如果该页面来自友好的企业内部网络（即“Intranet”区域），没问题：直接运行代码，无需询问。但来自狂野的 Web（即“Internet”区域）的随机网站则需要更加谨慎：用户必须点击一个包含 Authenticode 签名信息的加密模态对话框，然后才能允许该代码执行。1 (https://blog.randomoracle.io/2026/06/20/mark-of-the-web-and-pinning-installers-to-sites/#sdfootnote1sym) 虽然这种模型在浏览器内部呈现的内容方面“有效”（按其初衷），但对于下载的附件却存在明显问题。假设恶意软件 `malware.exe` 先被下载，然后从 Windows shell（称为“explorer”，它自然将其名称赋予了 Web 浏览器，遵循微软的创意命名惯例）打开。原则上，相同的基于区域的区分应该适用于用户体验：是否显示任何警告，以及使用何种恐怖语言解释继续打开文件决定的后果，应该取决于文件是来自友好的企业内网，还是来自危险的未知 Internet。 ### Mark-of-the-web 这就是 `mark-of-the-web` (https://isc.sans.edu/diary/31732)（通常缩写为 MoTW）要解决的问题。每当下载文件时，IE 会保存关于该文件的额外元数据，包括其来源 URL 和区域映射。2 (https://blog.randomoracle.io/2026/06/20/mark-of-the-web-and-pinning-installers-to-sites/#sdfootnote2sym) 如何在不更改内容本身、并保证元数据永久附加到文件的情况下做到这一点，这并非显而易见。如果 IE 只是在同一目录中写入第二个隐藏文件，那么一旦用户将原始文件（用户意识到的唯一文件）复制到另一个目录，连接就会断开。相反，MoTW 利用了 NTFS 文件系统的一个古老特性：每个文件可以有多个“备用数据流”。大多数文件只有一个流：默认的、我们通常视为内容的流。但可以创建额外的流来存储任意数据，而无需更改原始内容。（Linux 有扩展属性，macOS 有类似的概念以及命名分支。）MoTW 使用特定的数据流来存储文件下载时的来源信息，为未来的安全决策保留该上下文。 ## 利用 MoTW：从概念验证到纵深防御 ### 利用 MoTW 进行内省 虽然 MoTW 旨在供操作系统和其他感知来源的应用程序（如 MSFT Office）做出安全决策，但可执行文件也可以访问自身的 MoTW。这是基于 `proof-of-concept` (https://github.com/randomoracle/MoTW-introspection) 的基础，该概念验证是一个简单的 Win32 GUI 应用程序： - 从 `Github` (https://github.com/randomoracle/MoTW-introspection/releases/download/0.1.0/motw_check.exe) 下载并执行时，显示“Hello world”消息。 - 从 `另一个位置` (https://www.ideesfixes.io/distribution/motw_check.exe) 下载时，则会显示一条关于无法识别来源的错误消息。 两个文件具有相同的 SHA256 哈希：002d0bdbaaad909c8a6b49939b7f19ed8e897debce7aceb82732c2d590359bf2 [](https://blog.randomoracle.io/wp-content/uploads/2026/06/screenshot-from-2026-06-20-18-07-38.png)[](https://blog.randomoracle.io/wp-content/uploads/2026/06/image-7.png)（一个注意事项：由于此可执行文件没有 Authenticode 签名，SmartScreen 可能会干扰演示。点击 SmartScreen 警告继续运行可执行文件将会**删除 mark-of-the-web**，并将其替换为 ScreenConnect 使用的另一个备用数据流。这种设计是有意的；目的是避免在用户已表示某个二进制文件安全时重复发出警告。为避免此类干扰，只需打开终端窗口，直接通过命令行执行二进制文件，而不是通过 Windows shell。） 这满足了引言中关于应用程序行为取决于分发点的标准。在讨论这种技巧可能有用的更现实场景之前，重要的是要认识到威胁模型上的局限性：MoTW 可以被用户轻易篡改或删除。它未经身份验证。（尽管 URL *本身*可能包含应用程序可以验证的签名，因为查询字符串参数允许附加任意数据。但在相同的威胁模型下，用户也可以篡改二进制文件本身，因为我们假设对文件具有写入权限。）这意味着它不能用于对机器所有者实施任意策略，例如强制执行软件上的许可证限制。 ### 双用途应用程序的恶意再利用 回想一下 2025 年的 `ScreenConnect` 案例 (https://blog.randomoracle.io/2025/06/16/the-story-behind-screenconnect-certificate-revocation/)：ScreenConnect 是由 ConnectWise 发布的一款双用途远程控制应用程序，表面上用于 IT 部门管理其设备群。由于 ConnectWise 的 `可疑设计决策和自摆乌龙` (https://blog.randomoracle.io/2025/06/26/screenconnect-unauthenticated-attributes-are-not-authenticated/)，ScreenConnect 在威胁行为者中变得非常流行，他们使用由 ConnectWise 签名的真实签名安装程序来接管毫无戒心的消费者的 PC 并劫持其账户。攻击者的作案手法包括从 ConnectWise 获取合法安装程序，修改一些“自由格式”数据而不使 Authenticode 签名失效，然后将这些恶意安装程序从他们自己的网站以不同的伪装提供。例如，在本文剖析的攻击活动中，它被重命名为 RiverDesktop.exe，以冒充 River Financial 的一个不存在的桌面应用程序。 如果 ScreenConnect 安装程序使用了 MoTW 内省——或者实际上，任何类型的内省，从查看*自身名称*开始——它本可以轻易检测到这种滥用并拒绝继续安装。即使安装程序被定制为信任攻击者指定的恶意分发 URL，也可以在很大程度上最小化爆炸半径：恶意网站很快就会被关闭，攻击者依赖于能够轮换使用多个相似域名，与防御者玩打地鼠游戏。一个不关心分发点的安装程序可以从任何主机提供；而一个固定到特定分发点的安装程序在第一次滥用报告后就失效了。 尽管之前关于用户能够篡改 MoTW 的警告，但有三点原因说明这种缓解措施*对于这种特定的威胁模型*仍然有效： 1. 重要的是，远程提供恶意软件的*攻击者*无法篡改 MoTW。是用户自己的受信任 Web 浏览器——Chrome、Edge、Firefox、Safari 等——决定了该备用数据流的内容。虽然攻击者可以注册任何域名并从他们选择的 URL 提供恶意二进制文件，但仍会创建一个 MoTW，并且该 URL 会被逐字反映。 2. 用户没有动机去移除 MoTW 或以其他方式篡改它。回顾一下，攻击依赖于诱骗用户下载并运行他们认为是合法应用程序的东西。用户*可以*启动记事本并编辑包含 MoTW 的备用数据流，但攻击者没有办法促成这种情况发生。 3. 攻击者无法篡改安装程序以移除 MoTW 内省，而不会极大地削弱其骗局的说服力。回顾一下，对二进制文件的任何修改都会使原始软件发布者的 Authenticode 签名失效。这些骗局之所以有效，正是因为 Windows 对由 ConnectWise（一家信誉良好的企业 IT 应用程序供应商）签名的代码给予信任。无效签名或未签名的应用程序将会触发各种额外的警告。3 (https://blog.randomoracle.io/2026/06/20/mark-of-the-web-and-pinning-installers-to-sites/#sdfootnote3sym)（如果攻击者不关心从签名继承的信任，他们就没有理由费心使用 ScreenConnect。他们可以使用任何数量的、专门制作的、在暗网上可购买的恶意 RAT 应用程序。） CP 1 (https://blog.randomoracle.io/2026/06/20/mark-of-the-web-and-pinning-installers-to-sites/#sdfootnote1anc) 后来版本的 IE 试图通过使运行 ActiveX 控件越来越困难来提高安全性。例如，不再需要显式是/否决策的模态对话框，用户需要注意到状态栏上方的一个细微通知，指示该页面想要运行一个控件。 2 (https://blog.randomoracle.io/2026/06/20/mark-of-the-web-and-pinning-installers-to-sites/#sdfootnote2anc) 注意这里明显的 TOCTOU（检查时间与使用时间）问题：如果区域映射发生变化，元数据仍然会反映原始分类。 3 (https://blog.randomoracle.io/2026/06/20/mark-of-the-web-and-pinning-installers-to-sites/#sdfootnote3anc) 果然，在 2026 年的 `类似攻击活动迭代` (https://blog.randomoracle.io/2026/06/03/screenconnect-redux-the-limits-of-certificate-revocation/) 中，他们被观察到使用了由微软自己的身份验证 CA 颁发的代码签名证书。这使他们摆脱了必须使用“原厂”ScreenConnect 二进制文件的限制，并且理论上允许修改供应商逻辑。