AWS - STS Privesc

Support HackTricks

STS

sts:AssumeRole

Chaque rôle est créé avec une politique de confiance de rôle, cette politique indique qui peut assumer le rôle créé. Si un rôle du même compte indique qu'un compte peut l'assumer, cela signifie que le compte pourra accéder au rôle (et potentiellement privesc).

Par exemple, la politique de confiance de rôle suivante indique que n'importe qui peut l'assumer, donc tout utilisateur pourra privesc aux permissions associées à ce rôle.

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

Vous pouvez usurper un rôle en exécutant :

aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname

Impact potentiel : Privesc au rôle.

Notez que dans ce cas, la permission sts:AssumeRole doit être indiquée dans le rôle à abuser et non dans une politique appartenant à l'attaquant. Avec une exception, afin de prendre un rôle d'un compte différent, le compte attaquant doit également avoir le sts:AssumeRole sur le rôle.

sts:GetFederationToken

Avec cette permission, il est possible de générer des identifiants pour usurper n'importe quel utilisateur :

aws sts get-federation-token --name <username>

C'est ainsi que cette autorisation peut être accordée en toute sécurité sans donner accès à l'imitation d'autres utilisateurs :

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "arn:aws:sts::947247140022:federated-user/${aws:username}"
}
]
}

sts:AssumeRoleWithSAML

Une politique de confiance avec ce rôle accorde aux utilisateurs authentifiés via SAML l'accès pour usurper le rôle.

Un exemple d'une politique de confiance avec cette permission est :

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "OneLogin",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::290594632123:saml-provider/OneLogin"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}

Pour générer des identifiants afin d'usurper le rôle, vous pourriez utiliser quelque chose comme :

aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>

Mais les fournisseurs peuvent avoir leurs propres outils pour faciliter cela, comme onelogin-aws-assume-role :

onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600

Impact potentiel : Privesc au rôle.

sts:AssumeRoleWithWebIdentity

Cette permission accorde le droit d'obtenir un ensemble de credentials de sécurité temporaires pour les utilisateurs qui ont été authentifiés dans une application mobile, web, EKS... avec un fournisseur d'identité web. En savoir plus ici.

Par exemple, si un compte de service EKS doit être capable de se faire passer pour un rôle IAM, il aura un jeton dans /var/run/secrets/eks.amazonaws.com/serviceaccount/token et peut assumer le rôle et obtenir des credentials en faisant quelque chose comme :

aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/<role_name> --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
# The role name can be found in the metadata of the configuration of the pod

Abus de fédération

Soutenir HackTricks

Last updated