森 秀樹

Googleパスワードマネージャーの同期パスキーを暗号化する鍵「SDS」が、修正後もChromeのメモリーに現れる仕組みを研究者が解説。再登録リクエストなどの組み立て時に平文となる鍵を抜き取り、暗号化済みのパスキーデータと組み合わせて秘密鍵を復号する手法です。一般ユーザー権限のマルウェアが端末で既に動くことが前提で、今回の解説は取得用の実証コードや平文を含むバッファーの寿命も提示。ログへの平文出力の修正と、リクエスト処理中に鍵がメモリー上で平文になる問題を区別しており、現行の「Pass-ta-key」原報告も後者に言及しています。 【要点の整理】 ・2026年8月、Palo Alto NetworksのUnit 42が3類型の攻撃「Pass-ta-key」を公表。最上位の「Golden」型は32バイトの鍵SDSを奪う手口で、現行の原報告にもログ修正後のメモリー取得を説明。10月18日付の今回のブログは、リクエストのデータ構造や平文を含むバッファーの寿命を詳しく調べ、実証コードも示した解析 ・今回のブログによると、SDSはかつて再登録時にChromeのログへ平文で出力され、メモリーにも残存。報告2件を受けGoogleが該当項目を伏せて修正 ・今回の解析では、再登録や直後のパスキー利用・作成のリクエストにSDSが平文で入り、SDSを含むCBOR（バイナリーのデータ形式）バッファーの寿命は計測例で125〜203ミリ秒。鍵を使うには平文が要るため、端末側でリクエストを組み立てる限り避けられない構造との研究者の見方 ・マルウェアが登録状態ファイル（passkey_enclave_state）を消して再登録を発生させ、利用者がパスキーを使うか作る際にSDSを抜き取る流れ。暗号化済みのパスキーデータも管理者権限なしで取得でき、SDSは現行実装には失効させる機能がないとの研究者の説明 ・検証はTPM搭載Windows機で、ChromeのStable・Betaチャンネルのバージョン156、Dev・Canaryチャンネルのバージョン158で再現したと研究者は説明。設計上の欠陥のためすべてのバージョンに影響との主張 ・SDSによる秘密鍵の復号や偽造した認証応答でのアカウント乗っ取りは、研究者が公開済みの第2部で解説・実証 ・研究者によると、Googleはマルウェアが既に動く端末への攻撃を脅威モデルの対象外とする立場。ログへの平文出力に関する1件目の報告にはCVE-2025-12910を付与し、2件目は付けず。今回具体化された手法への対応や実際の悪用はブログで言及なし ・Unit 42は8月の報告で、登録状態ファイルの削除・変更後の不要な再登録の検知・制限を推奨 詳細は以下を参照： 0rcruxe.github.io/posts/pass… unit42.paloaltonetworks.com/… 0rcruxe.github.io/posts/pass… (※可能な範囲でファクトチェックは実施済なものの、元記事の精度依存や速報・要約の性質上漏れもありうるため、正確な情報は一次情報を直接参照のこと)