Microsoft Power Pagesの設定不備とみられる問題により、13の組織にまたがる約2,700万件の記録が流出した可能性があることがわかりました。データ恐喝グループのExfilSquadが、被害者データとされる382.64GB分をトレント配信で公開したことで判明したものです。
GetDatabase Tools
公開された資料を調査した研究者らによると、証拠が示しているのはゼロデイ脆弱性の悪用やランサムウェアの展開、あるいは従来型のネットワーク侵入ではなく、外部から自由に閲覧できる状態になっていたMicrosoft Dataverseのテーブルだといいます。
今回の事案では、Fortra社のIntelligence and Research Experts(FIRE)の調査担当者が、流出したデータセットの構造がDataverseを基盤とするMicrosoft Dynamics 365のCRMおよびERP環境からのエクスポートデータに酷似していることを確認しました。
Microsoft Power Pagesは、Dataverseと連携した外部向けのWebポータルを組織が構築できるようにするサービスです。
本来は、市民向けサービスや顧客サポート、登録手続き、申請フォームといった正当な公開用ワークフローを支援するために設計されていますが、アクセス制御はテーブルの権限設定とWebロールの割り当てに依存しています。
有力な仮説として挙げられているのは、影響を受けたポータルで、公開読み取りアクセスを許可するDataverseのテーブル権限に「Anonymous Users」(匿名ユーザー)というWebロールが割り当てられていたというものです。
こうした権限設定が機密性の高いテーブルに適用されると、認証を受けていない訪問者でも、ポータルの公開APIレイヤーを通じてレコードを取得できてしまう可能性があります。
研究者らの報告によれば、ExfilSquadがこのデータにアクセスするにあたり、マルウェアやラテラルムーブメント、認証情報の窃取、あるいはソフトウェアの脆弱性の悪用が必要だったという証拠は見つかっていません。
この違いは運用上、重要な意味を持ちます。脆弱性のあるアプリケーションであればパッチ適用が必要ですが、設定に不備のあるポータルの場合は、アクセス制御の即時是正やデータ流出の影響評価、認証情報・アイデンティティに関するリスク対応が求められるからです。
今回のキャンペーンは、クラウドセキュリティにおいて繰り返し起きている現実を浮き彫りにしています。それは、正当なSaaS機能であっても、匿名アクセスの権限設定が過度に広範であれば、インターネット経由でアクセス可能なデータ流出経路になり得るという点です。
エンドポイント環境がクリーンであるからといって、公開向けポータルが設計上バックエンドのテーブルを外部に露出させているなら、データが保護されているとは限らない点に組織は注意すべきです。
Fortraの調査により、382.64GBのアーカイブは13の組織、約2,700万件の記録に関連付けられました。
報告されている被害者には政府機関や教育機関が含まれており、公に議論されているデータセットの中には、アトランタ市、英国教育省(UK Department for Education)、コロンビア特別区公立学校(District of Columbia Public Schools)といった組織が関わっているものもあります。
XM Cyberのセキュリティ研究者らは最近、Microsoft System Center Configuration Management(SCCM)に一連の脆弱性を発見しました。これらを連鎖させることでリモートコード実行が可能になるといいます。
Securityconsulting services
Microsoft Power Pagesの設定ミス
今回の影響は、一般的な連絡先情報にとどまりません。報告されているサンプルには、個人を特定できる情報やCRMレコード、サービス・サポートデータのほか、教育関連のデータセットには生徒の氏名、生年月日、固有の学生識別番号まで含まれていました。
こうした情報はスピアフィッシングの材料となるほか、なりすまし詐欺、アカウント復旧を悪用した攻撃、成りすまし、さらには従業員・学生・市民・顧客・取引先を標的とした後続攻撃にも利用されかねません。
ExfilSquadは7月下旬に活動が確認され始めたとされ、8月7日には被害者データを公然と公開しました。これにより、恐喝の脅しが実際に、広範なプライバシー侵害と詐欺リスクへと変わったことになります。
同グループの活動はまた、クラウドデータの露出が大規模な情報収集の対象になり得ることも示しています。ポータルが公開状態にあり、そのAPIがレコードを返す設定になっていれば、脅威アクターは内部ネットワークに侵入することなく情報収集を自動化できてしまうのです。
Power Pagesを運用しているセキュリティチームは、匿名アクセスを許可しているすべてのポータルを早急に見直し、テーブル権限が業務上必要最小限を超える読み取り権限を付与していないか確認する必要があります。
特に注意すべきは、連絡先、アカウント、リード、インシデント、注釈、商談、ケース記録、あるいは個人・財務・従業員・業務に関するデータを含むカスタムエンティティを保持するテーブルです。
管理者は、公開データへのアクセスが明確に必要とされていないテーブル権限からは、「Anonymous Users」ロールを削除すべきです。
匿名アクセスが必要な場合でも、権限は必要最小限の範囲に絞り込み、API対応テーブルではワイルドカードによるフィールド選択ではなく、明示的に必要なフィールドのみを公開するようにすべきです。
Microsoftもまた、一部のシステムテーブルについて匿名Web APIのワイルドカード設定を制限し、意図しない広範な情報開示のリスクを軽減しています。
実務的な検証手順として、防御側は自組織の外部到達可能なポータルに対し、未認証セッションからテストを行い、APIルートがレコード本体を返さないことを確認すべきです。
Dataverseのデータを含む応答が返ってくるケースが一件でもあれば、それは現に情報が露出している状態とみなし、過去のアクセス履歴を調査した上で、直ちに是正措置を講じる必要があります。
今回の事案は、アイデンティティと認可の設定が組織の攻撃対象領域の一部であることを改めて示すものです。
Power Pagesの展開において、たった一つの過度に寛容なWebロール割り当てが、顧客向けポータルをインターネット上の誰もが利用できる大量データ抽出用インターフェースに変えてしまう可能性があります。
[ライブウェビナー] Elastic&UnderDefenseと共に、小規模なセキュリティチームがAIの可視性とエージェント型対応を一つの運用モデルに統合する方法を学びましょう。-> 今すぐ登録
翻訳元: https://gbhackers.com/misconfigured-microsoft-power-pages/
