FIDO認証の背景

FIDO（Fast Identity Online）は、パスワードレスの認証標準で、FIDO2およびWebAuthnに基づいています。以下はその基本的な仕組みです：

パスキーの仕組み

• ユーザーがパスキーを登録すると、デバイス（例：スマートフォン、PC、ハードウェアキー）上で公開鍵と秘密鍵のペアが生成されます。
• 公開鍵はサービス（例：Microsoft Entra ID）に送信され、秘密鍵はデバイスに安全に保存されます。
• ログイン時、サービスはランダムな暗号チャレンジを発行し、デバイスが秘密鍵で署名して応答。これによりユーザーの身元が検証されます。
• 秘密鍵は送信されないため、フィッシング攻撃者が傍受できる情報がありません。

フィッシング耐性

• 従来の多要素認証（MFA、例：SMSコードやアプリ通知）は、攻撃者が中間者（AiTM）攻撃でリアルタイムにデータを中継し、認証情報を盗むことが可能です。
• FIDOは認証をデバイスとドメインに紐づけ、こうした中継攻撃を防ぎます。

Microsoft Entra IDでの実装

• Entra IDは、FIDOを利用したエンタープライズログイン（例：Windows Hello for Business）をサポート。
• ただし、すべてのブラウザがFIDOを完全にサポートしているわけではありません。例えば、Windows上のSafariは互換性がなく、この点が攻撃の鍵となります。

ダウングレード攻撃の仕組み：ステップごとの解説

この攻撃は、Evilginxという中間者攻撃フレームワークにカスタム「フィッシュレット」（フィッシング用テンプレート）を使用し、認証フローを操作します。以下に詳細な手順を説明します：

1. フィッシングリンクの配信:
   • 攻撃者は、メール、SMS、悪意のあるOAuth同意プロンプトなどを通じてフィッシングリンクを送信。
   • このリンクは、Evilginxが運営する偽装サイトに誘導します。
   • EvilginxはAiTMプロキシとして機能し、実際のMicrosoft Entra IDログインページにリクエストを転送し、応答を被害者に中継するため、ページは本物に見えます。
2. ユーザーエージェントの偽装でダウングレードを誘発:
   • Evilginxは、ブラウザのユーザーエージェント文字列を、FIDOをサポートしないブラウザ（例：Windows上のSafari、例：「Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36」をカスタマイズ）に偽装。
   • Microsoft Entra IDは、ブラウザのFIDO互換性をチェック（Microsoftの公式ドキュメント：詳細）。非対応のユーザーエージェントを検出すると、FIDO認証を無効化し、「このブラウザまたはOSはこのサインインをサポートしていません」といったエラーを返します。
   • これにより、代替の認証方法（フォールバック）が提示されます。これは、アカウントに設定されているリカバリー用の方法（例：FIDOデバイス紛失時用）です。
3. 被害者が弱い認証方法を選択・実行:
   • 被害者は、本物に見えるエラーを見て、代替方法を選択：
   • Microsoft Authenticatorアプリ（プッシュ通知またはコード）。
   • SMSワンタイムパスコード（OTP）。
   • メール認証。
   • ユーザーが認証を完了（例：プッシュ通知を承認、OTPを入力）。
   • AiTM攻撃のため、Evilginxはユーザー名/パスワード（入力された場合）やMFA応答をリアルタイムで傍受。
4. セッショントークンの盗難とハイジャック:
   • 認証後、Entra IDはセッションクッキー（例：アクセスのためのベアラートークン）を発行。
   • Evilginxはこのクッキーを中継時に取得。
   • 攻撃者は、ブラウザ拡張機能などを使ってこのクッキーを自身のブラウザにインポートし、追加の認証なしでアカウントにフルアクセス可能。データ窃取、メール送信、ネットワーク内でのさらなる攻撃が可能です。
5. 攻撃後の悪用:
   • ハイジャックしたセッションで、攻撃者は持続的なアクセス、データ抽出、またはさらなる攻撃を実施。
   • 被害者はログインが成功したように見えるため、すぐには気づかない可能性があります。

技術的ポイント

• Evilginxの役割：オープンソースのAiTMフレームワークで、TLS終端、クッキー取得、リクエストプロキシを処理。今回の攻撃用に、Entra ID向けのカスタムフィッシュレットが作成され、ユーザーエージェントを偽装（例：Luaスクリプトでヘッダー操作）。
• ユーザーエージェントの悪用：Entra IDの「セキュリティ対策の欠如」で、報告されたユーザーエージェントのみを信頼し、実際のブラウザがFIDOをサポートしていても無視。これを攻撃者が簡単に偽装可能。
• 攻撃範囲：FIDOを有効にしつつフォールバックが設定されたEntra IDユーザーが標的。FIDO自体の脆弱性ではなく、実装の隙を突く。過去にWindows Hello for Businessでも類似のダウングレードが報告。
• 検知の難しさ：Entra IDからは通常のログインに見える。ただし、異常なユーザーエージェントやIPの検知で、進んだ監視システムが警告を発する可能性。

影響と懸念点

この攻撃は、FIDOの「フィッシング耐性」の主張を実運用で損なうものです。パスワードレス認証の採用が増える中（特に企業）、攻撃者はこのような回避策にシフト。以下が主な懸念：

• 高価値ターゲットのリスク：AiTMでセッションを盗めば、機密データへのアクセスやネットワーク内での横展開が可能。
• 攻撃の普及性：Proofpointはこれを「新たな脅威」と呼び、現時点では高度な攻撃者に限られるが、Evilginxのようなツールで実行可能。
• 信頼性の低下：FIDOが「安全」と宣伝される中、こうしたバイパスが信頼を損なう。

対策と推奨事項

情報源では具体的な修正は未記載（新発見のため）ですが、以下に推奨される対策を提案します：

1. 厳格なポリシー適用:
   • Entra IDで、弱いフォールバック（例：SMS）を無効化し、FIDO専用を可能な限り強制。
   • 条件付きアクセスポリシーを使い、非対応ブラウザや疑わしいユーザーエージェントからのログインをブロック。
2. ユーザー教育:
   • ダウングレードのプロンプトを疑わしいと認識し、報告するよう教育。
   • 機密ログインには、サポートされたブラウザ（例：Chrome、Edge）を使用するよう指導。
3. 監視と検知:
   • 認証ダウングレード、異常なユーザーエージェント、AiTMの兆候をログで監視（例：Microsoft Defender for Identity）。
   • 異常なIPやユーザーエージェントを検知する設定を強化。
4. ブラウザの強化:
   • ユーザーエージェント偽装を防ぐブラウザポリシーを展開。
   • エンドポイント検知でEvilginxのようなプロキシを特定。
5. ベンダーの対応:
   • Microsoftが、偽装ユーザーエージェントを無視するパッチや検証を追加する可能性。公開後のアップデートを監視。
6. 包括的対策:
   • FIDOに加え、デバイスに紐づけたセッション、フィッシング耐性のMFA、ゼロトラストアクセスを組み合わせた多層防御を採用。

最新情報は、MicrosoftのセキュリティアドバイザリやProofpointのブログで確認してください。

🧠 要点まとめ：Microsoft Entra ID × FIDOダウングレード攻撃

🔓 攻撃の本質

• FIDO自体は安全：秘密鍵は送信されず、フィッシング耐性が高い。
• 問題はEntra IDの実装：FIDO非対応ブラウザを検出すると、弱い認証にフォールバックする仕様が悪用される。

🧪 攻撃の技術的流れ

⚠️ 攻撃の特徴と懸念

• FIDOの信頼性が損なわれる：技術的には安全でも、実装の隙で回避可能。
• 検知困難：ログ上は「正常なログイン」に見える。
• ProofpointによるPoC：実際の攻撃は未確認だが、再現性あり。

🛡️ 推奨される対策

✅ 技術的対策

• FIDO以外の認証手段（SMS等）を無効化。
• 条件付きアクセスポリシーで非対応ブラウザをブロック。
• ユーザーエージェント偽装の検知ロジック強化。

🧑‍🏫 運用面の対策

• ユーザー教育：「FIDOが使えない」という表示は攻撃の兆候。
• サポートブラウザ（Chrome, Edge）を標準化。

🔍 監視と検知

• Microsoft Defender for Identityなどで異常なIP・UAを監視。
• セッションハイジャックの兆候をリアルタイム検知。

📌 補足：FIDOの限界ではなく、Entra IDの設計ミス

この攻撃はFIDOの暗号設計を破るものではなく、「互換性チェック → フォールバック提示」というEntra IDの仕様を逆手に取ったものです。Proofpointはこの点を「missing security measure（欠落した対策）」と明言しています。

詳細はProofpointの公式ブログ「Don’t Phish-let Me Down」で確認できます。

🧠 Entra IDのUA判定ロジック：技術的構造

🔍 判定の仕組み

Microsoft Entra IDは、ログイン時にブラウザのUser-Agentヘッダーを解析し、FIDO2/WebAuthnの互換性を判断します。以下がその基本的な流れです：

1. UA文字列の受信:
   • クライアント（ブラウザ）がHTTPリクエストで送信するUser-Agentヘッダーを取得。
   • 例：Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/91.0.4472.124 Safari/537.36
2. 互換性リストとの照合:
   • Microsoftは内部的にFIDO2対応ブラウザのリストを保持。
   • UAがこのリストに一致しない場合、FIDO認証オプションを非表示にする。
3. フォールバック提示:
   • 非対応と判定された場合、「このブラウザではFIDO認証がサポートされていません」と表示。
   • 代替手段（SMS、OTP、Authenticatorなど）を提示。

⚠️ 脆弱性の根源

• UA判定は文字列ベースであり、簡単に偽装可能。
• EvilginxなどのAiTMツールは、UAを任意に変更できるため、FIDOを意図的に無効化可能。

📊 FIDO互換性マトリクス（Microsoft公式）

Microsoftは公式ドキュメントで、FIDO2/WebAuthnの互換性を以下のように分類しています：

※ UA判定はこの互換性マトリクスに基づいて行われるが、UA文字列の信頼性が低いため、セキュリティ的には不十分。

🛠️ 改善の方向性

Microsoftが今後対応すべき技術的課題は以下の通り：

• UAベースの判定から脱却:
  • 実際のブラウザ機能検出（Feature Detection）へ移行。
  • JavaScript APIでwindow.PublicKeyCredentialの存在を確認する方式など。
• TLSレベルでの検証強化:
  • 中間者攻撃を防ぐため、TLSピンニングや証明書検証の強化。
• 条件付きアクセスポリシーとの連携:
  • UA偽装が検出された場合、アクセス拒否または追加認証を要求。

🧠 条件付きアクセスポリシー × UA判定：連携の構造

🔍 ロジック概要

Microsoft Entra IDは、ログイン時のHTTPリクエストから以下の情報を取得・評価します：

• User-Agentヘッダー：ブラウザの種類・OS・バージョンを判定。
• IPアドレス：地理的ロケーションや信頼性評価に使用。
• デバイス状態：Intuneなどの管理状態、セキュリティパッチの有無。
• ユーザーリスクレベル：異常な行動履歴やログインパターンに基づく評価。

これらを条件付きアクセスポリシーのトリガーとして使用し、アクセス制御を動的に適用します。

🧪 UA判定との連携ポイント

UA判定は、FIDO互換性の判断だけでなく、条件付きアクセスポリシーの「ブラウザ制限」や「認証強度要求」に直接影響します。

🔐 条件付きアクセスポリシーの構成例

① ブラウザ制限ポリシー

条件:
  - アプリ: Microsoft 365
  - ユーザー: 全ユーザー
  - クライアントアプリ: ブラウザ
  - ユーザーエージェント: Safari on Windows（FIDO非対応）

制御:
  - アクセス拒否
  - または追加のMFA要求

② 認証強度ポリシー

条件:
  - ユーザー: 高リスクユーザー
  - クライアントアプリ: 任意
  - デバイス: 未管理

制御:
  - FIDO2またはWindows Hello for Businessのみ許可
  - SMSやOTPは拒否

⚠️ 攻撃対策としての活用

• EvilginxによるUA偽装の検知:
  • 条件付きアクセスポリシーで「非準拠UA」をブロック。
  • UA文字列の異常（例：Safari on Windows）をログで監視。
• FIDOダウングレードの防止:
  • 認証強度ポリシーで「FIDO以外は拒否」を設定。
  • フォールバック認証を無効化。
• ゼロトラストの実現:
  • UAだけでなく、IP、デバイス、ユーザーリスクを総合評価。
  • リアルタイムでアクセス制御を動的に適用。

📌 参考情報

• Microsoft公式：外部ユーザー向け認証強度ポリシー
• テクニケーション社：Entra IDと条件付きアクセスポリシーの活用解説

🧠 Entra IDのログ構造：3つの主要カテゴリ

Microsoft Entra IDでは、以下の3種類のログが取得可能です：

UA判定に関係するのは主に「サインインログ」です。

🔍 UA判定の監査方法：技術的ステップ

① Azure Portalでの確認

• Entra IDブレード →「監視」→「サインインログ」へアクセス。
• 各ログエントリに以下の情報が含まれる：
  • UserAgent：ブラウザ・OSの識別情報。
  • ClientAppUsed：アクセス元アプリ（例：Browser, Mobile）。
  • AuthenticationDetails：使用された認証方法（FIDO, OTPなど）。
  • Status：成功/失敗の結果。

② Log Analyticsとの連携（推奨）

• Entra IDの診断設定で、ログをLog Analyticsに送信。
• KQL（クエリ言語）で詳細分析が可能：

SigninLogs
| where UserAgent contains "Safari"
| where OperatingSystem startswith "Windows"
| project TimeGenerated, UserPrincipalName, UserAgent, AuthenticationDetails, Status

上記は「Windows上のSafari（FIDO非対応）」を偽装したログイン試行を抽出する例。

③ 異常検知の観点

• UAが互換性マトリクスに存在しない組み合わせ（例：Safari on Windows）は偽装の可能性。
• 条件付きアクセスポリシーと連携し、以下のようなアラートを設定可能：
  • UAが非準拠 → アクセス拒否。
  • 認証方法がFIDO以外 → 追加検証。

📌 監査ログの保持と活用

🔗 参考資料

• Microsoft公式：Entra IDの監査ログ構造と活用方法
• Qiita：Log AnalyticsによるEntraログ監査の実践ガイド

🧠 検出アルゴリズムの設計方針

🎯 目的

• UA文字列が互換性マトリクスに存在しない組み合わせ（例：Safari on Windows）であるかを検出。
• UA文字列が既知の偽装パターン（Evilginxなど）と一致するかを判定。
• UAとIP、TLS証明書、リクエストヘッダーの整合性チェックを行う。

🔍 検出ロジック：擬似コード形式

-- 互換性マトリクス（簡易版）
local valid_combinations = {
  ["Windows"] = {"Edge", "Chrome", "Firefox"},
  ["macOS"] = {"Safari", "Chrome", "Firefox"},
  ["iOS"] = {"Safari"},
  ["Android"] = {"Chrome"}
}

-- UA解析関数
function parse_user_agent(ua_string)
  local os, browser = nil, nil
  if ua_string:find("Windows") then os = "Windows" end
  if ua_string:find("Macintosh") then os = "macOS" end
  if ua_string:find("iPhone") or ua_string:find("iPad") then os = "iOS" end
  if ua_string:find("Android") then os = "Android" end

  if ua_string:find("Chrome") then browser = "Chrome" end
  if ua_string:find("Safari") and not ua_string:find("Chrome") then browser = "Safari" end
  if ua_string:find("Firefox") then browser = "Firefox" end
  if ua_string:find("Edg") then browser = "Edge" end

  return os, browser
end

-- 偽装判定関数
function is_suspicious_ua(ua_string)
  local os, browser = parse_user_agent(ua_string)
  if os == nil or browser == nil then return true end
  local valid_browsers = valid_combinations[os]
  for _, b in ipairs(valid_browsers) do
    if b == browser then return false end
  end
  return true
end

-- 使用例
local ua = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Safari/537.36"
if is_suspicious_ua(ua) then
  print("⚠️ Suspicious UA detected: possible spoofing or downgrade attack.")
else
  print("✅ UA appears valid.")
end

🛠️ 拡張ポイント

• IPアドレスとの整合性：UAがモバイルなのにIPが企業VPNなどの場合は疑わしい。
• TLS証明書の検証：EvilginxはTLS終端を行うため、証明書のCNやSANが正規と異なる。
• Referer/Originヘッダーの不一致：本物のログインページと異なる場合は偽装の可能性。

📌 実運用での活用

このLuaスクリプトは、以下のような環境で活用可能です：

• NGINXのaccess_by_luaディレクティブで実行し、リクエストをブロック。
• Entra IDの前段に配置したリバースプロキシで、偽装UAを検出・遮断。
• SIEM連携でログ解析し、異常なUAをアラート化。

補足

この攻撃は、FIDOの設計自体の問題ではなく、Microsoft Entra IDの実装における「見落とし」を悪用するものです。FIDOの普及に伴い、攻撃者は技術的限界を回避する手法を模索しており、企業は実装と運用の両方で注意を払う必要があります。