「Entra OAuth」を悪用して楽しむと同時に、内部のMicrosoftアプリケーションへのアクセスを得る

289日前原文(research.eye.security)

概要

Microsoftの 内部サービス22件以上 に不正アクセスできた経緯と脆弱性の内容
Entra IDのマルチテナントアプリ 設定ミスに起因するリスクの解説
実際にアクセスできた 機密データやシステム の具体例
攻撃面の調査方法 と再現性、他のサービスも同様に脆弱な可能性
対策方法 とPowerShellによる脆弱性チェックの案内

Microsoft内部サービスへの不正アクセス体験記

aka.ms はMicrosoftの公式URL短縮サービス
単なる興味から https://aka.ms へアクセスし、ログイン画面を発見
一般ユーザーではログイン不可、Microsoftテナントアカウントが必要
eng.ms という新たなドメインを発見し、サブドメイン列挙を実施
rescue.eng.ms で自分のMicrosoft 365アカウントでログイン成功
表示された Engineering Hub はMicrosoftエンジニア向けポータル
内部手続きや製品グループの パスワード情報13,252件 にアクセス可能
すぐにアクセスを停止し、 Microsoft Security Response Centre (MSRC) に報告

Entra IDの認証・認可の仕組みと問題点

Entra ID でWebアプリを認証する場合、まずアプリ登録が必要
アプリは シングルテナント または マルチテナント として設定可能
マルチテナントアプリは personal Microsoft accounts も許可可能
認証エンドポイントURL：・シングルテナント： /tenantid または /domain ・マルチテナント： /common
Engineering Hubは マルチテナントアプリ として /common エンドポイントを利用
ユーザーが初回アクセス時に Consent（同意）画面 が表示され、同意後は自分のテナントで Service Principal が作成される
発行された アクセストークン は自分のテナント由来、 認可の主体が誤っている 状態
アプリロジックで トークンのissやtidを未検証 だったため、内部サービスへ不正アクセス可能

Microsoft攻撃面の調査方法

microsoft.com、azure.com、office.com、.msドメイン のサブドメインを列挙
102,672件 の（サブ）ドメインをリストアップし、うち 1,406件 がEntra ID認証を利用
各アプリの client_id からApplication IDを抽出し、Azure AD Graph APIでマルチテナントか判別
1,406件中176件 がマルチテナント設定
多くのアプリが /tenantidエンドポイント を利用していたが、これは本来シングルテナント用
認証時に /tenantid→/common へ書き換えることで、攻撃側テナントで認証可能
- Burp Suite等で マッチ＆リプレースルール を用い、認証エンドポイントを書き換え
- 一部アプリはユーザー割り当てやConsentが必要だが、自テナントなので容易に設定可能
必要に応じてPowerShellで Service Principalを直接作成 し、Consentフローをスキップ

実際にアクセスできた内部Microsoftアプリの例

Risk Register （内容はMicrosoftの要請で非公開）
Security Intelligence Platform （セキュリティインテリジェンスデータセット）
Media Creation Service （Windows等のメディア生成・ライセンスキーAPI・ビルド基盤へのRCE）
Engage ACE Hub
Responsible AI Ops Platform
Billing Account of Microsoft Internal (BAMI) portal
CPET webservice
Electronic Label Management
Bing ads SA Diagnostic Tool
Secure Devices Portal など多数

脆弱性の本質と組織的リスク

アプリ開発者とEntra登録担当の責任分担の曖昧さ が原因
アプリ開発者は認証周りの設定を十分に理解せず、登録担当も細部まで把握していないケースが多い
結果として 意図せずマルチテナント化 し、外部からアクセス可能に

検証・対策方法

マルチテナントアプリの利用は必要最小限に限定
アプリロジックで アクセストークンのissまたはtidクレームを必ず検証

PowerShellスクリプトで 自組織のマルチテナントアプリとリダイレクトURI を一覧化

例:
```
.\ListMultiTenantApplications.ps1
```

出力例:

DisplayName                  AppId                                   RedirectUris
-----------                  -----                                   ------------
Eye Security Secret App      8123db1e-3ae6-4068-abcd-f45acafee99c    https://somepath.eye.security
Eye Security Research Blog   74561b55-4eee-4db9-dead-c80ababee56d    https://research.eye.security/rest/oauth2-credential/callback

各アプリのリダイレクトURIが インターネット経由で到達可能か確認 し、 iss/tidチェック が実装されているか精査

報告・報奨・その後

2024年11月 に最初の4件をMSRCへ報告
Microsoft側が Azure Security Variant Hunting Team を立ち上げ、報告合戦に
2025年1月に18件中17件 で報告勝利、ほぼ全件が2ヶ月以内に修正
MSRC Q1リーダーボード第3位 を獲得
バグバウンティ報酬は…（YouTubeコメントの通り、期待外れ？）
最後に“Rewards Support Tool”アプリにアクセス、「自分にご褒美を…」で締め

まとめ・教訓

大規模環境では設定ミス1つで甚大なリスク が発生
アプリの認証・認可設計は 必ず多重で検証
自組織のEntra環境を定期的に監査 し、不要なマルチテナント設定や認可ミスを排除
バグハンティングは 知識と好奇心が成果に直結

Hackerたちの意見

こいつら、AIが書いたコードが30%もあるって自慢してるけど、Microsoftアカウントを強制して、OneDriveのバックアップをデフォルトにして、OpenAIにインフラを提供してるんだよね。OpenAIは削除されたチャットも保存しなきゃいけないし。LinkedInも持ってるし、これ、全然問題ないと思ってるのかな？もし、核兵器を持った外国の敵対的な政府が、MSアカウント、LinkedInプロフィール、OpenAIアカウントをメールや電話番号で繋げたら、どうなるんだろうね。国をズボン脱がせるために戦争を始める価値があるのかな？

└

正直なところ、ここにあるコードは、現代のAIが登場する前に書かれたものだと思うよ。恐竜が地球を歩いてた頃の話だね。

└

Fortune 10の企業で2回の面接を受けた経験から言うけど（そのうちの1つはMicrosoftね）、これはAIじゃないよ。何年も「動かすために頑張った」結果だし、ダクトテープで繋いでる感じ。これは「イントラネットに置いておけば安全だろう」っていう考えから始まって、誰かが「ゼロトラスト！」って言い出して、急に内部で認証してたものも新しい別の認証レイヤーを通ることになったんだ。完全に妥当な期待が重なり合って、まるでSig Sauer P320みたいに、思いもよらない時に自分の足を撃ってくるんだよね。

「クラウドに移行しろ」って言われたけど、インターネットよりも安全だって言ってたよね。自分のオペレーションチームに金を払うのはバカだって。俺、もう年寄りでバカだから、内部用のMicrosoftアプリが外からアクセスできる理由すら理解できないよ。

└

過去10年で、Googleが「ゼロトラスト」って呼び始めて、VPNを完全に廃止する流れが進んでるよね。問題は、一度VPNに入っちゃうと、重要なデータへのアクセスを防ぐのがすごく難しくなること。だから、今や「内部」のものも外部扱いになって、それぞれに許可のレイヤーが必要になってる。例えば、この記事のように、一つの脆弱性を使って別のサービスにアクセスするのが難しくなってるんだ。

└

それは多くの会社にとってまだ良いアドバイスだと思う。ジョーの屋根修理ビジネスは3つの州で一番かもしれないけど、彼らに自分たちのウェブサイト、メール、予約のためにサーバーを運営させたい？このフォーラムにいる人たちは自分のものを作れるし、自分のサーバーを運営できるけど、ほとんどの人はそうじゃないからね。

└

「クラウドに移行しろ」って言った。「お前のイントラネットよりも安全になる」って言った。「自分のOpsチームに金を払うのはバカだ」って言った。ブログ記事で浮かび上がった根本的な問題は、リソースサーバーで認可に取り組む開発者たちが、発行者やオーディエンス、サブジェクトなどの基本的なクレームをチェックしていないことだね。もしあなたの開発者がこの大きな見落としをしているなら、イントラネットが違いを生むとは本当に思う？聞いて、根本的な問題はクラウド対セルフホスティングじゃない。根本的な問題はセキュリティが難しいことで、一般的にはセキュリティインシデント以外にフィードバックループがないってこと。アプリをイントラネットやVPNに置いても、この問題を軽減することにはならないよ。

おお、マルチテナントアプリの認証がもたらす贈り物は尽きないね！(解雇された) MicrosoftのPMだけど、Wizの研究からのパッチに関わってたんだ。記事に一つ訂正したいことがあるんだけど、マルチテナントアプリを認証する際には「iss」か「tid」クレームをチェックするようにってガイダンスがあるんだ。実際に提供した推奨ガイダンスはもう少し複雑なんだよね。テナントだけを検証する場合、任意のサービスプリンシパルが認可されたアクセスを得る可能性がある。トークンを認可する際には、テナントの検証に加えて、常にサブジェクトも検証すべきだよ。これを行う一つの方法は、結合キー（例えば、tid+oid）を使ってトークンを検証するか、アクセスを認可する前にテナントとサブジェクトの両方をチェックすることだね。詳しくはここで確認できるよ。

└

すべてのトークンが偽造されていると仮定しよう。デフォルトで安全に。CPUを無駄にしても、すべてのフィールドを検証するべきだ。署名は検証されて初めて機能する。ついでに、アイデンティティデータベースに対しても検証しよう。ダブルチェック、トリプルチェックが必要ならやるべきだよ。これが俺が開発者に教えたこと。テナント、ユーザー、グループ、リソース - 通過させる前にすべてを検証しよう。

└

100%正しいけど、ほんとにこのエンジニアたちはガイダンスを読んだ方がいいよ。必要なことはかなり明確だからね。

彼、これで本当に報酬ゼロだったの？その人、Windowsが構築されてるビルドボックスに侵入する方法を見つけて、ライセンスキーを生成するために使われるプライベートキーを見つけたかもしれないし、RCEを取得した後に最新のWindows 11のソースコードを持ち出すこともできたかもしれない。報酬を発行する方法も見つけたのに、何ももらえなかったの？

└

もし彼らのルールがこれにバウンティを与えないって言うなら、そのバウンティプログラムは詐欺だよ。

OAuthは「より安全」とよく宣伝されるけど、実装が認証と認可を混同しちゃって、こういう問題が起きるんだよね。

└

俺は「auth」って言うだけ。どれを指してるかはお前が決めて。

Entraの馬鹿みたいな複雑さを無視すると、間違いに気づかないのがどれだけ簡単か（特にマイクロソフト内部では、サポートしなきゃいけない内部テナントと3P顧客テナントの区別がないから）本当に怖いよ。人々が認証トークンだけが必要なセキュリティ層だと思ってるのが。これらのサイトは公衆インターネットにさらされるべきじゃなかった（今はそうなってないけど）。ネットワークセキュリティは後回しにされがちだけど、実は最強の防御層なんだよね！

ああ、それがリリース直前にシングルテナントアプリ登録の統合が突然動かなくなった理由かも。みんなのために/commonエンドポイントを使ってたんだ。それは今は禁止されてる。

それが現実だよ。Entra IDはマルチテナントアプリのために特定のテナントをブラックリストやホワイトリストにすることを許可してないから、こんな問題が起こるんだ。さらに、MSALがブラウザ拡張みたいなものに対応してないから、人々はEntra IDとやり取りするために自分たちのセキュリティソリューションを実装しなきゃいけなくて、問題が多いのも当然だよ。

簡単なことだよ：Entra*（Azure ADとか呼ばれてるやつ）はAuthZには使わない方がいい。EntraのAuthNはまあまあだけど、AuthZは自分でやった方がいいよ。AuthZをやってみれば、避けるのは簡単だってわかるから。* なんで名前が変わったのかは全然わからないけど、Microsoftのマネージャーが「Renomino, ergo sum.」って plaque 持ってるのかな？

WindowsのビルドサーバーでのRCEに対して$0の報酬って、マジでおかしいよ。実際のゼロデイを見つけたわけじゃなくて、ただの設定の問題だったのは理解してるけど、それでもさ。バックドア付きのDLLでビルド環境を汚染できたら、どれだけ世界中に混乱を引き起こせるか想像してみてよ…

ハクソク