2023年1月18日（水）
著者：カウンター・スレット・ユニット（CTU™）リサーチチーム
※本記事は、https://www.secureworks.com/ で公開されている Azure Active Directory Flaw Allowed SAML Persistence を翻訳したもので、 2023年1月18日執筆時点の見解となります。
Secureworks® カウンター・スレット・ユニット（CTU™）のリサーチャーは2022年8月、Azure Active Directory（Azure AD）の脆弱性を発見しました。この脆弱性により、ユーザー割り当てが解除されたユーザーが、任意のSecurity Assertion Markup Language（SAML）アプリケーションへの接続を維持できる状態となっていました。悪意あるユーザーが、「SAMLアプリケーションへのアクセスに同意する」と設定されたバックドアアプリケーションを使用すると、自身へのユーザー割り当てが解除されているにもかかわらず、SAMLトークンを要求できる状態でした。この脆弱性が悪用されると、任意のSAMLアプリケーションへの接続が永続化され、権限昇格が行われる恐れがありました。
CTU™リサーチャーは8月4日、Microsoft社に対して前述の所見を報告しました。Microsoft社はこの問題に関する最初の緩和策を10月25日に適用しました。
攻撃の概要
Azure ADでは、事前連携済の各種サービスおよび顧客側で開発したサービス（アプリケーションなど）を対象に、SAMLベースのシングルサインオン（SSO）が設定可能です。ユーザー割り当てが必須になっている場合には、ユーザがアプリケーションにアクセスする前に、ユーザーおよびグループをアプリケーションに割り当てる必要があります。
今回の脆弱性を悪用しようとするユーザーにとって、Azure ADのユーザー割り当て設定のみに依存するSAMLアプリケーションは格好の標的となります。その場合、ユーザー割り当てが強制されていないSAMLアプリケーションが悪用され、悪意あるユーザーが標的サービス上の新規ユーザーとしてプロビジョニングされる恐れがあります。
この欠陥は、別のアプリケーションおよび特定のパラメータを用いたトークンリクエストによる連鎖的なサインインをきっかけに誘発されていました（図1）。このユースケースは元々、OAuth 2.0アプリケーションからバックエンドのSAML APIを呼び出すことを目的としたものでした。
図1：攻撃の流れ（出典：Secureworks）
- 悪意あるユーザーが、標的とは別のアプリケーションに対するAzure ADアクセストークンを要求。
- このアプリケーションがOn-Behalf-Ofフローを介して、標的となるSAMLアプリケーションへのトークンを要求。リクエストのペイロードには、図2に記載のパラメータが含まれる。
図2：リクエストのペイロードに含まれるパラメータ（出典：Securework）
ステップ1と2を連鎖的に実行すると、ユーザー割り当て設定をバイパスできる。「assertion」パラメータにはステップ１で生成されたトークンが用いられる。 - 上記リクエストに対する応答でSAMLトークンが発行される。
概念実証
概念実証（PoC）では、悪意あるユーザーが、バックドアアプリケーション設定時に自身が割り当てられていたSAMLアプリケーションへのアクセスを、バックドアアプリーケションを使用して試みる、というシナリオを用いました。このユーザーは、自らのアクセス権が削除された後も、バックドア経由でSAMLアプリケーションへのアクセスを維持できます。
- 悪意をもつユーザーが、バックドア用のAzure ADアプリケーションを新たに作成する。その後、ユーザー割り当て解除後にトークンを取得したいSAMLアプリケーションを選び、前述のバックドアアプリによるアクセス許可に同意する。図3の例では、当該ユーザーが割り当てられていた「SAML app」という名前のごく普通のアプリケーションへのアクセス手段として「UnPrivilegedUserSAMLattack2」という名前のバックドアアプリが使われている。
図3：バックドアを介したSAMLアプリケーションの侵害（出典：Secureworks）
- アプリケーション管理者が、既存のSAMLアプリケーションのユーザー割り当てから当該ユーザーを削除する（図4）。
図4：悪意あるユーザーをSAMLアプリケーションのユーザー割り当てから削除（出典：Secureworks）
- 悪意あるユーザーが、ステップ1でアクセス許可に同意設定したアプリケーションを介してSAMLアプリケーションへのアクセストークンを要求する。
この概念実証で用いたバックドアアプリケーションは、無関係のアプリケーションのgetCode.jsファイルに悪性コードを追加したもので、このアプリケーションを介してトークンを要求します。以下に示すとおり、要求されたトークンを参照する行には、ユーザー割り当ての検証をバイパスする脆弱なパラメータの組み合わせが含まれています。
"requested_token_type":"urn:ietf:params:oauth:token-type:saml2",
"requested_token_use":"on_behalf_of"
SAMLトークンの内容確認
攻撃の目的は、有効な署名、発行者、オーディエンス、クレームが含まれたSAMLトークンを取得することです（図5）。悪意あるユーザーは、標的アプリケーションへのユーザー割り当てが解除されているにもかかわらず、正規のアクセスパターンで発行されたものと同等のSAMLトークンを取得できます。不正に取得されたSAMLトークンを調べたところ、標的となるSAMLアプリケーションに対して設定された追加のクレーム（グループなど）が含まれていました。
図5：不正に取得されたSAMLトークンの属性（出典：Secureworks）
悪用するための条件
今回の脆弱性は簡単に攻撃できましたが、Azure ADアプリケーションおよびその設定内容を深く理解していなければ実行できません。攻撃を実行するには、自身に対するユーザー割り当てが解除される前にアプリケーションへのバックドアを作成する必要があります。この脆弱性を攻撃するには、以下の知識が必要です。
- Azure ADのOn-Behalf-Ofフローを理解していること
- JWTでSAMLトークンを要求する、通常とは異なる要求フローの利用方法を理解していること
- Azure ADアプリケーションに対する同意およびアクセス許可について理解していること
- 通常とは異なるSAMLトークンの利用パターンについて理解していること。概念実証コードでは、デバイスコードフローを使用するCLIアプリケーションを悪用してJWTを取得した後に、On-Behalf-Ofフローのパターン「<->」を用いてJWTをSAMLトークンと交換しました。この手法は、Webブラウザがブラウザアプリケーションと直接連携してSAMLトークンを取得するという一般的なユースケースとは異なります。
Microsoft社とのやり取り
当社のCTUリサーチャーは2022年8月4日、今回の脆弱性に関する最初の所見をMicrosoft社に報告しました。その後10月7日に更なる詳細を提供しました。Microsoft社は10月10日、当社が指摘した攻撃パターンを認め、この脆弱性を権限昇格に関する「重要」カテゴリの問題に指定しました。Microsoft社は10月25日付で最初の緩和策を適用して問題に対処し、当社に対して以下の通り回答しました。
Microsoft社は、Azure Active Directory（Azure AD）におけるOAuth2.0プロトコルのアクセストークン要求に関する問題を修正しました。この問題は、中間層アプリケーションがアクセス要求を行った後にSecurity Assertion Markup Language（SAML）ベースの認可を用いてバックエンドAPIにアクセスする際に発生し、一定の状況下では、テナント環境に存在するユーザーがバックエンドアプリケーションの機能に不適切な形でアクセスできる状態となっていました。
Microsoft社は、上記の問題を修正しました。今後は、バックエンドアプリケーションの機能へのアクセス権は、適切に設定されたユーザーのみに付与されます。
結論
今回判明した欠陥は、Azure ADテナント環境内で以前に割り当てられたユーザーであれば、ユーザー割り当てが解除された後でもバックドアアプリケーション経由でアプリケーションへのアクセスを維持できる、というものでした。この振る舞いが実行できるのは、バックドアアプリケーションの設定時に有効なアクセス権が付与されていたユーザーのみでした。
この脆弱性の影響を緩和できていたケースは以下の通りです。
- 今回影響を受けたのは、IdPを起点としたSSOをサポートするアプリケーションでした。SPを起点としたSSOのみをサポートしているアプリケーションは、SAML要求の応答で「inResponseTo」属性が必要なため、影響はありませんでした。
- トークン取得時にユーザーのアクセス許可やロールに関する追加チェックをアプリケーション側で実行している場合は、悪意あるユーザーがAzure ADのユーザー割り当てをバイパスしたとしても追加チェックの段階で阻止できていました。
CTUリサーチャーは、今後同様の脅威が発生した場合のリスク軽減策として、自組織のユーザーがAzure ADテナント環境で独自のアプリケーション登録を禁止することを推奨します。
