AWS - IAM & STS Unauthenticated Enum

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks:

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

Brute-Force de l'Assume Role

Cette technique ne fonctionne plus car que le rôle existe ou non, vous obtenez toujours cette erreur :

Une erreur s'est produite (AccessDenied) lors de l'appel de l'opération AssumeRole : L'utilisateur : arn:aws:iam::947247140022:user/testenv n'est pas autorisé à effectuer : sts:AssumeRole sur la ressource : arn:aws:iam::429217632764:role/account-balanceasdas

Vous pouvez tester ceci en exécutant :

aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example

Tenter de supposer un rôle sans les autorisations 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'assumption de rôle ne permet pas votre assumption. En revanche, essayer d'assumer un rôle inexistant entraîne une erreur différente :

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

Intéressant, cette méthode de différenciation 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, il est possible d'énumérer les rôles présents dans le compte sans rencontrer de limitations inhérentes.

Vous pouvez utiliser ce script pour énumérer les principaux potentiels en exploitant ce problème.

Politiques de confiance : Brute-Force des rôles et utilisateurs inter-comptes

La configuration ou la mise à jour de la politique de confiance d'un rôle IAM implique de définir quels 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 inter-comptes :

  • 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 stratégie sera enregistrée sans erreurs. (L'erreur est pour la mise à jour, mais cela 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

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 à impersonner par Pacu pour créer les politiques nécessaires à l'énumération

Élévation de privilèges

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"
}
]
}

Le pirate pourrait simplement le supposer.

Fédération OIDC de tiers

Imaginez que vous parveniez à lire un flux de travail 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"
}
}
}
]
}

Ce manque de conditions supplémentaires devrait vous inciter à vous méfier, même si la stratégie de confiance semble correcte. Cela est dû au fait que le rôle précédent peut être assumé par N'IMPORTE QUI de Github Actions! Vous devriez également 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 erreur potentielle de configuration est d'ajouter une condition comme celle-ci :

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

Notez que le joker (*) avant les deux-points (:). Vous pouvez créer une organisation telle que org_name1 et assumer le rôle depuis une Action Github.

Références

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres façons de soutenir HackTricks:

Dernière mise à jour