Pentesting CI/CD Methodology
VCS
VCS significa Sistema de Controle de Versão, esses sistemas permitem que os desenvolvedores gerenciem seu código-fonte. O mais comum é o git e você geralmente encontrará empresas usando-o em uma das seguintes plataformas:
Github
Gitlab
Bitbucket
Gitea
Provedores de nuvem (eles oferecem suas próprias plataformas VCS)
Pipelines
Pipelines permitem que os desenvolvedores automatizem a execução de código (para construção, teste, implantação... propósitos) após certas ações ocorrerem: Um push, um PR, cron... Eles são extremamente úteis para automatizar todas as etapas do desenvolvimento à produção.
No entanto, esses sistemas precisam ser executados em algum lugar e geralmente com credenciais privilegiadas para implantar código.
VCS Pentesting Methodology
Mesmo que algumas plataformas VCS permitam criar pipelines, nesta seção vamos analisar apenas ataques potenciais ao controle do código-fonte.
Plataformas que contêm o código-fonte do seu projeto contêm informações sensíveis e as pessoas precisam ter muito cuidado com as permissões concedidas dentro dessa plataforma. Estes são alguns problemas comuns em plataformas VCS que um atacante poderia explorar:
Leaks: Se seu código contém leaks nos commits e o atacante pode acessar o repositório (porque é público ou porque ele tem acesso), ele poderia descobrir os leaks.
Acesso: Se um atacante pode acessar uma conta dentro da plataforma VCS, ele poderia ganhar mais visibilidade e permissões.
Registro: Algumas plataformas permitirão apenas que usuários externos criem uma conta.
SSO: Algumas plataformas não permitirão que os usuários se registrem, mas permitirão que qualquer um acesse com um SSO válido (então um atacante poderia usar sua conta do github para entrar, por exemplo).
Credenciais: Nome de usuário + Senha, tokens pessoais, chaves ssh, tokens Oauth, cookies... existem vários tipos de tokens que um usuário poderia roubar para acessar de alguma forma um repositório.
Webhooks: Plataformas VCS permitem gerar webhooks. Se eles não estiverem protegidos com segredos não visíveis, um atacante poderia abusar deles.
Se nenhum segredo estiver em vigor, o atacante poderia abusar do webhook da plataforma de terceiros.
Se o segredo estiver na URL, o mesmo acontece e o atacante também terá o segredo.
Comprometimento de código: Se um ator malicioso tiver algum tipo de acesso de escrita sobre os repositórios, ele poderia tentar injetar código malicioso. Para ter sucesso, ele pode precisar contornar as proteções de branch. Essas ações podem ser realizadas com diferentes objetivos em mente:
Comprometer a branch principal para comprometer a produção.
Comprometer a principal (ou outras branches) para comprometer as máquinas dos desenvolvedores (já que eles geralmente executam testes, terraform ou outras coisas dentro do repositório em suas máquinas).
Comprometer o pipeline (ver próxima seção)
Pipelines Pentesting Methodology
A maneira mais comum de definir um pipeline é usando um arquivo de configuração CI hospedado no repositório que o pipeline constrói. Este arquivo descreve a ordem dos trabalhos executados, condições que afetam o fluxo e configurações do ambiente de construção. Esses arquivos geralmente têm um nome e formato consistentes, por exemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) e os arquivos YAML do GitHub Actions localizados em .github/workflows. Quando acionado, o trabalho do pipeline puxa o código da fonte selecionada (por exemplo, commit / branch) e executa os comandos especificados no arquivo de configuração CI contra esse código.
Portanto, o objetivo final do atacante é de alguma forma comprometer esses arquivos de configuração ou os comandos que eles executam.
PPE - Execução de Pipeline Envenenado
O caminho de Execução de Pipeline Envenenado (PPE) explora permissões em um repositório SCM para manipular um pipeline CI e executar comandos prejudiciais. Usuários com as permissões necessárias podem modificar arquivos de configuração CI ou outros arquivos usados pelo trabalho do pipeline para incluir comandos maliciosos. Isso "envenena" o pipeline CI, levando à execução desses comandos maliciosos.
Para que um ator malicioso tenha sucesso ao realizar um ataque PPE, ele precisa ser capaz de:
Ter acesso de escrita à plataforma VCS, já que geralmente os pipelines são acionados quando um push ou um pull request é realizado. (Ver a metodologia de pentesting VCS para um resumo das maneiras de obter acesso).
Note que às vezes um PR externo conta como "acesso de escrita".
Mesmo que ele tenha permissões de escrita, ele precisa ter certeza de que pode modificar o arquivo de configuração CI ou outros arquivos dos quais a configuração depende.
Para isso, ele pode precisar ser capaz de contornar as proteções de branch.
Existem 3 sabores de PPE:
D-PPE: Um ataque Direto PPE ocorre quando o ator modifica o arquivo de configuração CI que será executado.
I-DDE: Um ataque Indireto PPE ocorre quando o ator modifica um arquivo do qual o arquivo de configuração CI que será executado depende (como um arquivo make ou uma configuração terraform).
PPE Público ou 3PE: Em alguns casos, os pipelines podem ser acionados por usuários que não têm acesso de escrita no repositório (e que podem nem mesmo fazer parte da organização) porque podem enviar um PR.
Injeção de Comando 3PE: Geralmente, pipelines CI/CD definirão variáveis de ambiente com informações sobre o PR. Se esse valor puder ser controlado por um atacante (como o título do PR) e for usado em um lugar perigoso (como executar comandos sh), um atacante pode injetar comandos ali.
Benefícios da Exploração
Conhecendo os 3 sabores para envenenar um pipeline, vamos verificar o que um atacante poderia obter após uma exploração bem-sucedida:
Segredos: Como mencionado anteriormente, os pipelines requerem privilégios para seus trabalhos (recuperar o código, construí-lo, implantá-lo...) e esses privilégios geralmente são concedidos em segredos. Esses segredos geralmente são acessíveis via variáveis de ambiente ou arquivos dentro do sistema. Portanto, um atacante sempre tentará exfiltrar o máximo de segredos possível.
Dependendo da plataforma do pipeline, o atacante pode precisar especificar os segredos na configuração. Isso significa que se o atacante não puder modificar o pipeline de configuração CI (I-PPE, por exemplo), ele poderia apenas exfiltrar os segredos que esse pipeline possui.
Computação: O código é executado em algum lugar, dependendo de onde é executado, um atacante pode ser capaz de pivotar mais.
On-Premises: Se os pipelines são executados localmente, um atacante pode acabar em uma rede interna com acesso a mais recursos.
Nuvem: O atacante poderia acessar outras máquinas na nuvem, mas também poderia exfiltrar tokens de contas de serviço/roles IAM para obter mais acesso dentro da nuvem.
Máquina da plataforma: Às vezes, os trabalhos serão executados dentro das máquinas da plataforma de pipelines, que geralmente estão dentro de uma nuvem com nenhum acesso adicional.
Selecione-o: Às vezes, a plataforma de pipelines terá várias máquinas configuradas e se você puder modificar o arquivo de configuração CI, poderá indicar onde deseja executar o código malicioso. Nessa situação, um atacante provavelmente executará um shell reverso em cada máquina possível para tentar explorá-la mais.
Comprometer a produção: Se você estiver dentro do pipeline e a versão final for construída e implantada a partir dele, você poderia comprometer o código que acabará sendo executado em produção.
Mais informações relevantes
Ferramentas & CIS Benchmark
Chain-bench é uma ferramenta de código aberto para auditar sua pilha de cadeia de suprimentos de software para conformidade de segurança com base em um novo benchmark de Segurança da Cadeia de Suprimentos de Software CIS. A auditoria foca em todo o processo SDLC, onde pode revelar riscos desde o tempo de código até o tempo de implantação.
Top 10 Riscos de Segurança CI/CD
Confira este artigo interessante sobre os 10 principais riscos de CI/CD de acordo com a Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/
Labs
Em cada plataforma que você pode executar localmente, você encontrará como lançá-la localmente para que possa configurá-la como quiser para testá-la.
Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat
Ferramentas Automáticas
Checkov: Checkov é uma ferramenta de análise de código estático para infraestrutura como código.
Referências
Last updated
