Az - Illicit Consent Grant
OAuthアプリのフィッシング
Azureアプリケーションは、ユーザーデータ(基本情報だけでなく、ドキュメントへのアクセス、メールの送信など)へのアクセス許可を要求します。
許可された場合、通常のユーザーは**「低影響の権限」**にのみ同意できます。それ以外の場合は、管理者の同意が必要です。
GA
、ApplicationAdministrator
、CloudApplication
Administrator
、およびアプリケーションにアクセス許可を付与する権限
を含むカスタムロールは、テナント全体の同意を提供できます。
管理者の同意が不要な権限のみが低影響として分類されます。これらは、基本的なサインインに必要な権限であるopenid、profile、email、User.Read、offline_accessです。組織がすべてのアプリにユーザー同意を許可している場合、従業員はアプリに自分のプロフィールから上記を読む権限を付与できます。
したがって、攻撃者は悪意のあるアプリを準備し、フィッシングを行い、ユーザーにアプリを受け入れさせてデータを盗むことができます。
2種類の不正な同意付与攻撃
非認証: 外部アカウントから
User.Read
およびUser.ReadBasic.All
の権限を持つアプリケーションを作成し、ユーザーをフィッシングすると、ディレクトリ情報にアクセスできます。これには、フィッシングされたユーザーが外部環境からのOAuthアプリを受け入れる能力が必要です!
認証済み: 十分な権限を持つ主体を侵害した場合、アカウント内でアプリケーションを作成し、特権のあるOAuth権限を受け入れることができる特権のあるユーザーをフィッシングします。
この場合、すでにディレクトリの情報にアクセスできるため、権限
User.ReadBasic.All
はもはや興味深くありません。管理者に権限を付与する権限が必要な権限に興味がある可能性が高いです。なぜなら、生のユーザーはOAuthアプリに権限を付与できないためです。そのため、これらのユーザーだけをフィッシングする必要があります(後でどの役割/権限がこの特権を付与するかについて詳しく説明します)
ユーザーが同意できるかどうかを確認する
Azure Active Directory(Azure AD)のユーザーがアプリケーションに同意できるかどうかに関する同意構成を確認するために、次のPowerShellコマンドが使用されます:
ユーザー同意の無効化: この設定は、ユーザーがアプリケーションに対して権限を付与することを禁止します。ユーザーによるアプリケーションへの同意は許可されません。
検証済みのパブリッシャーまたは組織からのアプリに対するユーザー同意を許可しますが、選択した権限のみ: この設定では、すべてのユーザーが、検証済みのパブリッシャーによって公開されたアプリケーションおよび自分のテナントに登録されたアプリケーションにのみ同意できるようにします。特定の権限に対してのみ同意を許可することで、コントロールのレイヤーを追加します。
すべてのアプリに同意できる: この設定はより寛容であり、すべてのユーザーが、管理者の同意が必要とされない限り、アプリケーションの任意の権限に同意できるようにします。
カスタムアプリ同意ポリシー: この設定は、特定の組織の要件に合わせて調整できるカスタムポリシーが導入されていることを示し、アプリのパブリッシャーやアプリが要求する権限などに基づいた制限の組み合わせを含む場合があります。
不正な同意付与攻撃の理解
不正な同意付与攻撃では、攻撃者がエンドユーザーをだまして、Azureに登録された悪意のあるアプリケーションに権限を付与させます。これは、アプリケーションを正当なものと見せかけ、被害者が無意識に「承諾」ボタンをクリックさせることで行われます。その結果、Azure ADは攻撃者のサイトにトークンを発行し、組織アカウントを必要とせずに攻撃者が被害者のデータにアクセスして操作することを可能にします。例えば、メールの読み取りや送信、ファイルへのアクセスなどが挙げられます。
攻撃フローの概要
この攻撃は、一般的な企業を標的としていくつかのステップを経て展開されます。以下は、攻撃が展開される可能性のある方法です:
ドメイン登録とアプリケーションホスティング: 攻撃者は、信頼できるサイトに似せたドメインを登録します。例えば、「safedomainlogin.com」というドメインの下に、悪意のあるアプリケーションをホストするためのサブドメイン(例:「companyname.safedomainlogin.com」)が作成されます。
Azure ADでのアプリケーション登録: 次に、攻撃者はAzure ADテナントでマルチテナントアプリケーションを登録し、それを標的企業の名前にして正当に見せかけます。アプリケーションのリダイレクトURLを、悪意のあるアプリケーションをホストするサブドメインを指すように構成します。
権限の設定: 攻撃者は、さまざまなAPI権限(例:
Mail.Read
、Notes.Read.All
、Files.ReadWrite.All
、User.ReadBasic.All
、User.Read
)を持つアプリケーションを設定します。これらの権限は、ユーザーによって付与されると、攻撃者がユーザーの代わりに機密情報を抽出できるようにします。悪意のあるリンクの配布: 攻撃者は、悪意のあるアプリケーションのクライアントIDを含むリンクを作成し、対象ユーザーに共有して同意を取得するように仕向けます。
攻撃に利用するツール
この攻撃は、365-Stealerなどのツールを使用して容易に行うことができます。
攻撃前の準備:
攻撃者が被害組織のユーザーにある程度のアクセス権を持っている場合、組織のポリシーがユーザーがアプリを受け入れることを許可しているかどうかを確認するかもしれません。
攻撃を実行するために、攻撃者はAzureテナント内のApp registrationsで新しいAppを作成する必要があります。このAppは以下の権限で構成されています:
User.ReadBasic.All
はDelegated permissions
内のMicrosoft Graph
にあります(Application permissionsは常に追加の承認が必要です)。
User.ReadBasic.All
は、付与された場合に組織内のすべてのユーザーの情報を読み取ることを許可する権限です。GA
、ApplicationAdministrator
、CloudApplication Administrator
、およびアプリケーションに権限を付与する権限を含むカスタムロール
のみがテナント全体の同意を提供できます。したがって、管理者同意が必要なAppを承認するよう求めるには、これらの役割のいずれかを持つユーザーをフィッシングする必要があります。
また、CLIを使用してAppを作成することもできます:
https://www.alteredsecurity.com/post/introduction-to-365-stealer をチェックして、それを設定する方法を学びます。
取得される アクセストークン は、User.Read
と User.ReadBasic.All
(要求された権限)のスコープを持つ graphエンドポイント 用です。他のアクションを実行することはできません(しかし、これらは組織内のすべてのユーザーに関する情報を ダウンロードするのに十分です)。
このツールを使用してこの攻撃を実行することもできます。
ポストエクスプロイテーション
ユーザーにアクセスできると、機密文書の盗みや、バックドア付きの文書ファイルをアップロードするなどのことができます。
参考文献
最終更新