サイバーセキュリティ防御側にとって年末の恒例行事としてすっかりおなじみになってしまったが、研究者らはMicrosoft Entra IDを標的とする新しい攻撃ベクターを発見した。正規のOAuth 2.0認証フローを悪用して、特権アクセス・トークンを収集するものだ。
PushSecurityが「ConsentFix」と名付けたこの手法は、ClickFixのソーシャルエンジニアリング手法を進化させたもので、Microsoftのファーストパーティ製アプリケーションにおける認可コードフローを悪用し、デバイス準拠チェックや条件付きアクセス（Conditional Access）ポリシーを回避できるようにする。
この攻撃手法は、Microsoft Azure CLIのようなネイティブのパブリックアプリケーションがユーザーを認証する仕組みを根本から覆す。
被害者が悪意あるWebサイトを訪れると、攻撃者は「Microsoft Azure CLI」クライアントアプリケーションと「Azure Resource Manager」リソースを対象とする正規のMicrosoft EntraログインURIを生成する。
これにより標準の OAuth 2.0認可コードフローが開始され、通常はアプリケーションがランダムな高番ポート（リプライURI）でリスナーを作成し、認証応答を受け取る。
正規のシナリオでは、認証に成功するとEntra IDは重要なパラメータ（code（認可コード）および任意のstateパラメータ）を付与してユーザーをlocalhostへリダイレクトする。
Azure CLIアプリケーションはこのリダイレクトを捕捉し、コードをベアラートークンに交換する。しかしConsentFix攻撃では、localhostで待ち受けるアプリケーションが存在しないためブラウザーエラーが発生する一方、URIには機微な認可コードが含まれたままとなる。攻撃者はドラッグ＆ドロップやコピー＆ペースト操作を通じて、ユーザーにそのコードを提供させるよう誘導する。
セキュリティ研究者のJohn Hammondは、初期公開から数日以内に改良版を実証し、手動のコピー＆ペースト要件を排除して、純粋なドラッグ＆ドロップによる抽出を可能にした。
入手後、攻撃者は自らのインフラからそのコードを交換し、アクセストークン、IDトークン、そして場合によってはリフレッシュトークンを取得する。これによりAzure Resource Managerやその他のクラウドリソースへ無制限にアクセスできる可能性がある。
異常相関による検知
フォレンジック分析により、Entra IDのサインインログに特徴的な痕跡が残ることが分かる。攻撃が成功するたびに2つのイベントが生成される。1つ目は被害者の認証を表す初回の対話型サインイン、2つ目はトークン交換時に攻撃者のインフラから行われる非対話型サインインである。
認可コードのUTIはベアラートークンのUTIと異なるため、相関メカニズムの可能性が断たれる一方で、SessionIdは両イベントで一貫して同一のままである。
効果的な検知には、同一のSessionId、ApplicationId、UserIdを共有し、かつ2つ目のイベントが1つ目からおよそ10分以内に発生しているイベント同士を関連付けることが必要となる。
この時間的しきい値が重要である。GitHub Codespacesのような正規の自動化シナリオでは数秒以内にコードが交換されるのに対し、ソーシャルエンジニアリング攻撃では人間の操作遅延による間隔が生じる。
さらに、正規のAzure CLI利用では両方のサインインが同一IPアドレスから発生するのに対し、攻撃では被害者と攻撃者インフラの間で地理的な分散が見られる。
初期報告はMicrosoft Azure CLI（アプリケーションID: 04b07795-8ddb-461a-bbee-02f9e1bf7b46）に焦点を当てていたが、この脆弱性はlocalhostへのリダイレクトを受け付ける多数の事前同意済みファーストパーティ製アプリケーションにも及ぶ。
高リスクの対象には、Microsoft Azure PowerShell、Visual Studio、Visual Studio Code、MS Teams PowerShell Cmdletsが含まれる。EntraScopes.comのセキュリティ研究者は、公開解決できない開発・テスト用URLを含め、影響を受けるアプリケーションの全範囲をカタログ化している。
緩和策
組織は、導入の複雑さと緩和効果のバランスを取る複数の防御オプションに直面している。
最も手間の少ないアプローチは、影響を受けるサービスプリンシパルに対して明示的なユーザー割り当てを必須にすることだ。攻撃対象となる範囲は限定できるが、正当なCLIユーザーを網羅的に特定する必要がある。
条件付きアクセスポリシーでCLIツールへのアクセスを完全にブロックし、許可された担当者を除外することも可能だが、そのためにはレポート専用モードでの綿密なベースライン分析が必要となる。
最も堅牢な防御は、Microsoft Entra IDのToken Protection機能を活用し、Windowsプラットフォーム上のWeb Account Manager（WAM）ブローカーを通じた所持証明（proof-of-possession）を要求することだ。これを強制すると、ブラウザーはコード交換に必要なセキュアチャネルを確立できず、ConsentFix攻撃を完全に無力化できる。
ただし、適用範囲は特定の Microsoft 365リソースに限られており、Azure管理シナリオについては、現行のAzure CLIおよびPowerShellのバージョンでクライアント側WAMが利用可能であるにもかかわらず、公式サポートはまだ保留となっている。
より広範な保護として、準拠ネットワークチェックを伴うGlobal Secure Accessにより、盗まれたリフレッシュトークンを用いた後続のトークン発行をブロックできるが、初回のコード交換自体を防ぐことはできない。
デバイス管理における鶏と卵の問題は、Intuneやその他の管理サービスに対する慎重な除外ポリシーを必要とする。
レッドチームがこれらの手法を急速に武器化し、脅威アクターがフィッシングキャンペーン向けに適応させる中、防御側は直ちにサインインパターンを監査して異常なSessionId相関を確認し、CLIアプリケーションに対するユーザー割り当て制御を実装し、Token Protectionの準備状況を評価しなければならない。
翻訳元: https://gbhackers.com/new-oauth-attack/
