「Pass-ta-key」攻撃、マルウェアがGoogle同期パスキーを乗っ取ることが可能に

セキュリティ研究者らは、すでに侵害されたWindowsデバイス上のマルウェアがGoogleパスワードマネージャーの同期パスキーを悪用し、アカウントの乗っ取り、ユーザー確認のバイパス、パスキー秘密鍵の抽出を可能にする3つの攻撃手法を発見しました。

パスキーは、ユーザーのデバイスに保存された暗号鍵を用いてオンラインアカウントにサインインする、パスワードを使わない認証方式です。

パスキーは推測されたり、再利用されたり、フィッシングによって容易に盗まれたりすることがないため、パスワードよりも安全とされています。また、PINや指紋認証・顔認証などの生体認証でユーザーが認証できるという利点もあります。

Googleのパスキー関連ドキュメントには、次のように記載されています。「パスワードとは異なり、パスキーは共有したり、コピーしたり、書き留めたり、誤って他人に渡してしまったりすることができません。これにより、フィッシングに対する耐性が高まります」。

しかし、Palo Alto NetworksのUnit 42による新たな報告書では、TPM（Trusted Platform Module）を搭載したWindowsデバイス上のChromeにおいて、Googleパスワードマネージャーを標的とする3つの新しい攻撃手法が示されています。これらはまとめて「Pass-ta-key」と呼ばれています。

これら3つの攻撃はいずれも、被害者のコンピューター上ですでにマルウェアが実行されていることを前提としており、パスキーで使用されている暗号技術そのものを破るものではありません。その代わりに、Chromeおよびgoogleのクラウド認証システムが、デバイスの信頼性・オンボーディング・復旧・同期された認証情報をどのように扱うかという点の弱点を突いています。

1つ目の手法は「Pass-ta-key」と名付けられており、権限を持たないマルウェアが信頼済みデバイスになりすまし、被害者のパスキーの一つに対して有効な認証応答を要求できるというものです。

このマルウェアは、ChromeのTPMに紐づいたデバイス識別鍵を悪用し、Googleのクラウド認証システムに送信するリクエストに署名します。この操作は、管理者権限、ユーザー操作、生体認証、デバイスのロック解除のいずれも必要とせずに実行可能です。

すると、Googleのクラウド認証システムは、このリクエストを被害者の信頼済みコンピューターからのものとして扱い、署名済みの認証応答（アサーションと呼ばれる）を返します。このアサーションを使えば、標的アカウントへのログインが可能になります。

ただし、このアサーションには「User Verified」フラグが含まれており、生体認証やPINによる確認が行われたかどうかを示します。サービス側がユーザー確認の成功を必須とし、かつ適切に検証している場合、この攻撃は失敗します。

GitHubに対してはこの攻撃は失敗しました。GitHubはUser Verifiedフラグを適切にチェックしていたためです。一方でUnit 42は、eBayに対しては攻撃が成功したと述べています。eBayもユーザー確認を必須としていましたが、確認が行われたかどうかを示すフラグを適切に検証していませんでした。

eBayは、研究者らの報告を受けてこの問題をすでに修正済みです。

2つ目の手法「Silver Pass-ta-key」は、さらに踏み込んだもので、攻撃者が自ら制御するユーザー確認鍵をGoogleのクラウド認証システムに登録できてしまうというものです。

まず攻撃者は、侵害済みデバイス上のマルウェアを使い、既存のユーザー確認鍵を無効化するか、パスキー状態を保持するローカルファイルを削除することで、Chromeに強制的に再登録処理を行わせます。

この再登録プロセス中、クラウド認証システムは新しい鍵が信頼済みハードウェア由来かどうかを検証していないため、攻撃者は自身が制御するユーザー確認鍵を登録できてしまいます。

その結果、Googleは攻撃者の鍵で署名されたリクエストを、被害者がPINや生体認証でデバイスのロックを解除した証拠として受け入れてしまいます。これにより攻撃者は、ユーザー確認を適切に必須化・検証しているアカウントにもアクセスできてしまいます。

不正な鍵が一度登録されてしまえば、攻撃者は被害者のコンピューターに改めてアクセスすることなく、別のシステムから認証を行えるようになります。

3つ目にして最も深刻な手法「Golden Pass-ta-key」は、被害者のGoogleパスワードマネージャーアカウントを通じて同期されるすべてのパスキーを暗号化するために使われるマスター鍵を、マルウェアが取得できてしまうというものです。

このマスター鍵は「セキュリティドメインシークレット」と呼ばれるもので、デバイスがアカウントへの登録あるいはアクセス復旧を行う際に、一時的にChromeへ送信されます。

Unit 42は当初、Chromeが内部のFIDOログを通じてこのシークレットを平文で露出させていることを発見しました。研究者らの報告を受けてGoogleはログからこのシークレットを削除しましたが、Unit 42によれば、シークレット自体は依然としてChromeに送信されており、ブラウザのプロセスメモリ上には一時的にアクセス可能な状態で残っているとのことです。

Unit 42は次のように説明しています。「今回の報告を受けてGoogleはこのシークレットをChromeのログ出力から削除しましたが、SDS（セキュリティドメインシークレット）は依然としてクライアントに送信されており、Chromeのプロセスメモリ内でアクセス可能な状態のままです」。

「攻撃者が被害者に強制的にクラウド認証システムへの再登録を行わせ、かつ探すべきパターンを把握していれば、メモリから直接SDSを抽出することができます」

攻撃者は、盗み出したマスター鍵を使って被害者の同期済みパスキーレコードを復号し、秘密鍵を復元できます。これらの秘密鍵は別のシステムに移すことができ、被害者になりすましてアカウントにサインインする際に使用可能です。

Unit 42は、盗まれたマスター鍵が今後アカウントに同期される新たなパスキーの復号にも使われる可能性があると警告しています。Googleの現行の実装では、この鍵をローテーションしたり無効化したりする手段が提供されていないとされており、そのため現在および将来同期されるパスキーはすべて同じシークレットによって保護され続けることになります。

研究者らは、パスキーは依然として従来のパスワードよりも大幅に安全であるとしつつも、今回の攻撃は、すでに侵害されたデバイス上で動作するマルウェアがもたらすリスクをパスキーが完全には排除できないことを示していると述べています。

Unit 42は、Webサイト側がユーザー確認を必須とし、かつ適切に検証することを推奨しています。また、認証情報管理システムについても、新規登録されるデバイス鍵を検証すること、復旧処理やデバイス再登録プロセスを堅牢化すること、そしてマスター鍵がブラウザのメモリ上でアクセス可能な状態にならないようにすることを求めています。

研究者らは、Googleパスワードマネージャーに関する攻撃をGoogleに開示するとともに、eBayを含む影響を受けるサービスに対してもユーザー確認に関する関連の欠陥を報告した上で、今回の調査結果を公表しました。

BleepingComputerはUnit 42の調査結果についてコメントを求めるとともに、記載された攻撃がすでに完全に対処されているかどうかについてもGoogleに問い合わせましたが、本稿執筆時点で回答は得られていません。