AWS - IAM & STS Unauthenticated Enum

Reading time: 6 minutes

Énumérer les rôles et les noms d'utilisateur dans un compte

Assume Role Brute-Force

Tenter de assumer un rôle sans les permissions nécessaires déclenche un message d'erreur AWS. Par exemple, si non autorisé, AWS peut 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 assume role policy n'autorise pas votre prise de rôle. En revanche, tenter de assumer un rôle non existant entraîne 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 roles existants et non-existants s'applique même entre différents comptes AWS. Avec un AWS account ID valide et une wordlist ciblée, il est possible d'énumérer les roles présents dans le compte sans rencontrer de limitations inhérentes.

Vous pouvez utiliser ce script pour énumérer les principals potentiels en abusant de ce problème.

Trust Policies : Brute-Force Cross Account roles and users

La configuration ou la mise à jour d'une IAM role's trust policy implique de définir quelles ressources ou services AWS sont autorisés à assumer ce role et à obtenir des credentials temporaires. Si la ressource spécifiée dans la policy existe, la trust policy est enregistrée avec succès. En revanche, si la ressource n'existe pas, une erreur est générée, indiquant qu'un principal invalide a été fourni.

Voici un exemple de policy:

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

GUI

Ceci est l'erreur que vous trouverez si vous utilisez un role qui n'existe pas. Si le role existe, la policy sera enregistrée sans aucune erreur. (L'erreur concerne une mise à jour, mais cela fonctionne aussi 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
• The admin role used in the example is a rôle de votre compte pouvant être usurpé par pacu pour créer les policies dont il a besoin pour l'énumération

Privesc

Dans le cas où le rôle est mal configuré et permet à n'importe qui de l'assumer :

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

L'attaquant pourrait simplement l'assumer.

Fédération OIDC par un tiers

Imaginez que vous parveniez à lire un Github Actions workflow qui accède à un role dans AWS.
Cette relation de confiance pourrait donner accès à un role avec la trust policy 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 stratégie de confiance peut être correcte, mais le manque de conditions supplémentaires devrait vous rendre méfiant.
Ceci est dû au fait que le rôle précédent peut être assumé par N'IMPORTE QUI sur Github Actions ! Vous devriez préciser dans les conditions aussi d'autres éléments tels que le nom de l'organisation, le nom du repo, l'env, la branche...

Une autre mauvaise configuration possible est d'ajouter une condition comme suit :

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

Notez que le wildcard (*) avant les deux-points (:). Vous pouvez créer une org telle que org_name1 et assume the role depuis une Github Action.

Références

• https://www.youtube.com/watch?v=8ZXRw4Ry3mQ
• https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/