AWS - IAM & STS Unauthenticated Enum
Enumérer les Rôles et Noms d'Utilisateurs dans un compte
Assume Role Brute-Force
Cette technique ne fonctionne plus car que le rôle existe ou non, vous obtenez toujours cette erreur :
An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::947247140022:user/testenv is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::429217632764:role/account-balanceasdas
Vous pouvez tester cela en exécutant :
aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example
Tenter de prendre un rôle sans les permissions nécessaires déclenche un message d'erreur AWS. Par exemple, si non autorisé, AWS pourrait renvoyer :
Ce message confirme l'existence du rôle mais indique que sa politique d'assumer le rôle ne permet pas votre supposition. En revanche, essayer d'assumer un rôle inexistant conduit à une erreur différente :
Fait intéressant, cette méthode de distinction entre les rôles existants et non existants est applicable même entre différents comptes AWS. Avec un ID de compte AWS valide et une liste de mots ciblée, on peut énumérer les rôles présents dans le compte sans faire face à des limitations inhérentes.
Vous pouvez utiliser ce script pour énumérer les principaux potentiels en abusant de ce problème.
Trust Policies: Brute-Force des rôles et utilisateurs de comptes croisés
Configurer ou mettre à jour la politique de confiance d'un rôle IAM implique de définir quelles ressources ou services AWS sont autorisés à assumer ce rôle et à obtenir des informations d'identification temporaires. Si la ressource spécifiée dans la politique existe, la politique de confiance est enregistrée avec succès. Cependant, si la ressource n'existe pas, une erreur est générée, indiquant qu'un principal invalide a été fourni.
Notez que dans cette ressource, vous pouvez spécifier un rôle ou un utilisateur de compte croisé :
arn:aws:iam::acc_id:role/role_name
arn:aws:iam::acc_id:user/user_name
Voici un exemple de politique :
GUI
C'est l'erreur que vous trouverez si vous utilisez un rôle qui n'existe pas. Si le rôle existe, la politique sera enregistrée sans aucune erreur. (L'erreur est pour la mise à jour, mais elle fonctionne également lors de la création)
CLI
Vous pouvez automatiser ce processus avec https://github.com/carlospolop/aws_tools
bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt
Ou en utilisant Pacu :
run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt
run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt
Le rôle
admin
utilisé dans l'exemple est un rôle dans votre compte à être usurpé par pacu pour créer les politiques nécessaires à l'énumération
Privesc
Dans le cas où le rôle était mal configuré et permet à quiconque de l'assumer :
L'attaquant pourrait simplement le supposer.
Fédération OIDC de Tiers
Imaginez que vous parvenez à lire un workflow Github Actions qui accède à un rôle à l'intérieur d'AWS. Cette confiance pourrait donner accès à un rôle avec la politique de confiance suivante :
Cette politique de confiance pourrait être correcte, mais le manque de conditions supplémentaires devrait vous rendre méfiant. Cela est dû au fait que le rôle précédent peut être assumé par N'IMPORTE QUI depuis Github Actions ! Vous devriez spécifier dans les conditions d'autres éléments tels que le nom de l'organisation, le nom du dépôt, l'environnement, la branche...
Une autre mauvaise configuration potentielle est d'ajouter une condition comme la suivante :
Notez que wildcard (*) avant le deux-points (:). Vous pouvez créer une organisation telle que org_name1 et assumer le rôle à partir d'une Github Action.
Références
Last updated