マルウェアは Pass-ta-key 攻撃で Google Passkeys を盗み出すことができます


Pass-ta-key 攻撃は、マルウェアが Google Password Manager を悪用し、Windows 上の Chrome を通じて保存されたパスキーを乗っ取ることを可能にします。この攻撃はパスキーの暗号化を破るものではなく、デバイス登録、復旧、同期、信頼チェックの弱点を悪用します。

Palo Alto Networks の Unit 42 は、Google Password Manager を通じて同期されるパスキーに影響する 3 つの攻撃を発見しました。研究者らはこれらの手法をまとめて Pass-ta-key と名付けました。

3 つの攻撃すべてで、マルウェアが被害者の Windows コンピューター上で既に実行されている必要があります。ただし、一部の手法は管理者権限やユーザーによる操作なしでも機能します。

マルウェアが信頼済み Windows デバイスになりすます

最初の Pass-ta-key の手法では、マルウェアが、Google によって既に信頼済みと見なされている Windows デバイスになりすますことが可能です。

マルウェアは Chrome の TPM に裏付けられたデバイス ID キーを悪用し、Google クラウド オーセンティケーターに対して有効な認証応答を要求します。このプロセスは、生体認証、PIN、ユーザー承認、あるいはコンピューターのロック解除さえもなしに行われる可能性があります。

その結果、Google が署名付きのパスキーアサーションを返し、攻撃者がそれを標的のアカウントにアクセスするために使用する可能性があります。

パスキーアサーションには、ユーザーが PIN または生体認証によるログインを承認したかどうかを示すユーザー検証フラグが含まれています。Web サイトがユーザー検証を要求し、そのフラグを正しく検証すれば、この攻撃を防止できます。

Silver Pass-ta-key では攻撃者が制御するキーを追加

Silver Pass-ta-key と呼ばれる 2 つ目の手法では、攻撃者が自分の検証キーを Google クラウド オーセンティケーターに登録できます。

マルウェアはまず Chrome の既存のパスキー状態を削除するか無効化し、ブラウザーにデバイス登録プロセスを再度実行させます。登録の際に、攻撃者は自分が制御する検証キーを送信します。

Unit 42 によると、Google のシステムはその置き換えられたキーが信頼できるハードウェアから生成されたかどうかを検証していませんでした。

Google が悪意のあるキーを受け入れると、攻撃者はそれを被害者が認証要求を承認した証拠として使用できるようになります。この手法は、PIN や生体認証を正しく要求するサービスも回避できます。

攻撃者は後日、別のデバイスから認証することも可能です。元の感染したコンピューターに継続的にアクセスする必要はもはやありません。

Golden Pass-ta-key ではパスキーのマスター シークレットが露出

最も深刻な手法である Golden Pass-ta-key は、Google Password Manager を通じて同期されるすべてのパスキーを暗号化するために使用されるセキュリティ ドメイン シークレットを標的とします。

Google はデバイス登録時またはアカウント復旧時に、このマスター シークレットを Chrome に一時的に提供します。Unit 42 は当初、このシークレットが Chrome の FIDO ログ内に平文で保存されているのを発見しました。

Google は研究者がこの問題を報告した後、それらのログからその値を削除しました。

しかし Unit 42 は、このシークレットが一時的に Chrome のプロセス メモリ内に依然として現れると述べています。マルウェアはデバイスの再登録をトリガーし、暗号化キーを求めてブラウザーのメモリを検索する可能性があります。

シークレットを抽出した後、攻撃者は同期されたパスキーのレコードを復号し、その秘密キーにアクセスできます。そしてそれらのキーを別のデバイスに移し、被害者になりすますことができます。

盗まれたシークレットは、後日そのアカウントに追加されたパスキーも復号する可能性があります。研究者らは、Google の実装は現在、セキュリティ ドメイン シークレットをローテーションまたは失効させる方法を提供していないと報告しています。

つまり、攻撃者はキーを盗んだ後も、既存および将来の同期されたパスキーへのアクセスを保持できる可能性があります。

パスキーは依然としてデバイス セキュリティに依存する

Unit 42 は調査結果を公表する前に、Google Password Manager の脆弱性を Google に非公開で報告しました。Google は、説明されたすべての手法を完全に解決したかどうかを公に確認していません。

この調査は、パスキーを管理するデバイスがマルウェアに侵害された場合、パスキーが依然として脆弱になり得ることを示しています。Microsoft がユーザーにパスキーへの移行を推進しているにもかかわらず、攻撃者がブラウザーやオペレーティング システムを制御している場合、パスワードレス認証はアカウントを完全には保護できません。

Web サイトはユーザー検証を要求し、関連するパスキー フラグを検証すべきです。また、資格情報マネージャーは、新しく登録されたデバイス キーが信頼できるハードウェアから生成されたことを確認すべきです。

開発者は、デバイスの復旧および再登録プロセスを強化するとともに、機密の暗号化キーがブラウザーのメモリ内で利用可能な時間を制限すべきです。

ユーザーは引き続きセキュリティ更新プログラムをインストールし、疑わしいダウンロードを避け、コンピューターをマルウェアから保護する必要があります。Google はまた、より広範なアカウント セキュリティの取り組みの一環として、ディープフェイク対策を備えた自撮り動画アカウント復旧機能を導入しています。

公共ネットワークを使用する際は、デバイスのセキュリティが特に重要です。Microsoft は最近、侵害されたキャプティブ ポータルを通じて旅行者を狙った世界的なホテル Wi-Fi マルウェア キャンペーンを発見しました

BleepingComputer 経由

読者の皆様のご支援が Windows Report を支えています。当サイトのリンクを経由してご購入いただいた場合、当社が手数料を受け取ることがあります。 Tooltip Icon

情報開示ページをご覧いただき、Windows Report の編集チームをどのように支援できるかをご確認ください。 Read more

User forum

0 messages