隐藏火药桶：Chrome的AppBound Cookie加密

2024 年 7 月，谷歌推出了一项新功能，以更好地保护 Chrome 中的 Cookie：AppBound Cookie 加密。这项新功能彻底颠覆了信息窃取者的格局，迫使恶意软件开发者快速修改其恶意软件以适应最新的保护措施。在新的 Cookie 保护时代，信息窃取恶意软件要么需要直接访问 Chrome 进程，要么需要以提升的权限运行。

在本文中，我们将探讨新推出的 AppBound 加密技术，并介绍我们的C4 攻击（Chrome Cookie 密码破解器）。该攻击使我们能够以低权限用户身份解密 Cookie。此外，这种技术还使我们能够滥用 Google 的新安全功能来攻击 Windows 设备，并访问通常只有特权 SYSTEM 用户才能访问的数据。

本博客中详述的研究严格遵循负责任且合乎道德的安全分析原则。为了履行我们致力于为开源和安全社区做出贡献的承诺，我们在研究过程中发现的所有漏洞均已在发布前以负责任的方式向 Google 和 Microsoft 披露（请参阅下文“负责任的披露”部分）。

介绍

多年来，谷歌与世界其他地区一样，一直在努力保护 Cookie 免遭信息窃取恶意软件的窃取。由于 Chrome 占据了浏览器市场的很大份额，而且大多数其他浏览器都基于 Chromium 内核（例如 Edge、Opera），因此谷歌为 Chrome 采取的安全措施，世界上大多数国家也都采取了类似的措施。

在 AppBound 加密技术出现之前，信息窃取恶意软件要想窃取 Windows 设备上的 Cookie，需要访问两个文件：一个名为 Cookies 的 SQLite 文件，用于存储加密的 Cookie；以及一个名为 Local State 的 JSON 文件，用于存储解密 Cookie 所需的密钥（我们将其称为Cookie密钥）。Cookie 密钥使用 Windows 数据保护 API (DPAPI) 进行加密，以进一步保护 Cookie 免遭盗窃。要解密 DPAPI 加密的 Blob，进程必须在与加密进程相同的用户上下文中运行。

图 1. 旧 Cookie 保护流程

这种较旧的 Cookie 保护方法或许能有效抵御使用 WinSCP 或 RClone 等工具窃取 Cookie 文件的攻击者，但对于恶意软件而言，它并非非常有效的解决方案。由于 Chrome 在加密 Cookie 密钥时以低权限用户身份运行，因此任何以低权限用户身份运行的恶意软件都可以使用 DPAPI 解密 Cookie 密钥，进而解密 Cookie。正因如此，谷歌推出了一种新的 Cookie 保护方法。

AppBound 加密

旧的 Cookie 保护方法与 AppBound 方法相比有三个主要变化：

图 2. AppBound 加密流程

添加了 SYSTEM DPAPI 加密：添加了一层新的加密（如图 2 中的步骤 4 所示）。现在，Chrome Cookie 使用一个密钥进行加密，该密钥首先受用户 DPAPI（User-DPAPI）保护，然后使用 SYSTEM 帐户的 DPAPI（SYSTEM-DPAPI）再次加密。这意味着只有 SYSTEM 级进程才能解密 Cookie，从而阻止低权限恶意软件的访问。然而，这也带来了一个新问题：由于 Chrome 以普通用户身份运行，它无法再自行解密 Cookie。

委托解密：为了解决新问题，加密和解密被委托给 Google 创建的 COM 服务器，称为提升服务（图 2 右侧）。提升服务随 Chrome 一起安装，并以 SYSTEM 权限运行。

在新设置中，Chrome 会通过 COM 请求将加密的 blob 发送给提升服务进行解密。提升服务会使用 DPAPI 两次——第一次是 SYSTEM-DPAPI，第二次是 User-DPAPI（使用令牌模拟）。结果是 Cookie 密钥，该密钥返回给请求者（Chrome），然后可用于解密 Cookie。但这又引发了最初的问题：由于提升服务是一个 COM 服务器，任何进程都可以向提升服务发送 COM 请求来解密 Cookie。

添加路径验证数据：第三部分通过将请求进程的路径与一些验证数据（图 2 中的步骤 6）进行比较来解决最后一个问题。验证数据是原始加密进程（在本例中为 Chrome）的路径。当 Chrome 初始创建 Cookie 密钥时，提升服务会同时加密 Chrome 可执行文件路径和 Cookie 密钥。然后，当 Chrome 请求 Cookie 密钥时，提升服务会将请求者的路径与加密后的路径进行比较。只有路径匹配时，提升服务才会返回密钥。

这三个功能组合在一起构成了 AppBound Cookie 加密（见图 2）。引入此功能迫使恶意软件开发者改变 Cookie 窃取的实现方式，主要通过提升权限运行或从 Chrome 内存中提取 Cookie 来实现。

攻击 AppBound 加密

AppBound Cookie 加密的设置非常复杂，而且它严重依赖于 DPAPI，而 DPAPI 本身就非常复杂。由于这两项复杂功能是由多家公司的不同团队开发的，因此出错的可能性更大，我们认为出现不匹配的情况的可能性相对较高，从而导致安全问题。

我们决定探索 AppBound 加密，看看低权限恶意软件是否仍有办法在无需访问 Chrome 的情况下窃取 cookie。

有很多有希望的地方可以开始寻找：

• 尝试模拟 Chrome 来获取提升服务，以便向我们提供密钥

• 尝试模拟提升服务，以便 Chrome 使用恶意软件创建的密钥加密 Cookie

• 窃听 Chrome 与提升服务之间的通信以获取 Cookie 密钥

• 降级攻击使 Chrome 使用旧的 Cookie 加密方法，因此低权限恶意软件也可以解密它们

• 最后，虽然这看起来有些牵强，但破解加密

对于管理员来说，许多变种攻击都相当容易实现。例如，创建一个名为 chrome-decrypt.exe 的恶意软件，并将其保存在与 Chrome 相同的文件夹中，这样就可以冒充 Chrome 从提升服务获取 Cookie 密钥（这是可能的，因为在进行验证时会修剪部分路径）。另一个例子是用恶意代码替换提升服务二进制文件。同样，通过使用组策略，可以禁用 AppBound 加密。

然而，我们的目标是低权限访问，而这些想法需要管理员权限。针对低权限用户，我们发现了两种有效的攻击方式。

COM劫持

第一个想法很简单。提升服务是一个 COM 服务器。这立刻促使我们考虑COM 劫持的可能性。不出所料，提升服务（与许多 COM 服务器一样）容易受到 COM 劫持。理论上，攻击者可以编写专门的 COM 服务器恶意软件来充当提升服务的角色。

然后，每次打开 Chrome 时，浏览器都会向恶意软件发送 Cookie 密钥请求，恶意软件可以发送任何它选择的密钥。不过，这种技术有一些局限性，因为在 COM 劫持之前加密的所有 Cookie 都会丢失，信息窃取者必须等待 Chrome 使用恶意软件提供的密钥保存新的 Cookie，然后才能访问它们。

另一个缺点是创建 COM 服务器可能非常繁琐。然而，事实证明，这对于这项技术来说并非绝对必要。一个更简单的替代方案是使用 COM 劫持将 Chrome 指向一个不存在的二进制文件。如果 COM 服务器不存在，Chrome 会恢复使用旧的加密方法。同样，所有旧的 Cookie 都会丢失，因此恶意软件必须在攻击生效之前在设备上停留一段时间。

图 3 展示了此次攻击的演示。上半部分展示了在 HKCU 配置单元中设置值之前的情况（第一行显示“NAME NOT FOUND”，最终导致在 HKCR 下找到了提升服务二进制文件（高亮显示行）。下半部分展示了在 HKCU 下设置值之后发生的情况（结果现在为“SUCCESS”），这导致 Chrome 去查找一个名为 aaa.dll 的不存在的 dll。

图 3. Chrome COM 劫持之前（顶部）和之后（底部）

C4：Chrome Cookie 密码破解器

从技术角度来看，针对 AppBound 加密的下一次攻击更加引人注目。此次攻击最初只是试图冒充 Chrome，后来逐渐演变成更大规模的攻击。

利用位翻转攻击进行欺骗——失败

提醒一下，提升服务会将请求进程的路径与验证数据中保存的路径进行比较。您可能认为，尝试冒充请求者比尝试操纵经过两次 AES 加密的路径更容易。但是，提升服务使用的 API QueryFullProcessImageName 似乎是从内核（可能是 EPROCESS 结构）获取路径的，而操纵该路径并不容易。

与此同时，事实证明 AES 的安全性远低于我们通常认为的水平。作为一种分组密码，AES 旨在加密长度为 16 字节的单个分组。据我们所知，当用于此目的时，AES 几乎无法破解。然而，大多数明文的长度并非恰好为 16 字节，因此我们使用“加密模式”和“填充”的组合来处理这些不同长度的明文。虽然这些功能必不可少，但它们也存在许多陷阱，可能使攻击者能够操纵明文，甚至可能在无需知道密钥的情况下完全破解加密。

DPAPI 使用一种称为密码块链接 (CBC) 的加密模式，该模式与 AES 相结合，通常记为 AES-CBC。虽然 AES-CBC 可能是全球最流行的加密模式，但它存在许多内在问题。

其中一个问题被称为位翻转攻击。本质上，每个块都通过 AES 单独解密，然后将结果与前一个块的密文进行异或运算（对于第一个块，则使用初始化向量）。这一点很重要，因为这意味着如果攻击者窃取了密码块C n， 那么下一个块的明文将从P n+1 变为P n+1  ⊕ X（图 4）。

图 4. 位翻转攻击

虽然这种攻击在 CBC 中始终存在可能性，但其用途有限。通常情况下，攻击者不会知道明文，因此以可预测的方式修改明文并不会特别有用。此外，通过修改C n，区块P n（与区块C n关联的明文）将发生不可预测的变化（图 4 中的P n *）。

尽管位翻转攻击存在局限性，但在我们的案例中，它似乎是一种值得尝试的方法。因为在我们的案例中，我们知道部分明文是指向 Chrome 浏览器的路径。如果我们能将该路径更改为不需要高权限写入的位置，我们就可以从那里运行恶意软件，并绕过提升服务验证！

最终，事实证明 DPAPI 对其 blob 进行了签名，以防止他人篡改密文。当尝试解密已被篡改的 DPAPI 加密 blob 时，可以在 Windows 事件查看器中清楚地看到错误消息（图 5）。

填充 Oracle 攻击 – 成功！

虽然对失败感到失望，但我们注意到 Windows 事件查看器中的错误有些奇怪。通常，“失败原因”是“MAC 检查失败”（MAC 是签名），但有时原因会变成“未知”（参见图 5）。经过一番检查，我们发现差异源于明文填充的有效性。

DPAPI 使用PKCS7填充来确保明文长度是 16 的倍数。如果解密后填充的 PKCS7 格式无效，则会抛出错误，并显示“失败原因：未知”消息。只有当填充有效时，才会检查签名。最后，如果签名无效，则会写入“失败原因：MAC 检查失败”消息。

图 5. Windows 事件查看器中的 DPAPI 错误

关于填充的讨论乍一听可能不太重要，但实际上它为一种可怕且罕见的密码攻击打开了大门，这种攻击被称为“填充预言机攻击”。简而言之，这种攻击允许用户更有效地暴力破解密码的明文，从而允许在合理的时间内破解密文。

要实施填充预言攻击，攻击者需要两样东西：以可预测的方式修改明文末尾的能力（位翻转攻击内置于 CBC 中）以及一个填充预言机。填充预言机是一个黑匣子，它接收密文并指示明文的填充是否有效（我们可以从事件查看器中获取）。攻击的工作原理是反复将修改后的密文发送到填充预言机，并根据预言机的响应调整修改内容。

使用 Windows 事件日志作为填充预言机 (padding Oracle)，我们能够实施填充预言机攻击 (padding Oracle Attack)，以低权限用户身份解密 Cookie。我们首先从本地状态文件中提取两次加密的 DPAPI blob。然后，我们通过向提升权限服务发送多个请求来实施填充预言机攻击，每个请求都包含一个略微修改过的 DPAPI 加密 blob 版本。填充预言机攻击使我们能够破解最外层的加密，从而有效绕过 SYSTEM-DPAPI。

结果是另一个 DPAPI blob，但这次是 User-DPAPI 加密的 blob。由于低权限用户加密了该 blob，因此只需调用 CryptUnprotectData 即可解密。对于大多数 Chromium 浏览器来说，这足以恢复 Cookie 密钥。

然而，谷歌在其 Chrome 浏览器中添加了一个称为后处理的步骤（该步骤不属于 Chromium 通用项目）。我们在此不做详细介绍，但简而言之，CryptUnprotectData 返回的内容会使用硬编码密钥进行加密，然后进行一些异或运算。加密结果就是 Cookie 密钥，我们用它来解密 Cookie：

给填充预言攻击起一些比较滑稽的名字，这些名字也是描述该攻击的缩写，这在某种程度上是一种传统。最著名的例子是 POODLE、BEAST 和 ROBOT。对于我们的攻击，由于我们要破解 Chrome 用于 Cookie 的密码，因此我们选择了C4：Chrome Cookie 密码破解器。

填充 Oracle 限制

虽然填充预言攻击是一项巧妙的发现，但它也存在一些局限性。攻击似乎运行缓慢。许多猜测耗时超过一秒，而完全解密则耗时约 16 小时。这可能是因为每次猜测都需要多次文件读写操作和多个 IPC 请求响应（其中一些在博文中有所提及，更多则来自 CryptUnrptectData 的内部工作原理）。一些可能提高速度的方案包括：跳过明文固定/可预测的部分，或者尝试对填充预言进行时序攻击，而不是依赖事件。然而，攻击很可能仍需要几个小时。

另一个限制源于填充预言攻击中暴力破解的实现方式。为了对明文中某个字节尝试不同的值，需要修改前一个块中的某个字节。对于第一个明文块，我们需要修改 IV（初始化向量）。然而，DPAPI 使用固定的 IV（全为空字节），从而阻止攻击者暴力破解明文的前 16 个字节。

在破解 Chrome Cookie 的情况下，第二个限制并不成问题。我们尝试获取的明文本身就是一个 DPAPI 加密的 blob（以低权限用户身份加密的 blob）。由于 DPAPI blob 的前 20 个字节是固定的，因此我们不需要使用 Padding Oracle Attack 来破解它们。

C4 攻击的其他用途

经过一番思考，我们意识到这种攻击并不局限于 Chrome Cookie。事实上，由于提升服务允许低权限用户触发对 SYSTEM 加密 blob 的解密尝试，因此我们可以破解任何 SYSTEM-DPAPI blob（但需遵守上述限制）。其他程序也可能具有相同的设置，并可能被滥用来破解 SYSTEM 加密的 blob。

考虑到这一点，我们简要地搜索了其他潜在的目标或用例。大多数都不太实用。然而，有一个特殊情况我们认为值得一提。顾名思义，Windows 凭据管理器用于存储凭据。由于以明文形式存储凭据并非明智之举，因此通常使用 DPAPI 进行加密。

奇怪的是，似乎有一个内置对象作为属于 SYSTEM 权限的 Windows 凭据存储。该对象实际上是一个 SOAP XML 文件，其中包含一个用户和一个身份验证令牌。我们不确定它的用途，因为该用户似乎是“passport.net”域中随机生成的用户，而不是 Windows 计算机的用户。据我们了解，passport.net 域过去曾用于 Microsoft 单点登录，但目前已不再使用。

虽然 SOAP XML 没有明确的用途，但我们决定继续研究这个方向。任何以 SYSTEM 权限运行的进程，如果通过凭据管理器存储凭据，很可能也会以 SYSTEM 权限使用 DPAPI 加密数据。经过一番搜索，我们发现 Windows 任务计划程序可以被滥用。该任务计划程序可以配置为即使用户未登录也能运行任务。要实现这一点，必须手动将凭据添加到任务中。然后，计划程序会将凭据保存在凭据管理器中。更妙的是，凭据被保存为一个更大对象的一部分。这意味着，即使填充 Oracle 攻击无法解密前几个字节，我们仍然可以从类似的 Blob 中提取凭据。

图 6. 创建任务需要存储在 Windows 凭据管理器中的凭据

相反，使用任务调度程序破解 DPAPI blob 的加密在理论上是可行的，但在实际操作中却并非如此。任务调度程序似乎会在启动过程中尝试解密 blob。因此，攻击者每次猜测都需要重启计算机。这会非常缓慢且噪音很大，并且每次猜测都需要用户登录，这使得这种攻击比最初滥用 Google 权限提升服务的方法更加严重。即便如此，这只是我们快速查看特征后发现的一个例子。在 Windows 上可能存在另一个更实用的攻击版本。

总结与结论

目前，在微软构建的 DPAPI 机制中，任何以特定用户身份运行的进程都可以解密受该用户保护的数据。然而，微软也将其设置为只有以该用户身份运行的进程才能解密。谷歌试图限制这种情况，以便只有一个进程可以访问受保护的数据，但这需要允许低权限用户以 SYSTEM 用户身份创建请求。这样做最终导致谷歌允许低权限用户破解任何 SYSTEM-DPAPI blob。

这个问题的发生完全不明显，我们花了大量的尝试和错误才找到答案。然而，这也表明，当尝试以新的方式使用旧功能（尤其是安全功能）时，往往会遇到意想不到的问题。

最后一点：根据维基百科，CBC 仍然是最常见的加密模式。考虑到该加密模式本身存在的问题，或许是时候考虑 CBC 的不安全性并放弃它了。在多次 Padding Oracle 攻击之后，TLS 中弃用 CBC 的做法反复证明了互联网流量是可以被破解的。

特别感谢 Erez Waisbard 博士在处理密码学时提供的帮助和指导。

负责任的披露

我们已将这些问题报告给微软和谷歌。虽然微软和谷歌均未将这些问题归类为 CVE，但谷歌已表示将尝试修复 Padding Oracle 攻击。截至 6 月 23日，Chrome 中已提供部分解决方案，但默认情况下处于禁用状态。完整的解决方案将在未来的版本中添加。

报告时间表：

COM劫持攻击——谷歌：

2024 年 12 月 3 日 – 问题已报告

2024 年 12 月 4 日 – 问题已转至分类状态

填充 Oracle 攻击 — Google：

2024 年 12 月 4 日 – 问题已报告并转入分类状态

2025 年 2 月 26 日 – 问题已移至已接受状态

填充 Oracle 攻击 — 微软：

2025 年 3 月 26 日 – 问题已报告

2025 年 4 月 15 日——微软拒绝了该问题，因为他们认为报告的行为不符合安全修复的标准，并指出由于环境限制，实际可利用性较低。