Microsoft は、Tenable の CEO から「まったく無責任」と非難された後、認証されていない攻撃者がクロステナント アプリケーションや Azure 顧客の機密データにアクセスできるようになる Power Platform Custom Connectors 機能のセキュリティ上の欠陥を修正しました。
この問題の根本原因は、Power Platform 内のコネクタによって起動された Azure Function ホストのアクセス制御手段が不適切であったことにあります。これらのコネクタは、HTTP トリガーを備えた Microsoft 管理の Azure 関数に統合されたカスタム C# コードを使用します。
顧客によるカスタム コネクタとの対話は通常、認証された API を介して行われますが、API エンドポイントにより、認証を強制することなく Azure Function へのリクエストが容易になります。
これにより、攻撃者がセキュリティで保護されていない Azure Function ホストを悪用し、OAuth クライアント ID とシークレットを傍受する機会が生まれました。
「これは情報漏洩だけの問題ではないことに注意してください。セキュリティで保護されていないファンクション ホストにアクセスして対話できること、およびカスタム コネクタ コードによって定義された動作をトリガーできることは、さらなる影響を与える可能性があります」と、この問題を発見したサイバーセキュリティ企業 Tenable は述べています。この欠陥を発見し、3 月 30 日に報告しました。
「ただし、サービスの性質上、その影響は個々のコネクタごとに異なり、徹底的なテストを行わない限り定量化することは困難です。」
Tenable CEO のアミット・ヨーラン氏は、「これがどれほどひどいことなのかを説明すると、私たちのチームはすぐに銀行の認証秘密を発見しました。彼らは問題の重大さと倫理を非常に懸念していたので、すぐにマイクロソフトに通知しました」と Tenable CEO のアミット・ヨーラン氏は付け加えた。
Tenable はまた、概念実証のエクスプロイト コードと、脆弱なコネクタのホスト名を見つけるために必要な手順と、セキュリティで保護されていない API エンドポイントと対話するための POST リクエストを作成する方法に関する情報を共有しました。
Tenable のレポートを調査しているときに、同社は当初、この問題を悪用したのはその研究者だけであることが判明しました。 7 月にさらなる分析を行った結果、Microsoft は、適切に軽減されていない「論理的な削除」状態にある Azure 関数がいくつかあると判断しました。
6 月 7 日にレドモンドによって展開された初期修正が Tenable によって不完全としてタグ付けされた後、Microsoft は 8 月 2 日に最終的にすべての顧客の問題を解決しました。
Microsoftは金曜日、「この問題はすべての顧客に対して完全に対処されており、顧客による修復措置は必要ない」と述べた。
レドモンドは、8 月 4 日から Microsoft 365 管理センターを通じて、影響を受けるすべての顧客に通知しました。
Microsoft は、情報漏えいの問題はすべての Azure 顧客に対して解決されたと言っていますが、Tenable は、この修正は新しくデプロイされた Power Apps および Power Automation カスタム コネクタにのみ適用されると考えています。
「Microsoft は、関数ホストとその HTTP トリガーにアクセスするために Azure ファンクション キーを要求することで、新しくデプロイされたコネクタの問題を修正しました」と Tenable 氏は言います。
「導入された修復の性質に関して追加の詳細が必要なお客様には、信頼できる回答を得るために Microsoft に問い合わせるつもりです。」
修正は世間からの批判を受けて初めて行われた
Microsoft は 5 か月の期間を経てこの欠陥に対処しましたが、その後 Tenable の CEO が初期対応に対して激しい批判を表明しました。ヨラン氏はマイクロソフトのアプローチを「極めて無責任」かつ「明らかな怠慢」であると非難した。
さらに悪いことに、9月にこの問題を修正するというレドモンド社の当初の約束は、セキュリティ脆弱性へのパッチ適用に関してほとんどのベンダーが通常遵守する予定の90日という期限から大幅に逸脱していた。
この遅延の延長により懸念がさらに高まり、製品内に影響を与えるセキュリティ問題に対する Microsoft の対応の適時性についてさらなる疑問が生じました。
「Microsoft は、複数の顧客のネットワークやサービスへの事実上の侵害につながる可能性のある問題を迅速に修正しましたか? もちろんそうではありません。部分的な修正を実装するのに 90 日以上かかりました。しかも、サービスに読み込まれた新しいアプリケーションのみでした。」と Yoran 氏は言います。言った。
「つまり、修正前にサービスを開始していた他のすべての組織と同様に、問題を報告してから 120 日以上が経過した今日の時点で、上で言及した銀行は依然として脆弱であることを意味します。
「そして、私たちが知る限り、彼らは自分たちがリスクにさらされているという認識をまだ持っていないため、補償制御やその他のリスク軽減措置について十分な情報に基づいた決定を下すことができません。」
Comments