Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Les pools d'identité jouent un rôle crucial en permettant à vos utilisateurs d'acquérir des identifiants temporaires. Ces identifiants sont essentiels pour accéder à divers services AWS, y compris, mais sans s'y limiter, Amazon S3 et DynamoDB. Une caractéristique notable des pools d'identité est leur support pour les utilisateurs invités anonymes et une gamme de fournisseurs d'identité pour l'authentification des utilisateurs. Les fournisseurs d'identité pris en charge incluent :
Amazon Cognito user pools
Options de connexion sociale telles que Facebook, Google, Login with Amazon, et Sign in with Apple
Fournisseurs conformes à OpenID Connect (OIDC)
Fournisseurs d'identité SAML (Security Assertion Markup Language)
Identités authentifiées par le développeur
Pour générer des sessions de Identity Pool, vous devez d'abord générer un Identity ID. Cet Identity ID est l'identification de la session de cet utilisateur. Ces identifications peuvent avoir jusqu'à 20 ensembles de données pouvant stocker jusqu'à 1 Mo de paires clé-valeur.
Ceci est utile pour garder des informations sur un utilisateur (qui utilisera toujours le même Identity ID).
De plus, le service cognito-sync est le service qui permet de gérer et synchroniser ces informations (dans les ensembles de données, en envoyant des informations dans des flux et des messages SNS...).
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 personnalisés modifiables, des identifiants de pool d'identité utilisables, des rôles assumables dans des jetons d'identité, etc.
Pour une description des fonctions des modules, voir la partie 2 du blog post. Pour des instructions d'installation, voir la page principale de Pacu.
Exemple d'utilisation de cognito__attack pour tenter la création d'utilisateur et tous les vecteurs d'escalade de privilèges contre un pool d'identité et un client de pool d'utilisateurs donnés :
Exemple d'utilisation de cognito__enum pour rassembler tous les groupes d'utilisateurs, les clients de groupes d'utilisateurs, les pools d'identité, les utilisateurs, etc. visibles dans le compte AWS actuel :
Cognito Scanner est un outil CLI en python qui implémente différentes attaques sur Cognito, y compris la création de comptes non désirés et l'escalade de pools d'identité.
Pour plus d'informations, consultez https://github.com/padok-team/cognito-scanner
La seule chose qu'un attaquant doit savoir pour obtenir des identifiants AWS dans une application Cognito en tant qu'utilisateur non authentifié est le ID de la piscine d'identité, et cet ID doit être codé en dur dans l'application web/mobile pour qu'elle puisse l'utiliser. Un ID ressemble à ceci : eu-west-1:098e5341-8364-038d-16de-1865e435da3b (il n'est pas bruteforcable).
Le rôle IAM Cognito non authentifié créé via est appelé par défaut Cognito_<Nom de la piscine d'identité>Unauth_Role
Si vous trouvez un ID de piscine d'identité codé en dur et qu'il permet aux utilisateurs non authentifiés, vous pouvez obtenir des identifiants AWS avec :
Ou vous pourriez utiliser les commandes aws cli suivantes :
Notez qu'en défaut, un utilisateur cognito non authentifié NE PEUT avoir aucune permission, même si elle a été assignée via une politique. Consultez la section suivante.
La section précédente a suivi le flux d'authentification amélioré par défaut. Ce flux définit une politique de session restrictive pour la session de rôle IAM générée. Cette politique ne permettra à la session que d'utiliser les services de cette liste (même si le rôle avait accès à d'autres services).
Cependant, il existe un moyen de contourner cela, si le pool d'identité a "Flux basique (classique)" activé, l'utilisateur pourra obtenir une session en utilisant ce flux qui n'aura pas cette politique de session restrictive.
Si vous recevez cette erreur, c'est parce que le flux de base n'est pas activé (par défaut)
Une erreur s'est produite (InvalidParameterException) lors de l'appel de l'opération GetOpenIdToken : Le flux de base (classique) n'est pas activé, veuillez utiliser le flux amélioré.
Ayant un ensemble de credentials IAM, vous devriez vérifier quels accès vous avez et essayer d'escalader les privilèges.
N'oubliez pas que les utilisateurs authentifiés se verront probablement accorder des permissions différentes, donc si vous pouvez vous inscrire dans l'application, essayez de le faire et obtenez les nouveaux credentials.
Il pourrait également y avoir des rôles disponibles pour les utilisateurs authentifiés accédant au Identity Pool.
Pour cela, vous pourriez avoir besoin d'accéder au fournisseur d'identité. Si c'est un Cognito User Pool, peut-être pouvez-vous abuser du comportement par défaut et créer un nouvel utilisateur vous-même.
Le rôle authentifié IAM Cognito créé via est appelé par défaut Cognito_<Nom du Identity Pool>Auth_Role
Quoi qu'il en soit, le suivant exemple suppose que vous vous êtes déjà connecté à un Cognito User Pool utilisé pour accéder au Identity Pool (n'oubliez pas que d'autres types de fournisseurs d'identité pourraient également être configurés).
Il est possible de configurer différents rôles IAM en fonction du fournisseur d'identité avec lequel l'utilisateur est connecté ou même simplement en fonction de l'utilisateur (en utilisant des claims). Par conséquent, si vous avez accès à différents utilisateurs via le même ou différents fournisseurs, cela pourrait valoir le coup de se connecter et d'accéder aux rôles IAM de tous.
Apprenez et pratiquez le Hacking AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le Hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
