Windows Helloの鍵悪用によりMicrosoft Entra IDアカウントへの不正アクセスが可能に

セキュリティ研究者が、Windows Hello for Business(WHFB)に関わる手法を公表しました。この手法を使えば、Windowsのアクティブなユーザーセッションにアクセスできる攻撃者が、被害者のPIN、生体認証、パスワードを一切必要とせずにMicrosoft Entra IDサービスへ認証できてしまう可能性があります。

Mollema氏の調査では、Windows Hello認証の基盤となる暗号鍵を、侵害されたセッションから攻撃者が事実上「借用」できる仕組みが示されています。攻撃者はこの鍵を使ってクラウドトークンを取得したり、自身が管理するデバイスを登録したり、Entra IDテナント内での持続的なアクセスを維持したりすることが可能になります。

Windows Helloの鍵悪用

Windows Hello for Businessは、従来のパスワードの代わりに、通常はTrusted Platform Module(TPM)によって保護されたデバイス固有の暗号鍵を使用します。この設計は、秘密鍵のエクスポートや窃取を防ぐことを目的としています。

しかしMollema氏は、ログイン済みユーザーのセッション内で動作する低権限プロセスが、ネイティブのCryptography Next Generation(CNG)関数を用いてWindows Passport Key Storage Providerを呼び出せることを発見しました。これにより、Windows HelloのPINや生体認証を求められることなく、WHFBに紐づく鍵から署名を要求できてしまいます。

この手口は、ユーザーがセッションのロックを解除した後にWindowsが保持するキャッシュ済みの認証データ、いわゆる「チケット」に依存しているとみられます。その結果、マルウェアやインプラント、あるいはセッションレベルのアクセス権を持つその他のプロセスであれば、被害者がログインしたままの状態でこの鍵を悪用できる可能性があります。

Securedata storage

この技術の当初のやり口は、借用したWindows Hello鍵を使ってJWTアサーションに署名し、プライマリリフレッシュトークン(PRT)を要求するというものです。PRTはEntra IDのシングルサインオンにとって重要な要素であり、最長90日間有効で、更新も可能です。

これまで、この方法で利用可能なPRTを取得するには、攻撃者が別のEntra ID参加済み(または登録済み)デバイスを操作している必要がありました。攻撃者は自身のインフラを登録するために別のアカウントや適切なトークンへのアクセスが必要だったため、この要件が悪用の余地を制限していました。

Image

Mollema氏の新たな調査は、WHFB鍵をWebAuthn/FIDO2パスキーとして扱うことで、この障壁を大幅に下げてしまいます。攻撃者は被害者の鍵を使ってMicrosoft Entraが発行するWebAuthnチャレンジに署名し、別のシステムからフィッシング耐性のある認証フローを実行できます。

報告によれば、このWebAuthnチャレンジは特定のセッション、デバイス、ユーザー、テナントに紐づいていないため、攻撃者が管理するホスト上で取得し、被害者のアクティブなセッションを使って署名することが可能です。生成されたアサーションは、Entraトークンの取得や、あたかも被害者本人であるかのようなWebベースサービスへの認証に利用できてしまいます。

WebAuthn方式で取得したトークンには、デバイスIDクレームが含まれない場合があります。これは、準拠済みまたは管理対象のデバイス状態を要求する条件付きアクセスポリシーに対しては障害となり得ますが、一方で持続的なアクセスを確立する経路にもなり得ます。

攻撃者はこのトークンを使って、自身が管理する新しいEntraデバイスを登録する可能性があります。そこから、新たに登録したデバイス用のPRTを要求し、パスキーやWindows Hello鍵といった追加の認証情報を付け加えることもできます。

Image

WHFB認証は最新の多要素認証(MFA)として扱われるため、攻撃者は認証方式の登録を保護する各種制御を満たしてしまう可能性があります。これにより、アクティブなワークステーションセッションの一時的な侵害が、クラウドIDにおける持続的な足がかりへと変わりかねません。

組織は、Entraデバイス IDが関連付けられていないWindows Hello for Business認証を監視すべきです。以下のKQLクエリは、こうした異常な可能性のあるイベントを特定するのに役立ちます。

SigninLogs
| where AuthenticationDetails has '"authenticationMethod":"Windows Hello for Business"'
| where DeviceDetail.deviceId == ""

こうしたサインインは、プライベートブラウジングセッションや統合SSOに対応していないブラウザなど、正当な理由で発生することもありますが、それでも十分に稀なケースであるため調査に値します。特に、デバイス登録、PRTのアクティビティ、認証方式の変更が後に続く場合はなおさらです。

セキュリティチームはまた、予期しないユーザー主導のデバイス登録にも注意を払い、アクティブなユーザーセッションに対する堅牢なエンドポイント検知を徹底し、デバイス状態や認証方式の登録を規定する条件付きアクセスポリシーを見直す必要があります。

SecurityProducts & Services

新たなフィッシングやマルウェアが貴社を侵害する前に阻止しましょう。 世界15,000のSOCから届くライブインテリジェンスを統合

翻訳元: https://gbhackers.com/windows-hello-key-abuse/

ソース: gbhackers.com