Atlantis Security
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Atlantis basicamente ajuda você a executar terraform a partir de Pull Requests do seu servidor git.
Vá para a página de lançamentos do atlantis em https://github.com/runatlantis/atlantis/releases e baixe a que melhor se adequa a você.
Crie um token pessoal (com acesso ao repositório) do seu usuário github.
Execute ./atlantis testdrive e isso criará um repositório de demonstração que você pode usar para conversar com atlantis.
Você pode acessar a página da web em 127.0.0.1:4141.
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 Atlantis, mas algumas pessoas podem usar contas pessoais.
De qualquer forma, do ponto de vista de um atacante, a conta do Atlantis será uma interessante para comprometer.
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.
Atlantis estará expondo webhooks para que o servidor git possa enviar informações. Do ponto de vista de um atacante, seria interessante saber se você pode enviar mensagens para ele.
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:
AWS EC2 Roles (Pesquise por "EC2 Role")
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.
O container onde o Atlantis está executando provavelmente contém credenciais privilegiadas para os provedores (AWS, GCP, Github...) que o Atlantis está gerenciando via Terraform.
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).
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:
Flags
Variáveis de Ambiente
Arquivo de Configuração
Observe que na configuração você pode encontrar valores interessantes, como tokens e senhas.
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 ser permitido por flags como allowed_overrides ou allow_custom_workflows.
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).
Valores padrão.
PR Protections
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.
Se a flag configuração do lado do servidor allow_custom_workflows estiver definida como True, workflows podem ser especificados no arquivo atlantis.yaml de cada repositório. Também pode ser necessário que allowed_overrides especifique também workflow para sobrescrever o workflow que será usado.
Isso basicamente dará RCE no servidor Atlantis para qualquer usuário que puder acessar esse repositório.
Verificação de Políticas do Conftest
Atlantis suporta a execução de políticas do conftest server-side 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 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.
Na documentação você pode encontrar as opções que pode usar para executar o Atlantis:
Se durante a exploração você encontrar este erro: Error: Error acquiring the state lock
Você pode corrigir isso executando:
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 Atlantis carregar uma fonte de dados externa. Basta colocar um payload como o seguinte no arquivo main.tf:
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:
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.
Você pode dump secrets usados pelo terraform executando atlantis plan (terraform plan) colocando algo assim no arquivo terraform:
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 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 o PR for mesclável (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 o 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:
Siga as sugestões da técnica anterior para realizar este ataque de uma maneira mais furtiva.
Ao executar atlantis plan ou atlantis apply, o terraform está sendo executado sob, 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
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:
Se a flag de configuração do lado do servidor allow_custom_workflows estiver definida como True, fluxos de trabalho podem ser especificados no arquivo atlantis.yaml de cada repositório. Também pode ser necessário que allowed_overrides especifique também workflow para substituir o fluxo de trabalho que será utilizado.
Isso basicamente dará RCE no servidor Atlantis para qualquer usuário que possa acessar esse repositório.
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.
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 é 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:
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.
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).
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)
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.
--allow-fork-prsSe você estiver executando em um repositório público (o que não é recomendado, veja acima), você não deve definir --allow-fork-prs (o padrão é falso) porque qualquer um pode abrir um pull request de seu fork para o seu repositório.
--repo-allowlistO 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.
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:
Incorporar provedores na imagem do Atlantis ou hospedar e negar egress em produção.
Implementar o protocolo de registro de provedores internamente e negar egress público, assim você controla quem tem acesso de escrita ao registro.
Modificar o passo plan da sua configuração de repositório do lado do servidor 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.
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.
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.
Se você estiver usando webhook secrets, mas seu tráfego for via HTTP, então os webhook secrets poderiam ser roubados. Ative SSL/HTTPS usando as flags --ssl-cert-file e --ssl-key-file.
É 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.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
