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

2026-02-04 11:07:37 -08:00 · 2025-09-29 22:32:02 +00:00
parent 5ee4305a10
commit 2f8174d95d
2 changed files with 43 additions and 46 deletions
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
@@ -10,14 +10,14 @@ Pour plus d'informations :
 ../aws-services/aws-iam-enum.md
 {{#endref}}

-### Des identifiants IAM à la console
+### De IAM Creds vers Console

-Si vous avez réussi à obtenir des identifiants IAM, vous pourriez être intéressé par **l'accès à la console web** en utilisant les outils suivants.\
-Notez que l'utilisateur/le rôle doit avoir la permission **`sts:GetFederationToken`**.
+Si vous avez réussi à obtenir des IAM credentials, vous pourriez être intéressé par l'accès au web console en utilisant les outils suivants.\
+Notez que le user/role doit avoir la permission **`sts:GetFederationToken`**.

 #### Script personnalisé

-Le script suivant utilisera le profil par défaut et un emplacement AWS par défaut (ni gov ni cn) pour vous donner une URL signée que vous pouvez utiliser pour vous connecter à la console web :
+Le script suivant utilisera le profile par défaut et une région AWS par défaut (pas gov et pas cn) pour vous fournir une URL signée que vous pouvez utiliser pour vous connecter au web console:
 ```bash
 # Get federated creds (you must indicate a policy or they won't have any perms)
 ## Even if you don't have Admin access you can indicate that policy to make sure you get all your privileges
@@ -55,7 +55,7 @@ echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.co
 ```
 #### aws_consoler

-Vous pouvez **générer un lien de console web** avec [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler).
+Vous pouvez **générer un lien vers la console web** avec [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler).
 ```bash
 cd /tmp
 python3 -m venv env
@@ -64,7 +64,7 @@ pip install aws-consoler
 aws_consoler [params...] #This will generate a link to login into the console
 ```
 > [!WARNING]
-> Assurez-vous que l'utilisateur IAM a la permission `sts:GetFederationToken`, ou fournissez un rôle à assumer.
+> Assurez-vous que l'utilisateur IAM dispose de l'autorisation `sts:GetFederationToken`, ou fournissez un rôle à assumer.

 #### aws-vault

@@ -75,11 +75,11 @@ aws-vault exec jonsmith -- aws s3 ls # Execute aws cli with jonsmith creds
 aws-vault login jonsmith # Open a browser logged as jonsmith
 ```
 > [!NOTE]
-> Vous pouvez également utiliser **aws-vault** pour obtenir une **session de console de navigateur**
+> Vous pouvez aussi utiliser **aws-vault** pour obtenir une **browser console session**

 ### **Contourner les restrictions User-Agent depuis Python**

-S'il y a une **restriction pour effectuer certaines actions en fonction de l'agent utilisateur** utilisé (comme restreindre l'utilisation de la bibliothèque python boto3 en fonction de l'agent utilisateur), il est possible d'utiliser la technique précédente pour **se connecter à la console web via un navigateur**, ou vous pourriez directement **modifier l'agent utilisateur de boto3** en faisant :
+S'il existe une **restriction empêchant d'effectuer certaines actions en fonction du user agent** utilisé (comme restreindre l'utilisation de la librairie python boto3 selon le user agent), il est possible d'utiliser la technique précédente pour **vous connecter à la web console via un browser**, ou vous pouvez directement **modifier le boto3 user-agent** en faisant :
 ```bash
 # Shared by ex16x41
 # Create a client
@@ -92,4 +92,14 @@ client.meta.events.register( 'before-call.secretsmanager.GetSecretValue', lambda
 # Perform the action
 response = client.get_secret_value(SecretId="flag_secret") print(response['SecretString'])
 ```
+### **`sts:GetFederationToken`**
+
+Avec cette permission, il est possible de créer une identité fédérée pour l'utilisateur qui l'exécute, limitée aux permissions dont dispose cet utilisateur.
+```bash
+aws sts get-federation-token --name <username>
+```
+Le token renvoyé par sts:GetFederationToken appartient à l'identité fédérée de l'utilisateur appelant, mais avec des permissions restreintes. Même si l'utilisateur dispose de droits d'administrateur, certaines actions, telles que la liste des IAM users ou l'attachement de policies, ne peuvent pas être effectuées via le token fédéré.
+
+De plus, cette méthode est un peu plus discrète, puisque l'utilisateur fédéré n'apparaît pas dans l'AWS Portal ; il ne peut être observé que via les CloudTrail logs ou des outils de monitoring.
+
 {{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
@@ -6,9 +6,9 @@

 ### `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**).
+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**).

-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.
+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.
 ```json
 {
 "Version": "2012-10-17",
@@ -23,41 +23,22 @@ Par exemple, la politique de confiance de rôle suivante indique que tout le mon
 ]
 }
 ```
-Vous pouvez usurper un rôle exécutant :
+Vous pouvez usurper un rôle en exécutant :
 ```bash
 aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
 ```
-**Impact potentiel :** Privesc au rôle.
+**Impact potentiel :** Privesc vers 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 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.
+> 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.

-### **`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.**
+Une trust policy pour ce rôle permet **aux utilisateurs authentifiés via SAML de se faire passer pour le rôle.**

-Un exemple d'une politique de confiance avec cette permission est :
+Un exemple de trust policy avec cette permission est:
 ```json
 {
 "Version": "2012-10-17",
@@ -78,36 +59,36 @@ Un exemple d'une politique de confiance avec cette permission est :
 ]
 }
 ```
-Pour générer des identifiants afin d'usurper le rôle, vous pourriez utiliser quelque chose comme :
+Pour générer des credentials pour impersonate le role, vous pouvez généralement 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 avoir leurs **propres outils** pour faciliter cela, 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 au rôle.
+**Impact potentiel:** Privesc to the role.

 ### `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.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
+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)

-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 :
+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 :
 ```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
+### Federation Abuse

 {{#ref}}
 ../aws-basic-information/aws-federation-abuse.md
 {{#endref}}

-### Privesc IAM Roles Anywhere
+### IAM Roles Anywhere Privesc

-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.
+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.

-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.
+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.
 ```json
 {
 "Version": "2012-10-17",
@@ -127,9 +108,9 @@ Cette politique manque de restrictions sur les ancres de confiance ou les attrib
 }

 ```
-Pour privesc, le `aws_signing_helper` est requis depuis https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
+Pour privesc, l'`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.
+Ensuite, en utilisant un certificat valide, l'attaquant peut pivoter vers un rôle à privilèges supérieurs
 ```bash
 aws_signing_helper credential-process \
 --certificate readonly.pem \
@@ -138,6 +119,12 @@ 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`.
+
+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.
+
+Pour que cette attaque soit possible, l'ancre de confiance et le profil `default` doivent tous deux être actifs.
+
 ### Références

 - [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)