Microsoft内部アプリケーションへのアクセスを目的としたEntra OAuthの悪用
(research.eye.security)- 研究者は、Entra OAuthの同意および権限委譲プロセスを悪用し、Microsoftの内部アプリケーションへのアクセスが可能になることを確認した。
- この脆弱性は、社内システム保護に対する新たな脅威であり、外部ユーザーが内部サービスへアクセスする経路を確保できる可能性を示している。
- 根本的な原因は、基本的な同意メカニズムと権限設定の不備にある。
- 研究の結果、既存のセキュリティ制御だけではOAuth同意リクエストおよびアクセス制御に脆弱性があることが示された。
- 企業や組織は、OAuthの同意および権限管理の強化の必要性を確認した。
調査概要と背景
- Microsoft Entra OAuth は、ユーザーの同意に基づいて複数のアプリケーションが異なるサービスへのアクセス権限を取得する認証・認可フレームワークです。
- 研究者は、標的環境では通常内部からのみアクセス可能なMicrosoftアプリケーションが、特定の同意および権限委譲シナリオを悪用することで外部からもアクセスできることを発見した。
原因分析
- この脆弱性は、OAuth同意要求のプロセスを悪用して発生します。
- アプリケーションが適切に制限されていない場合、攻撃者はユーザーの同意を誘導し、社内リソーストークンを取得できます。
- デフォルトで提供される同意および権限付与メカニズムが十分に細分化されていないため、一部の社内サービスは外部向けに露出するリスクを負うことになります。
影響とリスク
- 悪意のあるユーザーがこの脆弱性を利用して、Microsoft社内システムおよびアプリケーションにアクセスできる可能性があります。
- アクセスが許可された場合、機密データの流出または内部機能の悪用のリスクが存在します。
対応と推奨
- 組織はOAuth管理体制を再評価し、すべての同意および権限割り当てプロセスを厳格に統制する必要があります。
- 最小権限の原則に基づき、同意されたリソースと権限範囲を明確に制限する必要があります。
- 定期的にOAuthアプリケーション監査と同意管理プロセスを確立し、管理を強化する必要があります。
1件のコメント
Hacker News コメント
Microsoft のドキュメントは本当に悪夢で、脆弱性があること自体がまったく驚きではない
最近 Entra ID で SSO ログインを構築したが、（幸い単一テナントだったので）アクセス トークンに正しいスコープと追加フィールド返却設定を合わせるまで、ほぼランダムに試行するしかなかった
スタートガイドを探そうとして検索すると、数多くのサブページにたどり着き、Microsoft 独特の難解な用語やほとんど役に立たないドキュメントリンクしか続かない
こうした結果はまったく驚くことではない
Entra の OAuth2 設定とドキュメントは完全にカオス
とても混乱していて、Microsoft 側でさえ正しく動作させられていないのは明らか
この問題に対する彼らの対応は「もっとドキュメントを足すこと」だが、既に存在するスパゲッティのようなドキュメントも読み込むのが難しい
数週間前にこの問題に遭遇した
公式ドキュメントでは、複数のリソース サーバーを対象にしたスコープとともに authorization code flow を実行できないと書かれている
しかし「openid $clientid/.default」をリクエストすると動作する
フローの最後で ID トークンとアクセス トークンを受け取るが、ID トークンには OIDC スコープが適用されているのが分かる
ただし、アクセス トークンを見るとスコープから「openid」が抜けている
実際に Microsoft Graph（UserInfo エンドポイントとしての役割）を呼び出せない
なぜそのような挙動になるのか、きちんと説明した資料を見つけられなかった
マルチテナント アプリの認可は、いまだに予期しない問題を生み続ける
私は Microsoft で Wiz の調査結果を反映したパッチを担当していた（退社した）PM だ
記事に修正提案を書いたら、マルチテナント アプリの認可時に「iss」または「tid」クレームだけを確認すればよいと案内されていた
実際の推奨はもう少し複雑
テナントだけを検証すると、どんなサービス プリンシパルでも認可済みアクセスを得られてしまう可能性がある
常にトークンについてテナントに加えて subject も検証する必要がある
例として tid+oid の組み合わせでトークンを検証するか、認可前にテナントと subject の両方を条件確認すべきだ
詳細はclaims validation 公式ドキュメントで確認できる
すべてのトークンは偽造されたものと仮定する方針を強調
デフォルトで常にセキュアに設計すべきだ
CPU が浪費されても、各フィールドはすべて検証すべきだ
署名は有効性検証があるからこそ意味がある
可能なら ID データベースとの照合検証を推奨する
テナント、ユーザー、グループ、リソース――許可前に必ず徹底的に検証するよう、開発者に教えてきた
100% 当たっている
事実、エンジニアは公式ガイドを必ず読まなければならない
関連ガイドはこちらで確認できる
「チェックすべき項目のガイド」が明確に整備されているかも気になる
本来これは Yes/No でシンプルに整理されるべきだと思う
「このグループのユーザーを、全員の個人ノートを読み取れるようにすべきか？」のようなチェックボックスをシステムに見たことがない
Entra の複雑さを除外しても、特に内部 Microsoft 側の多数のテナントと 3P 顧客向けテナントが区別なく混在しているため、ミスを見落としやすい
それ以上に恐ろしいのは「認証トークン」1 つでセキュリティを解決できると信じることだ
この種のサイトは本来インターネットに公開されるべきではなかった（現在は公開されていない）
ネットワークセキュリティは本当に後回しにされるが、最も効果的な防御手段である
防御は複数段階で行うことがカギ（defense-in-depth の概念）
クラウドに移れ、社内ネットワークより安全だ、社内運用チームは不要だと言ってきたけれど、 私はかなり昔で頭が固まっていて、内部 Microsoft 用アプリが外部からアクセスされること自体を理解できない
過去10年、Google で始まったと言われる「Zero Trust」の流れで VPN を完全に捨てる傾向がある
誰でも VPN に入るだけで重要データへのアクセスを阻止するのが非常に難しくなったからだ
そのため最近は「社内」サービスも外部へ公開し、各層ごとの権限管理（permissions）が必須になる
その結果、一度に複数サービスへ侵入するタイプの攻撃もずっと難しくなる
Zero Trust 概念の紹介
私の考えでは、当該アプリがパブリックネットワークに晒されていること（つまりイントラネットではないこと）が本当の問題ではない
本当の問題はこの種のアプリケーション（Entra ID）がマルチテナントである点だ
重要な認証情報が複数のテナント（悪意ある攻撃者を含む）と同一のデータベースに保存・共有されている
そのためマルチテナンシーの逸脱が頻発する
Entra ID にテナンシーチェック機能がいかに堅牢でも脆弱性は残る
たとえばブログで示されているように、2 つ以上のテナントにまたがるリクエスト（マルチテナント リクエスト）は基本的に認可が極めて難しく、ちょっとしたミスで全体リスクを作り得る
単一テナント アプリと比較すると、攻撃者は必ずそのテナント内ユーザーにならなければならないため、事前認証攻撃はずっと難しくなる
このように「クラウドに行け、社内より安全、運用チームはいらない」という主張が多くても
核心は、ブログで示される通り、リソース サーバー認可を実装する開発者がトークンの issuer、audience、subject といった基本クレームさえ確認していないことだ
このミスが繰り返されるならイントラネットにいても全く意味がない
結局、核心はクラウドかオンプレミスかではなく、セキュリティは本質的に難しく、実際に問題が起きるまで改善の循環が進まないという点である
イントラネットや VPN 網に置けば置くほど、このセキュリティ不備は消えない
「Defence in depth」（多層防御）という用語は今や流行が終わったのでは？
大半の会社では、オンプレでサーバー運用を自前で行うのがまだ有効な助言
3 つの州で一番の屋根修繕業者であっても、ウェブサイト、メール、予約システムまで全部任せたくはないだろう
このフォーラムの読者はサーバーの構築・運用が可能かもしれないが、それは「一般ユーザー」ではない
Windows ビルドサーバーで RCE 脆弱性発見後の報奨金が 0 ドルというのはありえない
実際、ゼロデイ脆弱性ではなく設定問題だけが見つかったとしても、もしバックドア DLL でビルド環境を汚染できるなら、世界規模の大惨事を引き起こしうる
このビルドツール管理 UI には慣れていないが（退職後に追加された可能性がある）、本当にリモートコード実行（RCE）が可能な UI だとは思わない
常に NuGet からパッケージを取得する必要があり、見た目上はいかなるパッケージやソースも指定できそうに見えるが、実際には内部 Microsoft NuGet フィードへ制限するホワイトリストがあった
NuGet パッケージの管理は、Windows エンジニアリングチームで非常に重視していた重要テーマだった
外部公開 NuGet パッケージの使用は全面禁止で、どうしても使う場合は再パッケージして内部ソースへアップロードしたものを使うことを強制していた
Microsoft だから、優秀な人材は多いにもかかわらず、最近のマスターキー流出、エンジニアが PR で GPT にコーディングを依頼した件、さらに CEO が「バックエンドエンジニアは消えた」と言ったことまで見て
あの会社は信頼できないと思う
もちろん多くの人は他の選択肢がないことを認める
それでも残るなら、それは無責任だ
dotnet/runtime の話かな？
私の考えは本当にシンプルだ
Entra（名前が Azure AD などに変わっても問題ない）は AuthZ（認可）用途としては使うべきではない
AuthN（認証）は問題ないが、認可は自前で実装すべきだ
AuthZ を自前で実施すれば、こうした問題は比較的簡単に回避できる
*- 名前がなぜ変えられたかは私にもわからない。Microsoft の管理者には「名前を変える、ゆえに存在する」というモットーの人がいるように思う
「Azure AD」という名前は、単に Azure 上で AD がホストされているという誤解を招く
実際にはそれ以上のものになっている
Entra による AuthZ 実装自体は問題ない
「このアプリにはユーザーの割り当てが必要」というボックスをチェックして直接割り当てればよい [1]
ただし、これは Entra が提供する唯一の AuthZ 機能だ
AuthZ を有効にしないなら、Entra が自動で認可管理をしてくれるだろうと期待するのは間違いだ
参考までに、単純な「許可/拒否」認可は、全ユーザーが同一権限を持つ非常にシンプルなアプリでのみ意味がある
通常の複雑なアプリではユーザーはさまざまなアクセスレベルを持つため、実際の認可（authorization）はアプリケーション内で実装する必要がある
[1] 管理ポータルでアプリ権限を割り当てる方法
こうなったのは、Entra ID のマルチテナント アプリで特定テナントのみをブラックリスト/ホワイトリストできないのが問題
さらに MSAL はブラウザ拡張のようなものでは動作しないため、結局ユーザーは Entra ID と通信するための追加セキュリティ対策を自前で実装することになる
だから様々な問題が続出するのは当然だ
「このアプリは次のテナントのみアクセス許可」といった機能があればよいのに、今は「自分のテナント」か「Azure 全体のテナント」しかない
私の回避策は「このテナント専用」にアプリを設定し、他テナントユーザーを自分のテナントに招待する方法だ
あるいは「すべてのテナントを許可」にして、実ユーザーはグループで管理して許可する
これは技術的な理由なのか、重要顧客が要求しないためなのか全くわからない
Azure は本当に混沌としている
Okta にも問題はあるが、少なくともドキュメントはずっとよく、価格は高くなる代わりに Azure サービスと混ぜず完全に分離して管理できる
その価値は十分だと思う