Pass-ta-key 攻擊：Windows 惡意軟件點樣劫走 Google Password Manager Passkey

重點係，呢三種攻擊都冇有直接破解 WebAuthn 或 FIDO2 的底層加密；佢哋針對的是 Chrome 雲端驗證器、裝置信任、裝置重新註冊，以及 Passkey 同步流程之間的實作漏洞 。

三種攻擊分別點樣運作？

1. Pass-ta-key：冒充受信任裝置

基本版 Pass-ta-key 會從電腦硬碟上的 passkey_enclave_state 檔案，攞走 Chrome 以 TPM 保護的裝置身分金鑰。惡意軟件之後利用正常的 Windows CNG（Cryptography API: Next Generation）API，重播及簽署由攻擊者控制的請求。

結果，攻擊者可以取得有效的 WebAuthn assertion（驗證回應），而受害者畫面上完全唔會彈出指紋或 PIN 碼提示。呢條攻擊路徑只對未有檢查驗證資料內 User Verified（UV，使用者已驗證）標記的網站有效 。

主要利用的問題：

• 雲端驗證器信任儲存在本機的裝置身分金鑰；
• 部分網站冇有喺伺服器一方強制檢查 UV 標記。

2. Silver Pass-ta-key：利用重新註冊窗口繞過 UV

Silver Pass-ta-key 會刪除或者令本機的 passkey_enclave_state 檔案失效，迫使 Chrome 重新進行裝置註冊（re-onboarding）。

喺重新註冊期間，Chrome 會短暫以延後流程建立使用者驗證金鑰。研究人員發現，攻擊者可以趁住呢個時間窗口，註冊自己控制的 UV 金鑰。由於 Google 雲端驗證器冇有驗證新金鑰的 attestation（證明資料），由呢把金鑰簽署的驗證回應仍然可以帶有 UV=1 標記。

換句話講，就算網站有強制要求使用者驗證，攻擊者仍然可能繞過檢查。而且，一旦攻擊者喺自己部電腦取得可重用的存取能力，受害者原本部 Windows 電腦之後甚至唔需要保持上線 。

主要利用的問題：

• Chrome 重新註冊裝置時，冇有驗證新 UV 金鑰的 attestation；
• 本機 enclave 狀態檔案可以被刪除，而且缺乏足夠保護。

3. Golden Pass-ta-key：攞走加密全部同步 Passkey 的主密鑰

Golden Pass-ta-key 係最嚴重的一條路徑。攻擊者同樣先觸發裝置重新註冊流程，然後傾出 Chrome 程序記憶體，嘗試攞取 Security Domain Secret（SDS，安全網域密鑰）。

SDS 係一把 32 bytes 的對稱式金鑰，用嚟加密受害者 Google 帳戶內所有同步 Passkey。只要攻擊者攞到 SDS，就可以解密現有的同步 Passkey 私密金鑰；之後新同步到帳戶的 Passkey，亦可能一樣被讀取。換句話講，風險唔再只係一次登入，而係可能影響所有由呢啲 Passkey 保護的服務 。

Unit 42 亦發現，Google 過去曾經將 SDS 以明文寫入 Chrome 的 chrome://device-log/FIDO 輸出；Google 喺獲通知後已經移除呢項明文記錄。不過，研究指出 Chrome 程序記憶體暴露 SDS 的問題仍然存在 。

主要利用的問題：

• SDS 喺裝置註冊流程期間，以明文形式存在於 Chrome 程序記憶體之中。

邊啲網站受影響？

基本版 Pass-ta-key 理論上會影響任何冇有正確驗證 UV 標記的 relying party（依賴方，即提供登入服務的網站或服務）。Unit 42 指出，eBay 曾經係其中一個冇有執行相關檢查的網站；eBay 其後已經修正問題 。

研究人員又表示，有「出乎意料地多」的網站喺註冊時要求 userVerification: "required"，但喺之後收到驗證回應時，並冇有真正檢查當中的 UV bit 。

SDS 被偷，最壞可以有幾大鑊？

SDS 可以視為 Google 帳戶內所有同步 Passkey 的主密鑰。若果攻擊者成功攞到，可能出現以下後果：

• 所有現有的同步 Passkey 私密金鑰都可以被解密；日後新同步的 Passkey 亦可能被讀取 。
• 攻擊者可以登入任何由相關 Passkey 保護的帳戶，包括 Gmail，而唔需要受害者再作任何操作 。
• 一旦 Gmail 被控制，攻擊者可以利用電郵重設其他服務的密碼，令影響範圍擴大至原本冇有直接使用該 Passkey 的帳戶 。
• SDS 暫時冇有內置輪換機制；Google 亦冇有提供讓用戶自行產生新 SDS 的方法 。

用戶可以點樣減低風險？

根據 Unit 42 的研究及相關報道，較實際的防範措施包括：

• 除同步 Passkey 外，至少註冊一把硬件安全金鑰，例如 YubiKey。裝置綁定的憑證唔會同步到雲端，亦唔會進入 Chrome 的 enclave 狀態，因此唔可以用同一方式從記憶體讀取 。
• 高風險用戶啟用 Google Advanced Protection Program，例如記者、高級行政人員、社運人士及系統管理員。計劃會要求使用安全金鑰或裝置綁定 Passkey，並加強帳戶復原流程 。
• 每月檢查一次 Google 帳戶的裝置清單，刪除任何唔認得的裝置或工作階段 。
• 將任何 infostealer（資訊竊取程式）感染，當成需要全面重設憑證的事件處理。 復原帳戶後，應重建受感染電腦，並喺乾淨裝置重新註冊所有 Passkey 。
• 網站及服務供應商必須喺伺服器端驗證 UV 標記，對敏感操作使用 userVerification: "required"，而唔係較寬鬆的 "preferred" 。

目前進展

截至 2026 年 8 月 3 日研究發表時，相關問題尚未獲分配 CVE 編號。Google 亦未有公開確認會否直接修正 Silver Pass-ta-key 或 Golden Pass-ta-key 兩條攻擊路徑 。

今次事件最值得留意的地方，唔係 Passkey 加密已經失效，而係「裝置一旦中招，端點本身就可能成為攻擊者的登入工具」。因此，Passkey 仍然要配合可靠的端點防護、硬件安全金鑰，以及受感染後的完整帳戶復原流程，先可以發揮應有的保護作用。