本ブログは、Potential Risk of Privilege Escalation in Azure AD Applications の抄訳版です。最新の情報は原文を参照してください。
概要
マイクロソフトは、Descope 社によって明らかになり、報告された Azure AD (以下、AAD) アプリケーションで使用される安全でない アンチパターン に対する緩和策を開発しました。アクセス トークンのメールクレームを認可に使用することで、特権の昇格につながる可能性があります。攻撃者は、アプリケーションに発行されるトークンに含まれるメールクレームを改ざんすることができます。さらに、アプリケーションがメールの検索にこのようなクレームを使用した場合、データ漏洩の脅威が存在します。
マイクロソフトは、メールクレームを認可目的に決して使用しないことを推奨します。アプリケーションがメールクレームを認可やプライマリユーザーの識別に使用した場合、アカウントや特権の昇格を狙った攻撃を受ける可能性があります。
開発者は、アプリケーションの認可ビジネスロジックを見直し、不正アクセスからアプリケーションを保護するために、以下に記載するガイダンスに従ってください。さらに、すべての開発者は、トークン検証のためのマイクロソフトIDプラットフォームの ベストプラクティス に従うことをお勧めします。サードパーティのアプリケーションを使用する場合 (つまり、開発者ではない場合) ベンダーがこれらのベストプラクティスを遵守していることを確認することをお勧めします。
アプリケーションのソースコードを確認し、メールが主要なユーザー識別や認可に使用されていないことを確認することをお勧めします。アプリケーションでこれらの安全でないパターンを使用している場合は、以下の 移行ガイダンス を使用して、アカウント エスカレーション攻撃のリスクを排除してください。
お客様への影響
マイクロソフトは、ドメイン所有者が確認していないメールアドレスを使用しているユーザーがいるマルチテナントアプリケーションをいくつか確認しました。検証されていないメールアドレスは、認可目的でメールを利用しないアプリケーションにリスクをもたらすものではありませんが、これらのアプリケーションの所有者には通知され、該当する場合はアプリケーションを修正する方法についてのガイダンスを提供しました。
通知を受け取らなかった場合、お客様のアプリケーションは、検証されていないドメイン所有者とのメールクレームを利用していません。特権昇格の可能性があるお客様やアプリケーションを保護するために、マイクロソフトは、ほとんどのアプリケーションで、未確認のドメイン所有者からのトークンクレームを除外する緩和策を導入しています。
技術的な詳細
プロビジョニングされたメールボックスを持たない AAD ユーザーは、Mail (Primary SMTP) 属性に任意のメールアドレスを設定できます。この属性は、検証済みのメールアドレスからのものであることを保証するものではありません。AAD ユーザーは、他の AAD ユーザーになりすましたメールを持つ特権ユーザーによって作成または変更することができます。アプリケーションが認可のために検証されていないメール クレームを使用する場合、悪意のあるアクターは、有効な AAD ユーザーになりすましてトークンを発行することによって、不正にアクセスする可能性があります。
これは、シングルテナントのアプリケーションで不正な管理者が行うことは可能ですが、リスクは主にマルチテナントのアプリケーションで、この誤った設定によってアカウントや権限の昇格が発生する可能性があります。
Azure AD アプリケーションのセキュリティに関するガイダンス
メールクレームは、変異しやすく、一意性がないため、アプリケーションは認可のために使用しないでください。この脆弱性に対処するには、メールクレームを認可に使用しているビジネスロジックを完全に削除する必要があります。 マイクロソフトは、アプリケーションを更新するには時間がかかるため、より短期的な緩和策が必要であることを認識しています。メールクレームを積極的に使用しているアプリケーションの場合、メールクレームの使用から移行するためのガイダンスと、マイクロソフトが公開しているリスク軽減のためのメカニズムの概要について記載している ドキュメント を参照することをお勧めします。
マイクロソフトは、アプリケーションのソースコードを精査し、この安全でないパターンが使用されていないことを確認することを推奨します。 この不正な認可パターンに対してアプリケーションを完全に保護するには、アプリケーションのソースコードを変更する必要があります。 開発者は、クレームベースの認可に関するベストプラクティス について、公開されているドキュメントに従ってください。現在、アプリケーションが影響を受けている場合は、短期的なリスク軽減とメールクレームからの移行に関する ガイダンス を確認してください。
謝辞
マイクロソフトは、Descope 社がこの安全でないシナリオについて責任を持って開示し、マイクロソフトがこの問題を調査し、適切な緩和策を開発するのに必要な時間を与えてくれたことに感謝します。我々は、すべての研究者が、CVD (Coordinated Vulnerability Disclosure) ガイドラインの下でベンダーと協力し、セキュリティ研究を行う際に顧客データに影響を与えないよう、侵入テストの契約規則 を遵守することを推奨します。
参考文献
ご質問がある場合には、 Azureポータルの aka.ms/azsupt からサポートケースを起票してください。
Descope 社のブログサイト ： https://www.descope.com/blog/post/noauth
アイデンティティとネットワーク アクセスス タンダードのガイダンス ： The False Identifier Anti-pattern
アイデンティティとネットワーク アクセス マイグレーションのガイダンス ： Migrate away from using email claims for user identification or authorization
標準クレームのためのOpen ID Connectコア仕様 ： https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims