
Google 同步 passkey 爆三種攻擊,風險由中毒 Windows 電腦開始
Google 已移除明文記錄,但 SDS 記憶體風險仲未完全處理
Palo Alto Networks 旗下 Unit 42 公開咗三種針對 Google Password Manager 同步 passkey 嘅攻擊。最嚴重嗰招可以攞走保護整批 passkey 嘅主密鑰,再喺另一部機解開私人密鑰。聽落相當大鑊,不過範圍要講清楚:研究集中喺有 TPM、用 Chrome 同 Google Password Manager 嘅 Windows 電腦,而且惡意程式要預先入到部機。研究亦冇話呢批攻擊已經俾人實際濫用。
Passkey 嘅密碼學冇俾人破解
Passkey 平時由私人密鑰簽署登入要求,網站只保存相應公鑰,所以撞正釣魚網站或者網站資料庫外洩,都唔會好似密碼咁直接交出可重用憑證。Google Password Manager 再用端對端加密同步 passkey,方便用戶換機或者同一帳戶跨裝置使用。今次出事嘅位置,集中喺裝置身份、復原流程同同步密鑰點樣交畀 Chrome 處理。
呢個分別好重要。Passkey 仍然擋到大量釣魚、撞庫同密碼重用攻擊;中咗木馬嘅電腦,本身亦可能洩漏登入 session、文件同其他帳戶資料。不過 Unit 42 呢次證明,惡意程式有機會令本來難以搬走嘅同步 passkey 變成可重用憑證;就算離開受害者部電腦,攻擊者仍可能繼續使用,維持得耐過一般 session cookie。

圖片:Palo Alto Networks Unit 42
第一招:借受害者部機扮可信裝置
Chrome 會用 TPM 保護裝置身份 key,向 Google Cloud Authenticator 證明要求來自已登記裝置。Unit 42 發現,一般用戶權限嘅惡意程式可以讀取 Chrome 本機資料,再叫同一粒 TPM 代為簽署。攻擊者仍要即時借用受害者部機,但過程唔使提權、解鎖裝置或者等用戶確認,就可以取得有效嘅 passkey assertion。
呢招能否登入,仲要睇網站有冇嚴格檢查 User Verified(UV)旗標。Unit 42 測試期間,GitHub 會拒絕缺少 UV 嘅要求;eBay 當時即使要求 user verification,仍因驗證漏咗一截而接受登入,收到通報後已經修正。換句話講,網站點樣實作 WebAuthn,同 passkey 管理器本身一樣影響結果。

圖片:Palo Alto Networks Unit 42
第二招:換入攻擊者控制嘅驗證 key
Silver Pass-ta-key 攻擊會先令原有裝置登記失效,逼 Chrome 再跑一次 onboarding。研究指 Windows 版 Chrome 喺呢段流程會短暫將 UV key 標成 pending;Google Cloud Authenticator 又冇核實新 UV key 係咪真係由安全硬件產生,攻擊者於是可以登記自己控制嘅 key。之後攻擊者喺自己部機都可以產生帶 UV 旗標嘅登入要求,受害者部電腦唔使繼續上網。
呢種存取維持得耐過第一招,亦對付到嚴格檢查 UV 嘅服務。Unit 42 指,移除相關裝置登記再重新加入,可以處理 Silver 攻擊。不過如果用戶平時用 passkey,突然反覆見到 Google Password Manager recovery PIN 或重新登記提示,就唔應該當普通故障撳過算,因為本機狀態可能已俾人改動。
第三招:抽走保護全部 passkey 嘅 SDS
Golden Pass-ta-key 鎖定 Security Domain Secret(SDS)。呢條 32-byte 主密鑰用嚟解開帳戶內同步 passkey;攻擊者只要迫 Chrome 重新登記裝置,再喺 SDS 短暫載入 Chrome process 時讀取記憶體,就有機會解開本機同步資料庫內嘅私人密鑰。Unit 42 指,呢條 SDS 可處理帳戶已有同之後新增嘅同步 passkey,攻擊者亦可以將私人密鑰帶去其他環境使用。
研究人員最初仲喺 Chrome 裝置記錄見到明文 SDS。Google 收到通報後已移除呢項記錄輸出,堵住咗最直接嘅讀取方法;SDS 喺裝置加入或者重新加入期間仍會短暫出現喺 Chrome 記憶體。至於輪替或者撤銷 SDS,Unit 42 喺研究刊出時話 Google 仲未提供相關機制,公開官方資料亦未交代完整處理時間表。
用戶而家要做啲咩
繼續用 passkey 冇問題,但要將 Windows 裝置安全放返喺同一個風險模型入面。Chrome、Windows 同保安軟件要保持更新,來源不明嘅安裝檔、破解軟件同瀏覽器擴充功能都要避開。公司 IT 可以留意 Chrome passkey 狀態檔遭刪除、異常重新 onboarding,同瀏覽器 process 俾其他程式讀取記憶體等訊號。
如果懷疑電腦已經中招,應先停用嗰部機處理敏感登入,再用可信裝置檢查 Google 帳戶已登入裝置、移除陌生 session,同逐個檢查重要服務嘅 passkey 及復原方法。清走惡意程式或者重裝系統後,先重新建立憑證。高風險帳戶亦可以考慮用獨立硬件 security key,減少依賴今次研究針對嘅同步流程。
今次研究冇推翻 passkey 對付釣魚同密碼外洩嘅優勢,但提醒咗一點:同步越方便,裝置加入、復原同主密鑰管理就越值得仔細審視。Google 已經處理明文記錄,下一步要睇 SDS 記憶體暴露同輪替機制會點改。
參考來源
- iThome — 研究人員揭露Google同步通行密鑰攻擊,可竊取私密金鑰 — original report
- Unit 42:Pass the Passkey — A Novel Attack Surface in Passwordless Authentication — 三種攻擊、研究環境、先決條件、披露狀態同緩解建議嘅一手研究
- Google Security Blog:Security of Passkeys in the Google Password Manager — Google 對 passkey 端對端加密、硬件保護同帳戶復原設計嘅官方說明
- Google Issue Tracker:SDS 明文記錄漏洞通報 — Unit 42 向 Google 提交嘅 SDS 洩漏技術報告同修補追蹤
- Google Account Help:用 passkey 登入 — Google 對 passkey、裝置解鎖同帳戶安全行為嘅官方用戶說明
本文根據原文及公開資料整理;資料有出入時,以原文及官方資料為準。







