Microsoft Dynamics 365 データ漏洩：FetchXMLの脆弱性とその影響

Dynamics 365とPower Apps Web APIにおける重大な脆弱性が機密企業データを露出

2024年初頭、メルボルン拠点のStratus Securityのサイバーセキュリティ研究者たちは、Microsoft Dynamics 365とPower Apps Web APIにおいて、数百万の機密ユーザーレコードを不正アクセスから守るための深刻な脆弱性を三つ発見しました。これらの重大な欠陥は、定期的な侵入テスト中に見つかり、Microsoftによって2024年5月に修正されましたが、攻撃者がアクセス制御を回避し、パスワードハッシュ、メールアドレス、金融データ、電話番号、その他の個人識別情報を取得できる可能性がありました。

これらの脆弱性は、エンタープライズ組織にとって現実的な脅威を浮き彫りにしています。高度なセキュリティフレームワークを持つプラットフォームでも、API実装に重大な弱点が潜むことがあるのです。本分析では、Stratus Securityが発見した三つの脆弱性、その悪用メカニズム、実世界への影響、そしてDynamics 365とPower Appsの環境を守るための重要な対策について詳述します。

脆弱性の現状理解

Microsoft Dynamics 365とPower Appsとは？

Microsoft Dynamics 365はMicrosoftの包括的なCRM/ERPソリューションであり、Power Appsは低コード/ノーコードのアプリケーション・ウェブサイト構築プラットフォームです。これらのアプリケーションがPower Pagesと通信する際、データは「Dataverse」に保存され、必要に応じてAPIを通じて細かなアクセス制御のもと公開されます。これらの脆弱性は、まさにこれらのアクセス制御メカニズムの弱点を突いたものでした。

発見の経緯

これらの脆弱性は、Microsoft Power Pages上でホストされているアプリのWebアプリケーションに対する侵入テスト中に最初に発見され、その後APIの機能を調査した結果、三つの異なるが関連性のある脆弱性が明らかになりました。これらは、どの組織でもセキュリティを脅かす可能性があります。

脆弱性 #1：OData Web APIのフィルターアクセス制御の欠陥

技術的概要

最初の脆弱性は、OData Web APIのフィルターに対するアクセス制御の不備に起因し、contactsテーブル内のフルネーム、電話番号、住所、金融情報、パスワードハッシュなどの機密データへの不正アクセスを許していました。Open Data Protocol（OData）は標準化されたRESTベースのデータアクセスを提供しますが、このケースではアクセス制限が不十分でした。

悪用の仕組み：ブール値に基づく文字抽出

この攻撃手法は、巧妙なブール値ベースの検索方法を用いて、攻撃者がパスワードハッシュを文字ごとに抽出できるものです。攻撃者は、次のようなクエリを連続して実行します：startswith(adx_identity_passwordhash, 'a')、startswith(adx_identity_passwordhash, 'aa')、startswith(adx_identity_passwordhash, 'ab')など、完全なハッシュ値が得られるまで続けます。

このブラインド式のブール値抽出は次のように動作します：

最初のクエリ：1文字の推測から開始
結果の検証：クエリが結果を返すかどうかを確認
反復的な改善：正の結果に基づき文字を追加
完全抽出：有効な文字がなくなるまで続行

この技術の魅力は、その信頼性と自動化の可能性にあります。スクリプトを用いれば、十分な時間をかけてパスワードデータベース全体を抽出可能です。

実世界への影響

パスワードハッシュの抽出は、以下の深刻なリスクを伴います：

認証情報の危殆化：弱いハッシュはレインボーテーブルやブルートフォースで解読される可能性
横展開：盗まれた認証情報を使った他システムへの不正アクセス
なりすまし：個人情報と合わせてのアイデンティティ詐欺
企業スパイ：不正アクセスによる競合情報の収集

脆弱性 #2：ODataのorderby句の悪用

技術的詳細

二つ目の脆弱性は、最初の脆弱性のパッチ検証中に発見され、OData Web APIのorderby句を利用して特定のデータベース列からデータを取得できるものでした。これは、最初の脆弱性よりも危険度が高く、直接データを返すため、大規模な悪用が容易になりました。

悪用の経路

最初の脆弱性では反復的な文字抽出が必要でしたが、このorderby句の脆弱性では、攻撃者は次のことが可能です：

特定の列（例：EMailAddress1）をターゲットにしたクエリの作成
降順でデータを取得し、重要なターゲットを優先
最小のクエリで完全なレコードを抽出
複数のテーブルや環境に攻撃を拡大

この脆弱性は2024年2月13日にMicrosoftに報告され、2月22日に確認され、広範な情報漏洩のために$20,000のクロステナントバウンティ賞金対象となりました。

データ露出のシナリオ

このorderbyの脆弱性により、以下の攻撃シナリオが可能になりました：

大量メール収集：フィッシングキャンペーン用のメールアドレス抽出
顧客データベースの窃盗：完全な顧客連絡先情報のダウンロード
競合情報収集：ビジネス連絡先や関係性のアクセス
標的型攻撃：高価値個人の特定とスピアフィッシング

脆弱性 #3：FetchXML APIのアクセス制御バイパス

FetchXML APIの理解

FetchXMLはMicrosoft Dynamics 365に固有のXMLベースのクエリ言語で、強力なデータ取得機能を提供します。柔軟で堅牢ですが、その実装には重大な欠陥があり、完全なアクセス制御のバイパスを可能にしていました。

重大な欠陥

FetchXML APIを利用する際、攻撃者は任意の列に対してorderbyクエリを作成でき、既存のアクセス制御を完全に回避できました。これには、orderbyが降順である必要はなく、攻撃の柔軟性が増しました。

この脆弱性は、次の点で最も多用途でした：

任意の列へのアクセス：アクセス制限に関係なくクエリ可能
柔軟な並び替え：特定の順序制約は不要
完全なバイパス：アクセス制御を完全に回避
容易な悪用：FetchXMLの基本的な理解だけで可能

攻撃の流れ

このFetchXMLの脆弱性は、前述のorderbyの脆弱性と類似しており、攻撃者は制限された列にアクセスするためにorderbyクエリを利用します。たった一つの公開された列があれば、これを悪用して未承認のデータにアクセス可能です。

攻撃の典型的な流れは次の通り：

偵察：ターゲットテーブルの公開列を特定
クエリ構築：制限された列をターゲットにしたFetchXMLクエリを作成
実行：FetchXML APIエンドポイントにクエリを送信
データ抽出：制限された列の完全なデータを取得
横展開：複数のテーブルや環境に繰り返し

公表と対策のタイムライン

責任ある公開プロセス

この脆弱性の公開は2023年12月2日に始まり、Stratus SecurityはMicrosoftに詳細なレポートとパスワードハッシュ抽出のデモGIF、PoCを提供しました。

タイムラインは以下の通りです：

2023年12月2日：最初の脆弱性をMicrosoftに報告 2024年2月3日：Microsoftが最初の脆弱性のパッチ展開を確認 2024年2月4日：パッチ適用により、フィルター技術が無効化され、無効な列参照時に同じ応答を返すように 2024年2月13日：二つ目の脆弱性をパッチ検証中に発見 2024年2月22日：二つ目の脆弱性をMicrosoftが確認 2024年初旬：二つ目の脆弱性を修正 2024年3月22日：三つ目の脆弱性を発見し、即座に報告 2024年5月：三つの脆弱性が完全に修正される

公表過程の課題

最初の公開後、約1ヶ月半にわたり、研究者とMicrosoft間でやり取りがあり、誤解も生じました。これは、脆弱性の公開がいかに複雑であるかを示しています。

また、これらの脆弱性は、ひとつ修正されると別の脆弱性が明らかになるという、深層防御の原則の重要性を浮き彫りにしています。

組織への影響とリスク評価

潜在的攻撃シナリオ

脆弱なDynamics 365とPower Appsを運用する組織は、複数の攻撃経路にさらされました：

シナリオ1：認証情報収集キャンペーン 攻撃者はパスワードハッシュとメールアドレスのリストを作成し、パスワードを解読したりダークウェブで販売したりします。

シナリオ2：標的型フィッシング 完全な連絡先データベース（メールアドレス、電話番号、組織関係）にアクセスできるため、高度なスピアフィッシングを仕掛けられます。

シナリオ3：企業スパイ 顧客データ、財務記録、ビジネス関係の体系的抽出による競合情報収集

シナリオ4：ランサムウェアの前段階 認証情報の侵害から横展開し、最終的にランサムウェアを展開

リスクのある業界

これらの脆弱性は、特に次の業界にとってリスクが高いです：

金融サービス：銀行、保険、投資企業の顧客データ
医療：病院や医療提供者の患者情報
小売：ECプラットフォームの顧客支払い情報
専門サービス：コンサル、法律事務所、会計事務所
政府：公共機関の市民データ

技術的深掘り：根本原因の理解

アクセス制御の失敗

これら三つの脆弱性の共通点は、API層でのアクセス制御検証の不備にあります。これにより、一つの列が公開されているだけで、他のすべての列にアクセスできてしまう設定ミスが多く見られました。

この設計の弱点は次の通りです：

列レベルのセキュリティがAPI境界で適切に適用されていない
クエリのフィルターや並び替えが認証チェックを回避
アクセス制御の決定が暗黙的に行われている
深層防御の原則が十分に実装されていない

APIセキュリティのアンチパターン

これらの脆弱性は、いくつかの一般的なAPIセキュリティのアンチパターンを示しています：

入力検証不足：APIクエリが適切にサニタイズまたは検証されていない

信頼境界の破壊：クライアント側リクエストをサーバー側で検証せずに信頼

情報漏洩：エラーメッセージや応答がデータベースのスキーマ情報を漏らす

権限昇格：一つの列へのアクセス権限が他の列まで拡大

緊急対策とベストプラクティス

即時修正のステップ

Microsoft Dynamics 365とPower Appsを利用する組織は、次の対策を直ちに行う必要があります：

1. パッチ適用状況の確認 2024年5月以降のバージョンにアップデート済みか確認

2. アクセス制御設定の見直し 敏感なテーブル（例：contacts）への不正クエリを制限し、RBACを適用して適切なアクセス権を設定

3. API権限の監査 定期的に権限を見直し、不要な権限を削除

4. 監視の強化 APIリクエストのレート制限と監視を導入し、列挙や不正アクセスを検知

長期的なセキュリティ強化策

パスワードのセキュリティ向上 bcryptやArgon2などのハッシュアルゴリズムを採用し、計算コストを増やす

クエリの検証とフィルタリング 不正アクセスを防ぐためにクエリ検証を徹底し、APIゲートウェイやミドルウェアで不審なクエリをブロック

列レベルのセキュリティ orderbyを用いた場合も含め、クエリ可能な列を制限し、パスワードハッシュやメールアドレスなどの機密データへのアクセスを制御

活動監視 APIの活動を監視・記録し、不審なパターンを検知、定期的な侵入テストと脆弱性診断を実施

エンタープライズセキュリティへの広範な影響

APIセキュリティの課題

これらの脆弱性は、現代のエンタープライズ環境においてAPIセキュリティの重要性を再認識させるものです。データ連携や自動化のためにAPIを公開するほど、攻撃対象は拡大します。

重要なポイントは：

深層防御：複数層のセキュリティコントロールが必要
明示的な検証：クライアント入力やアクセス制御を信頼しない
継続的評価：セキュリティテストを継続し、脅威の変化に対応
迅速な対応：パッチ適用を素早く行い、露出期間を短縮

サプライチェーンのセキュリティ

ベンダーのセキュリティ体制も信頼の対象です。今回の発見は、セキュリティの継続的な監視と改善の必要性を示しています。大規模な企業は特に、データの安全性に細心の注意を払う必要があります。

セキュリティアーキテクチャの推奨

Zero Trustの導入

Dynamics 365とPower Appsには、Zero Trustの原則を採用すべきです：

信頼しない、常に検証：すべてのリクエストを認証・認可 最小権限の原則：必要最小限の権限付与 侵害想定：侵害を前提とした設計 明示的な検証：多要素認証の利用

APIセキュリティの枠組み

包括的なAPIセキュリティコントロールを実装：

認証：多要素認証の徹底
認可：ポリシーベースのアクセス制御
暗号化：TLS 1.3による通信の保護
ログ記録：操作の監査証跡
レート制限：列挙やブルートフォース攻撃の防止
入力検証：すべてのユーザー入力の厳格なサニタイズ
出力エンコーディング：エラーや応答からの情報漏洩防止

組織の対応とガバナンス

インシデント対応計画

APIの脆弱性に対処するためのインシデント対応計画を策定：

検知フェーズ - 不審なAPIクエリパターンを監視 - 認証失敗をアラート - データ流出の兆候を追跡

封じ込めフェーズ - 脆弱なAPIエンドポイントを一時停止 - 不審なIPをブロック - 影響範囲の環境を隔離

根絶フェーズ - セキュリティパッチを即時適用 - アクセス制御を見直し修正 - 不正アクセスの資格情報を削除

復旧フェーズ - セキュリティ強化後のサービス再開 - セキュリティ対策の効果を検証 - 関係者に通知

教訓の記録 - インシデントの経緯と対応を記録 - 改善点を特定 - セキュリティポリシーと手順を更新

コンプライアンスと規制対応

これらの脆弱性は、規制遵守にも影響します：

GDPR：個人データ漏洩時の通知義務
HIPAA：医療情報の漏洩に関する違反
PCI DSS：決済情報の漏洩に対処
SOX：財務データの整合性確保

今後の展望と脅威の進化

新たな攻撃ベクトル

APIの重要性が増す中、攻撃手法も進化しています：

GraphQLの脆弱性：新興のクエリ言語の問題
マイクロサービス攻撃：サービス間通信の悪用
サーバーレスの脆弱性：Function-as-a-Serviceのセキュリティギャップ
AI/ML APIの悪用：機械学習モデルのエンドポイント攻撃

予防的なセキュリティ対策

組織は次の投資を推奨します：

APIセキュリティテスト：定期的な自動・手動の評価 脅威インテリジェンス：新たな脆弱性情報の監視 セキュリティ教育：開発者への安全なAPI設計の指導 継続的監視：リアルタイムの異常検知と対応

結論：教訓と今後の道筋

Microsoft Dynamics 365とPower Apps Web APIにおけるこれら三つの脆弱性は、成熟したエンタープライズプラットフォームであっても重大なセキュリティ欠陥を抱える可能性を示しています。ブール値に基づく文字抽出やFetchXMLのorderbyバイパスなど、攻撃者の創造性と粘り強さを証明しています。

組織にとっての重要なポイントは次の通りです：

脆弱性を想定：完璧なシステムはなく、侵害を前提に設計
多層防御：複数のセキュリティコントロールを導入
継続監視：早期発見で被害を最小化
迅速なパッチ適用：露出期間を短縮
定期的なテスト：積極的な評価で弱点を発見

Microsoftは、責任ある公開と迅速なパッチ展開を通じて、これらの脆弱性に対応しましたが、ベンダーだけに頼るのではなく、自組織のセキュリティ体制を強化する必要があります。APIの安全性は、今後ますます重要となるため、FetchXML APIの脆弱性は、強力な機能がリスクを伴うことを教えています。

Microsoft Dynamics 365とPower Appsを利用する組織は、直ちにパッチ適用状況を確認し、アクセス制御を見直し、監視を強化し、セキュリティ診断を実施して、これらの脆弱性から守る必要があります。予防のコストは、侵害対応や信用失墜のコストよりも低いのです。

サイバーセキュリティの脅威は日々進化しています。警戒心を持ち、積極的な防御と迅速な対応を続けることが、効果的なセキュリティ管理の要です。これらの脆弱性は修正されましたが、APIセキュリティ、アクセス制御、深層防御の教訓は今後も重要です。

キーワード：Microsoft Dynamics 365 脆弱性、FetchXML API セキュリティ、Power Apps Web API 攻撃、パスワードハッシュ抽出、OData セキュリティ欠陥、Dataverse アクセス制御、エンタープライズAPIセキュリティ、サイバー脆弱性 2024、CRM セキュリティリスク、Microsoft セキュリティパッチ