AWS - STS Privesc
STS
sts:AssumeRole
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 faire une élévation de privilèges vers les autorisations associées à ce rôle.
Vous pouvez vous faire passer pour un rôle en exécutant :
Impact potentiel : Élévation de privilèges vers le rôle.
Notez que dans ce cas, l'autorisation sts:AssumeRole
doit être indiquée dans le rôle à abuser et non dans une stratégie appartenant à l'attaquant.
À une exception près, pour assumer un rôle d'un compte différent, le compte de l'attaquant doit également avoir l'autorisation sts:AssumeRole
sur le rôle.
sts:GetFederationToken
sts:GetFederationToken
Avec cette autorisation, il est possible de générer des informations d'identification pour se faire passer pour n'importe quel utilisateur :
C'est ainsi que cette autorisation peut être donnée de manière sécurisée sans donner accès à l'usurpation d'identité d'autres utilisateurs :
sts:AssumeRoleWithSAML
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 de politique de confiance avec cette autorisation est :
Pour générer des informations d'identification pour usurper le rôle en général, vous pourriez utiliser quelque chose comme :
Mais les fournisseurs peuvent avoir leurs propres outils pour faciliter cette tâche, comme onelogin-aws-assume-role :
Impact potentiel : Élévation de privilèges vers le rôle.
sts:AssumeRoleWithWebIdentity
sts:AssumeRoleWithWebIdentity
Cette autorisation accorde la permission d'obtenir un ensemble de justificatifs 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 devrait pouvoir usurper un rôle IAM, il aura un jeton dans /var/run/secrets/eks.amazonaws.com/serviceaccount/token
et pourra assumer le rôle et obtenir des justificatifs en faisant quelque chose comme :
Abus de Fédération
Last updated