Atlantis Security
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 atlantisVocê 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 nesses 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 de 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 vai estar expondo webhooks para que o servidor git possa enviar informações. Do ponto de vista de um atacante, seria interessante saber se é possível enviar mensagens.
Credenciais do Provedor
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")
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 desbloqueie-os (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
ouallow_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 (pre workflow hooks) e depois (post workflow hooks) da execução de um workflow.
Não há opção para permitir especificar esses scripts no arquivo /atlantis.yml
do repositório.
Workflow
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 fluxos de trabalho 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á utilizado.
Isso basicamente dará RCE no servidor Atlantis para qualquer usuário que possa acessar esse repositório.
Verificação de Políticas Conftest
O Atlantis suporta a execução de políticas conftest no 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 não intencionais de recursos
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:
Ataques
Se durante a exploração você encontrar este erro: Error: Error acquiring the state lock
Você pode corrigi-lo executando:
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
:
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:
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:
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 burlas 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
:
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 está sendo executado por baixo dos panos, você pode passar comandos para o terraform a partir do atlantis comentando algo como:
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
. O 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.
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.
Sequestro de PR
Se alguém enviar comentários atlantis plan/apply
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 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 TerraformExemplo: /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 doatlantis 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
--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
--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. Veja 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 extrair 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 de 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 etapa
plan
da configuração do repositório do lado do servidor para validar contra o uso de provedores ou fontes de dados proibidos ou PRs de usuários não permitidos. Você também poderia adicionar validação extra neste ponto, por exemplo, exigindo um "joinha" na PR antes de permitir que oplan
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 do 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 uma 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
Last updated