Cognito Identity Pools
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
アイデンティティプールは、ユーザーが一時的な資格情報を取得できるようにする重要な役割を果たします。これらの資格情報は、Amazon S3やDynamoDBを含むさまざまなAWSサービスにアクセスするために不可欠です。アイデンティティプールの注目すべき機能は、匿名のゲストユーザーとユーザー認証のためのさまざまなアイデンティティプロバイダーの両方をサポートしていることです。サポートされているアイデンティティプロバイダーには以下が含まれます:
Amazon Cognitoユーザープール
Facebook、Google、Amazonでのログイン、Appleでのサインインなどのソーシャルサインインオプション
OpenID Connect (OIDC) に準拠したプロバイダー
SAML (Security Assertion Markup Language) アイデンティティプロバイダー
開発者認証されたアイデンティティ
Identity Pool セッションを生成するには、まず Identity ID を生成する 必要があります。この Identity ID は そのユーザーのセッションの識別 です。これらの識別は最大 20 のデータセットを持つことができ、最大 1MB のキーと値のペアを保存できます。
これは ユーザーの情報を保持するのに便利です (常に同じ Identity ID を使用するユーザー)。
さらに、サービス cognito-sync は この情報を管理および同期する サービスです(データセット内で、ストリームや SNS メッセージで情報を送信するなど)。
Pacu は、AWS のエクスプロイトフレームワークで、現在 "cognito__enum" および "cognito__attack" モジュールが含まれており、アカウント内のすべての Cognito アセットの列挙を自動化し、弱い構成、アクセス制御に使用されるユーザー属性などをフラグ付けし、ユーザー作成(MFA サポートを含む)や、変更可能なカスタム属性に基づく権限昇格、使用可能なアイデンティティプールの資格情報、ID トークン内の引き受け可能なロールなどを自動化します。
モジュールの機能の説明については、ブログ投稿 のパート 2 を参照してください。インストール手順については、メインの Pacu ページを参照してください。
特定のアイデンティティプールおよびユーザープールクライアントに対してユーザー作成とすべての権限昇格ベクターを試みるためのサンプル cognito__attack 使用法:
サンプル cognito__enum の使用法:現在の AWS アカウントで表示されるすべてのユーザープール、ユーザープールクライアント、アイデンティティプール、ユーザーなどを収集します。
Cognito Scanner は、不要なアカウント作成やアイデンティティプールのエスカレーションを含む、Cognitoに対するさまざまな攻撃を実装したPythonのCLIツールです。
For more information check https://github.com/padok-team/cognito-scanner
攻撃者がCognitoアプリで認証されていないユーザーとしてAWS資格情報を取得するために知っておくべき唯一のことはアイデンティティプールIDであり、このIDはウェブ/モバイルアプリケーションにハードコーディングされている必要があります。IDは次のようになります: eu-west-1:098e5341-8364-038d-16de-1865e435da3b
(ブルートフォース攻撃はできません)。
デフォルトでIAM Cognito認証されていないロールは Cognito_<Identity Pool name>Unauth_Role
と呼ばれます
アイデンティティプールIDがハードコーディングされていて、認証されていないユーザーを許可している場合、次のコマンドでAWS資格情報を取得できます:
または、次のaws cliコマンドを使用できます:
デフォルトでは、認証されていないcognito ユーザーは、ポリシーを介して割り当てられていても、いかなる権限も持つことができません。次のセクションを確認してください。
前のセクションでは、デフォルトの拡張認証フローに従いました。このフローは、生成されたIAMロールセッションに制限的なセッションポリシーを設定します。このポリシーは、セッションがこのリストのサービスを使用することを許可するだけであり(ロールが他のサービスにアクセスできたとしても)。
しかし、これを回避する方法があります。アイデンティティプールに「基本(クラシック)フロー」が有効になっている場合、ユーザーはそのフローを使用してセッションを取得でき、その制限的なセッションポリシーは適用されません。
このエラーが発生した場合、**基本フローが有効になっていない(デフォルト)**ためです。
An error occurred (InvalidParameterException) when calling the GetOpenIdToken operation: Basic (classic) flow is not enabled, please use enhanced flow.
IAM資格情報のセットを持っている場合は、どのアクセス権があるかを確認し、権限を昇格させることを試みてください。
認証済みユーザーには異なる権限が付与される可能性があるため、もしアプリ内でサインアップできる場合は、それを試みて新しい資格情報を取得してください。
認証済みユーザーがアイデンティティプールにアクセスするための ロールも利用可能かもしれません。
そのためには、アイデンティティプロバイダーへのアクセスが必要です。もしそれがCognitoユーザープールであれば、デフォルトの動作を悪用して自分で新しいユーザーを作成できるかもしれません。
IAM Cognito認証ロールはデフォルトで Cognito_<Identity Pool name>Auth_Role
と呼ばれます。
いずれにせよ、以下の例は、アイデンティティプールにアクセスするために使用されるCognitoユーザープールにすでにログインしていることを前提としています(他のタイプのアイデンティティプロバイダーも設定されている可能性があることを忘れないでください)。
ユーザーがログインしているアイデンティティプロバイダーやユーザー(クレームを使用)に応じて、異なるIAMロールを構成することが可能です。したがって、同じまたは異なるプロバイダーを通じて異なるユーザーにアクセスできる場合は、すべてのユーザーのIAMロールにログインしてアクセスする価値があるかもしれません。
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)