gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-02-04 19:11:41 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

Browse Source
This commit is contained in:
Translator
2025-09-30 19:16:49 +00:00
parent e83e830dae
commit 3327b34468
1 changed files with 22 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
View File

@@ -6,9 +6,9 @@
### `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 effectuer un **privesc**).
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 suivante indique que n'importe qui peut l'assumer, donc **tout utilisateur pourra effectuer un privesc** sur les permissions associées à ce rôle.
Par exemple, la politique de confiance suivante indique que n'importe qui peut l'assumer, donc **n'importe quel utilisateur pourra effectuer un privesc** sur les permissions associées à ce rôle.
```json
{
"Version": "2012-10-17",
@@ -23,20 +23,20 @@ Par exemple, la politique de confiance suivante indique que n'importe qui peut l
]
}
```
Vous pouvez usurper un rôle en exécutant :
Vous pouvez usurper un rôle en cours d'exécution :
```bash
aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
```
**Impact potentiel :** Privesc vers le rôle.
**Impact potentiel :** Privesc sur le 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 policy appartenant à l'attaquant.\
> À une exception près, pour **assumer un rôle depuis un compte différent** le compte attaquant **doit aussi** avoir la **`sts:AssumeRole`** sur le rôle.
> Avec une exception : pour **assumer un rôle dans un autre compte** le compte de l'attaquant **doit également** disposer de la **`sts:AssumeRole`** sur le rôle.
### `sts:AssumeRoleWithSAML`
Une trust policy pour ce rôle permet **aux utilisateurs authentifiés via SAML de se faire passer pour le rôle.**
Une trust policy associée à ce rôle accorde **aux utilisateurs authentifiés via SAML l'accès pour usurper le rôle.**
Un exemple de trust policy avec cette permission est:
```json
@@ -59,21 +59,21 @@ Un exemple de trust policy avec cette permission est:
]
}
```
Pour générer des credentials pour impersonate le role, vous pouvez généralement utiliser quelque chose comme :
Pour générer des identifiants pour usurper le rôle, en général vous pouvez 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](https://github.com/onelogin/onelogin-python-aws-assume-role):
Mais **les fournisseurs** peuvent proposer **leurs propres outils** pour rendre cela plus facile, comme [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-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 to the role.
**Impact potentiel :** Privesc au rôle.
### `sts:AssumeRoleWithWebIdentity`
Cette permission permet d'obtenir un ensemble d'identifiants temporaires de sécurité pour **les utilisateurs qui ont été authentifiés dans une application mobile, une application web, EKS...** via un fournisseur d'identité web. [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
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, une application web, EKS...** avec un fournisseur d'identité web. [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
Par exemple, si un **EKS service account** doit pouvoir **impersonate an IAM role**, il aura un token dans **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** et pourra **assume the role and get credentials** en faisant quelque chose comme :
Par exemple, si un **compte de service EKS** doit 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 :
```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
@@ -86,9 +86,13 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
### IAM Roles Anywhere Privesc
AWS IAM RolesAnywhere permet à des workloads externes à AWS d'assumer des rôles IAM en utilisant des certificats X.509. Mais lorsque les trust policies ne sont pas correctement restreintes, elles peuvent être abusées pour privilege escalation.
AWS IAM RolesAnywhere permet à des workloads situés en dehors d'AWS d'assumer des IAM roles en utilisant des certificats X.509. Mais lorsque les politiques de confiance ne sont pas correctement limitées, elles peuvent être abusées pour une escalation de privilèges.
Cette policy n'impose pas de restrictions sur quel trust anchor ou quels attributs de certificat sont autorisés. En conséquence, tout certificat lié à n'importe quel trust anchor du compte peut être utilisé pour assumer ce rôle.
Pour comprendre cette attaque, il est nécessaire d'expliquer ce qu'est une trust anchor. Une trust anchor dans AWS IAM RolesAnywhere est l'entité racine de confiance : elle 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 la trust anchor est active, AWS le reconnaît comme valide.
De plus, un profil est la configuration qui définit quels attributs du certificat X.509 (comme CN, OU ou SAN) seront transformés en tags de session, et ces tags seront ensuite comparés aux conditions de la politique de confiance.
Cette politique n'impose pas de restrictions sur les trust anchors ou les attributs de certificat autorisés. En conséquence, tout certificat lié à n'importe quelle trust anchor du compte peut être utilisé pour assumer ce rôle.
```json
{
"Version": "2012-10-17",
@@ -108,9 +112,9 @@ Cette policy n'impose pas de restrictions sur quel trust anchor ou quels attribu
}
```
Pour privesc, l'`aws_signing_helper` est requis depuis https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
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 un rôle à privilèges supérieurs
Ensuite, en utilisant un certificat valide, l'attaquant peut pivoter vers un rôle de privilèges supérieurs.
```bash
aws_signing_helper credential-process \
--certificate readonly.pem \
@@ -119,11 +123,11 @@ aws_signing_helper credential-process \
--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 sa CA autorisée ; lorsque l'ancre de confiance a été créée, le certificat public de la CA a été inclus (et est maintenant utilisé pour valider `readonly.pem`). À l'intérieur de `readonly.pem` se trouve la clé publique, qu'AWS utilise pour vérifier que la signature a été réalisée avec sa clé privée correspondante `readonly.key`.
L'ancre de confiance valide que le certificat `readonly.pem` du client provient de sa CA autorisée, et à l'intérieur de 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 prouve également l'identité et fournit des attributs (tels que CN ou OU) que le profil `default` transforme en tags, que la trust policy du rôle peut utiliser pour décider d'autoriser l'accès ; s'il n'y a pas de conditions dans la trust policy, ces tags sont ignorés et toute personne disposant d'un certificat valide est autorisée.
Le certificat fournit également des attributs (comme CN ou OU) que le profil `default` transforme en tags, que la trust policy du rôle peut utiliser pour décider d'autoriser l'accès. S'il n'y a pas de conditions dans la trust policy, ces tags sont inutiles et l'accès est accordé à toute personne disposant d'un certificat valide.
Pour que cette attaque soit possible, l'ancre de confiance et le profil `default` doivent tous deux être actifs.
Pour que cette attaque soit possible, l'ancre de confiance et le profil `default` doivent être actifs.
### Références