AWS - STS Privesc

Reading time: 6 minutes

STS

sts:AssumeRole

Chaque rôle est créé avec une politique de confiance du 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 du 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 vers le rôle.

sts:AssumeRoleWithSAML

Une stratégie d'approbation (trust policy) associée à ce rôle accorde aux utilisateurs authentifiés via SAML la possibilité de se faire passer pour le rôle.

Un exemple de stratégie d'approbation contenant 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 permettant d'usurper le rôle, vous pouvez généralement utiliser quelque chose comme :

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

Mais les fournisseurs pourraient 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 sur le rôle.

sts:AssumeRoleWithWebIdentity

Cette permission permet d'obtenir un ensemble d'identifiants de sécurité temporaires pour les utilisateurs qui ont été authentifiés dans une application mobile, web, EKS... auprès d'un fournisseur d'identité web. En savoir plus ici.

Par exemple, si un EKS service account devrait pouvoir 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 identifiants 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

Federation Abuse

AWS - Federation Abuse

IAM Roles Anywhere Privesc

AWS IAM RolesAnywhere permet à des workloads extérieurs à AWS d'assumer des IAM roles en utilisant des certificats X.509. Mais lorsque les trust policies ne sont pas correctement limitées, elles peuvent être abusées pour du privilege escalation.

Pour comprendre cette attaque, il est nécessaire d'expliquer ce qu'est un trust anchor. Un trust anchor dans AWS IAM Roles Anywhere est l'entité racine de confiance ; il contient le certificat public d'une Certificate Authority (CA) enregistrée dans le compte afin qu'AWS puisse valider les certificats X.509 présentés. Ainsi, si le certificat client a été émis par cette CA et que le trust anchor est actif, AWS le reconnaît comme valide.

De plus, un profile est la configuration qui définit quels attributs du certificat X.509 (tels que CN, OU ou SAN) seront transformés en session tags, et ces tags seront ensuite comparés aux conditions de la trust policy.

Cette policy ne contient pas de restrictions sur les trust anchors ou les attributs de certificat autorisés. En conséquence, n'importe quel certificat lié à n'importe quel trust anchor du compte peut être utilisé pour assumer ce rôle.

{
"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 effectuer un pivot vers un rôle à privilèges supérieurs.

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

L'ancre de confiance valide que le certificat client readonly.pem provient de son CA autorisé, et dans ce certificat readonly.pem se trouve la clé publique qu'AWS utilise pour vérifier que la signature a été faite avec sa clé privée correspondante readonly.key.

Le certificat fournit également des attributs (comme CN ou OU) que le profil default transforme en tags, que la politique de confiance du rôle peut utiliser pour décider d'autoriser l'accès. S'il n'y a pas de conditions dans la politique de confiance, ces tags n'ont aucune utilité, et l'accès est accordé à quiconque possède un certificat valide.

Pour que cette attaque soit possible, l'ancre de confiance et le profil default doivent être actifs.

Références

• https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation