企业官网建设流程全解析

传递通行密钥：无密码认证中的新型攻击面

本文分析了针对无密码认证的新型攻击类型，重点关注 Google 的同步通行密钥生态系统以及桌面客户端使用的云端身份验证器。这些攻击展示了受感染端点上的恶意软件如何滥用注册、恢复和设备信任流程，从而接管受通行密钥保护的账户。还展示了攻击者如何在无需用户交互的情况下进行身份验证，绕过用户验证要求，并提取所有同步的通行密钥私钥。

经过数十年的安全漏洞和数十亿的损失，以密码和共享密钥为特征的攻击向量终于开始逐渐消失。通行密钥利用公钥加密技术取代了密码和传统的多因素认证（MFA），减少了多年来一直主导威胁格局的各类攻击。由于没有可窃取、重复使用或钓鱼的共享密钥，攻击者许多最可靠的工具正逐渐过时，这对凭证盗窃市场造成了重大冲击。然而，攻击者不会轻易罢手，他们会不断进化，因此防御者必须为新一代的攻击做好准备。随着通行密钥的广泛采用并应用于数十亿个账户，防御者必须警惕新的攻击面，研究中揭示了其中一些。

本文是从安全角度审视通行密钥采用情况系列文章的第三部分。若还没阅读过前几部分，建议从以下文章开始：第一部分：无形密钥的艺术——通行密钥的全球突破；第二部分：Google 身份验证器：无密码认证的隐藏机制。

Palo Alto Networks 的客户可通过以下产品和服务更好地防范这种新的攻击向量：Cortex 云身份安全、Idira 威胁检测与响应、Idira 端点权限管理器、Idira 特权访问管理。如果认为自己可能已遭受攻击或有紧急情况，请联系 Unit 42 事件响应团队。

背景介绍

Google 的同步通行密钥实现具有重要的参考价值，其规模庞大，并在两个关键方面为私钥保护设定了更高标准：私钥在云隔离环境中生成和使用；由硬件支持、与客户端设备绑定的密钥控制对基于云的加密操作的访问，确保用户在可信设备上进行操作。

本文基于此前系列文章第一部分和第二部分的架构分析展开，现在将关注点从通行密钥的构建和部署转移到攻击者如何滥用它们。介绍了三种新型攻击，这些攻击可实现对受通行密钥保护账户的接管。每种攻击都挑战了通行密钥认证安全的不同核心假设。当客户端使用通行密钥进行身份验证时，通常期望满足以下条件：用户在设备上提供明确同意，以验证用户存在；对于 MFA，用户还必须解锁设备，以验证基于生物特征或知识的认证因素；通行密钥私钥不能共享或复制。

Google 文档体现了这些核心假设，将通行密钥登录过程描述为比密码更安全的替代方案。将挑战这些预期的一类攻击戏称为“Pass - ta - key”，这个有趣且层层递进的名字融合了“passkey”和“pass the key”这两个词，同时也略带调侃地暗示了这种密钥实现可能会变得多么复杂。

这些攻击在实践中各自暴露出不同的弱点：Pass - ta - key 攻击，攻击者利用运行在受害者设备上的恶意软件，接管受 Google 同步通行密钥保护的账户，无需提升权限、解锁设备或用户交互；Silver Pass - ta - key 攻击，攻击者欺骗 Google 云端身份验证器，使其相信受害者已通过生物特征解锁设备，从而在身份验证期间无需使用受害者设备即可完全接管账户；Golden Pass - ta - key 攻击，攻击者可以提取所有同步的通行密钥，并将其以可共享或在凭证黑市上出售的形式获取。这些攻击表明，即使提供商在云端身份验证器中添加了硬件保护措施来保障凭证安全，恶意软件仍可利用同步通行密钥的漏洞。

免责声明：本研究进行了负责任且合乎道德的安全分析，已负责任地披露了所有发现的漏洞。云端身份验证器模型被多个浏览器和平台的各种通行密钥提供商所采用，然而，本研究主要关注 Windows 系统上 Chrome 浏览器中的 Google 密码管理器，特别是配备可信平台模块（TPM）的设备。所有介绍的攻击都基于受害者设备在初始阶段已存在恶意软件的情况。

零阶段侦察

在尝试任何攻击之前，攻击者需要了解受害者账户中通行密钥的使用情况。在受感染的端点上，获取这些信息并不困难。Chrome 在同步过程中会本地存储同步通行密钥数据。在 Windows 系统上，Chrome 将这些数据以 proto 编码的 WebauthnCredentialSpecifics 记录形式存储在其同步数据库中，这些记录代表同步的 WebAuthn 凭证。访问这些记录无需提升权限。通过这些记录，攻击者可以确定受害者在哪些服务中使用了通行密钥，以及相关的用户名、凭证标识符和加密的私钥。

在确定受害者使用通行密钥的服务后，攻击者可以尝试以受害者的身份进行身份验证。攻击者面临的主要挑战是绕过用于签署身份验证挑战的私钥保护。该私钥由主密钥保护，虽然加密版本的主密钥存储在每个客户端设备上，但只有云端身份验证器能够解密它。尽管有这些安全措施，该架构仍存在被利用的漏洞。以下部分将详细介绍攻击者可能利用系统机制、以受害者身份进行身份验证并攻破通行密钥保护账户的方法。

设备身份模拟：Pass - Ta - Key 攻击

介绍的第一种攻击是最直接的方法，攻击者通过模拟 Google 密码管理器和 Chrome 在正常身份验证过程中的行为，接管受通行密钥保护的账户。在正常流程中，Chrome 会使用设备的硬件支持密钥对发送给云端身份验证器的请求进行签名。与需要用户交互和设备解锁的正常用户流程不同，这种攻击展示了恶意软件如何在无需用户同意、生物特征识别、设备解锁或提升权限的情况下，静默获取所需的签名。

为了理解这一点，需要关注 Chrome 的设备身份密钥，该密钥向云端身份验证器证明客户端设备的所有权。生成所需的断言涉及使用设备的一个硬件支持密钥对发送给云端身份验证器的数据进行签名，这个密钥可以是身份密钥或用户验证密钥（UV 密钥）。虽然这两个密钥都与硬件绑定，但访问方式不同。对于身份密钥，Chrome 会创造条件，使其能够在以普通用户身份运行且不提升权限、不触发设备解锁保护机制的情况下请求签名。

在 Windows 系统上，Chrome 调用相关函数时不指定密钥名称，使 TPM 支持的密钥成为临时密钥，防止其持久化到磁盘。Chrome 不将私钥存储在 TPM 中，而是调用相关函数将密钥导出为 NCRYPT_OPAQUE_KEY_BLOB，指示 TPM 使用 TPM 驻留密钥对私钥进行加密。生成的 blob 存储在 `passkey_enclave_state` 文件中，作为 `wrapped_identity_private_key`，以便在同一物理 TPM 上后续使用。

恶意软件可以从磁盘或 Chrome 内存中提取这个 `wrapped_identity_private_key`，然后使用标准的 Windows 密码学 API：下一代（CNG）API 在不提升权限的情况下调用加密操作，模仿 Chrome 的行为。

下面详细介绍完整的 Pass - ta - key 攻击流程，该流程允许在受害者设备上运行无特权恶意软件的远程攻击者以受害者的身份进行身份验证。攻击流程包括以下阶段：攻击者收集受害者的同步通行密钥记录后，选择目标账户并发起通行密钥登录；依赖方返回新的身份验证挑战；攻击者与 Google 云端身份验证器发起 WebSocket 握手；攻击者使用握手的哈希值与受害者的 TPM 进行交互，并使用提取的身份密钥对握手哈希和断言请求进行签名；攻击者向云端身份验证器发送包含身份密钥签名的断言请求；从云端身份验证器的角度看，该请求看起来像是来自可信设备的有效请求，因此它会生成有效的断言响应；该断言随后被转发给依赖方，完成身份验证，攻击者获得对受害者账户的完全控制权。

当依赖方不严格要求用户验证时，Pass - ta - key 攻击非常有效。许多依赖方将 WebAuthn 的 `userVerification` 参数配置为“首选”而非“必需”，以支持不同的设备和用户体验，这使得它们容易受到这种攻击。当依赖方明确要求用户验证时，人们通常期望云端身份验证器拒绝未使用通过 PIN 或生物特征验证的密钥签名的请求。然而，实际情况并非如此。无论请求是使用身份密钥还是 UV 密钥签名，云端身份验证器都会返回有效的断言，区别仅在于身份验证器数据中的一个比特，即用户验证（UV）标志。当使用 UV 密钥签名断言时，该标志设置为 1；当使用身份密钥签名时，该标志保持为 0。

虽然 Pass - ta - key 攻击生成的断言在密码学上与依赖方的公钥匹配，但测试表明，当需要用户验证时，攻击通常会失败，因为 UV 标志未设置。尽管在需要用户验证时，身份验证通常会被拒绝，但并非所有依赖方都会始终一致地执行此行为。在测试中，发现一些依赖方由于未正确验证 UV 标志而接受了身份验证，这使得攻击即使在没有用户验证的情况下也能成功。这种缺乏验证的情况实际上将身份验证过程简化为单一因素。攻击者只需攻破设备身份密钥，即使在需要 MFA 的情况下，也能够成功进行身份验证并接管账户。已将此问题报告给受影响的依赖方。

待攻击状态：Silver Pass - Ta - Key 攻击

当账户受到更强的身份验证要求保护时，攻击者还必须绕过用户验证。云端身份验证器要求使用 UV 密钥签名的消息来设置 UV 标志。客户端交互控制对该密钥的访问，因为操作系统通过与设备解锁相同的机制验证用户。如果不提升到系统权限或物理访问受害者设备，攻击者似乎无法获得这种访问权限。

攻击者可以通过以下机制绕过这一挑战：攻击者不直接绕过对 UV 密钥的访问，而是使云端身份验证器中已注册的现有密钥失效，并注册一个由其控制的新生成密钥；一旦攻击者控制的密钥注册成功，任何使用该密钥签名的消息都会被云端身份验证器接受，就好像用户已经成功解锁设备一样。

这种方法具有重要意义。它允许攻击者在无需人工交互的情况下，对受害者的所有账户进行全自动身份验证，即使在强制执行用户验证的情况下也是如此。此外，攻击者在身份验证期间不再需要实时访问受害者的设备。与之前的攻击不同，之前的攻击每次身份验证都需要受害者设备上的活动恶意软件，而 Silver 攻击提供了可重复使用的访问权限。这使得攻击者可以在自己的环境中访问受害者受通行密钥保护的账户，而无需受害者的设备在线或处于活动状态。最终，攻击者无需提升权限即可接管与受害者关联的所有通行密钥保护的账户。

为了实施此攻击，首要目标是使与目标设备关联的现有 UV 密钥失效。攻击者可以利用无特权的恶意软件，使用设备身份密钥对其控制的请求进行签名，并将其发送给云端身份验证器。攻击者可以代表受害者发出 `device/forget` 命令，更简单的方法是直接删除受害者的 `passkey_enclave_state` 文件，因为没有内置保护措施阻止其删除。无论采用哪种方法，下次用户尝试使用通行密钥时，Chrome 都将被迫重新注册设备。

在 Windows 系统上，设备注册只有在同一设备上第二次使用通行密钥后才会完成。在第一次使用时，Chrome 会在后台与云端身份验证器开始注册流程，同时提示用户输入 Google 密码管理器（GPM）恢复 PIN。如果 Chrome 在此时创建 UV 密钥，还会触发 Windows Hello 提示，要求用户再次使用生物特征或 PIN 进行身份验证。由于这两个步骤都可能涉及 PIN，在同一流程中连续显示可能会让用户感到困惑并导致错误。为避免这种情况，Chrome 会推迟 UV 密钥的创建。相反，设备最初会以 `uv_key_pending` 状态注册。在第一次交互期间，GPM 恢复 PIN 满足用户验证要求，实际的 UV 密钥只会在下次使用通行密钥时创建和注册，此时不再需要额外的提示。

在迫使受害者进入重新注册状态后，攻击者可以利用 `uv_key_pending` 条件。在自己的环境中，攻击者生成一个非对称密钥对，然后向云端身份验证器发送 `device/add_uv_key` 命令，并将其控制的公钥作为 UV 密钥提供。云端身份验证器不会验证新注册 UV 密钥的证明，以验证它们是否来自安全硬件。因此，攻击者控制的密钥会与合法的设备身份密钥一起存储。从这一点开始，攻击者可以使用伪造的 UV 密钥为与受害者关联的任何通行密钥请求签名，并获取设置了 UV 位的断言。这使得攻击者即使在强制执行和验证用户验证的情况下，也能访问高价值账户。

窃取主密钥：Golden Pass - Ta - Key 攻击

在这种攻击中，攻击者实际上获得了云端身份验证器的超级能力，即解密同步通行密钥的能力。这尤其具有影响力，因为它破坏了预期的保护机制。通行密钥的私钥由一个名为安全域密钥（SDS）的对称主密钥保护。这个主密钥无法直接访问，它以加密的 `wrapped_secret` 形式存储在设备上。只有云端身份验证器能够在其隔离环境中使用其设备特定密钥（`wrapping_key`）解密这个 `wrapped_secret`。

这种设计旨在即使客户端设备被攻破，也能保护同步通行密钥。正如 Google 在回应一份漏洞报告时指出的那样，云隔离身份验证器的主要功能是使窃取通行密钥私有数据变得困难，如果这些数据在本地可用，将成为恶意软件的明显目标。这种模型的安全性最终取决于对 32 字节 SDS 的保护。如果攻击者能够获取 SDS，他们实际上就获得了解密该账户所有同步通行密钥的能力。这使得他们能够以完全验证的用户身份进行身份验证，并接管受害者依赖通行密钥的所有服务。

这个密钥即使在设备丢失或账户恢复期间，也不应暴露给客户端设备。然而，意外地发现，在与云端身份验证器注册时，只需打开 `chrome://device - log/FIDO`，SDS 就会出现在 Chrome 的日志中。在当前的 Chrome 实现中，每个加入或重新加入账户安全域的设备都会从恢复密钥存储中检索 SDS。云端身份验证器包含一种机制，允许 Chrome 促进恢复流程，使密钥无法在客户端设备上解密，但这种机制并未被使用。相反，Chrome 以可访问的形式恢复了 SDS。一种可能的解释是需要在不同平台上标准化设备加入和恢复流程。与桌面环境不同，iOS 和 Android 上的 Google 密码管理器不依赖云端身份验证器，必须获取主密钥才能解密同步通行密钥。因此，Chrome 似乎遵循了相同的恢复模型，尽管云端身份验证器可以实现更隔离的方法。

尽管 Google 在报告后从 Chrome 的日志输出中移除了这个密钥，但 SDS 仍然会发送到客户端，并在 Chrome 的进程内存中保持可访问状态。如果攻击者迫使受害者重新与云端身份验证器注册，并知道要查找的模式，他们就可以直接从内存中提取 SDS。

Golden Pass - ta - key 攻击通过以下步骤实现完全账户接管：攻击者使用与 Silver Pass - ta - key 攻击相同的机制，迫使 Chrome 触发全新的注册流程；攻击者监控系统，以检测 `passkey_enclave_state` 文件的重新创建或修改；一旦该文件被重新创建或修改，攻击者转储 Chrome 的进程内存，并提取暂时以明文形式存在的 SDS；攻击者从 Chrome 的同步数据库中读取 `WebauthnCredentialSpecifics` 记录；攻击者使用提取的 SDS 解密每个记录中的加密字段，并恢复相应的通行密钥私钥；攻击者使用恢复的私钥签署依赖方的挑战，并成功以受害者的身份进行身份验证。

Golden Pass - ta - key 攻击的影响更为广泛。除了攻击者可以在自己的环境中重复使用访问权限之外，SDS 还允许攻击者解密所有现有通行密钥以及为该账户创建的任何未来通行密钥。虽然 Silver 攻击可以通过注销或重新注册设备来缓解，但 Golden 攻击具有很强的持久性。即使检测到攻击，补救措施也很有限。在 Google 的当前实现中，无法轮换或撤销 SDS，这意味着所有当前和未来的同步通行密钥仍然由同一个主密钥保护。

缓解措施

强制严格的用户验证（UV）验证：依赖方应要求 `userVerification = required`，并在所有身份验证响应中验证 UV 标志。未能执行此检查可能会将身份验证简化为单一因素。

验证设备密钥注册和证明：凭证管理器应验证新注册设备密钥（包括 UV 密钥和身份密钥）的来源和证明。在未进行验证的情况下接受任意密钥，会允许未经授权的密钥注册，并绕过用户验证要求。

强化恢复和设备重新注册流程：凭证管理器的恢复 PIN 提示通常与注册或账户恢复相关，而非常规的通行密钥身份验证。在正常使用通行密钥期间出现意外或重复的提示，可能表明重新触发了注册或恢复流程，这可能是由于钓鱼攻击或对通行密钥状态的本地篡改所致。这些流程对安全至关重要，因为恢复操作可以重新建立设备信任并恢复对同步凭证的访问。监控代理应检测并限制不必要的注册和恢复流程重新触发，特别是在本地通行密钥状态文件被删除或修改之后。在重新建立设备信任或恢复同步凭证之前，应进行额外的验证。

防止客户端暴露敏感密钥材料：敏感材料（如主密钥）不应暴露给客户端，包括通过内存或日志。相反，凭证管理器应采用在代表客户端执行加密操作的同时，不将底层密钥材料传输到客户端环境的设计。

限制对本地通行密钥数据的访问：对与通行密钥相关的存储（如 Chrome 的同步数据库和本地状态文件，如 `passkey_enclave_state`）的访问应仅限于浏览器进程，并通过平台访问控制进行保护。这可以减少从受攻击的端点枚举凭证、操纵注册状态或访问设备绑定密钥材料的可能性。

改进对异常通行密钥使用的检测：WebAuthn 定义了一个签名计数器机制，旨在帮助依赖方检测克隆或意外重复使用的凭证。在同步通行密钥系统中，身份验证断言通常包含一个恒定的 `signCount` 值。因此，依赖方和凭证提供商对同步凭证的未授权使用（包括从意外环境中提取或重复使用通行密钥的情况）的可见性有限。集中协调身份验证操作的凭证管理器应考虑实施协调签名计数器机制，以解决同步和多设备一致性挑战。这种机制可以提高对意外凭证使用或跨环境重复使用通行密钥的可见性和检测能力。

结论

通行密钥是身份验证安全领域的重要进步。通过消除共享密钥，它们减少了历史上导致广泛账户泄露的各类攻击。那么，未来在通行密钥的广泛应用中，还会出现哪些新的攻击形式和应对策略呢？