Pentesting CI/CD Methodology
VCS
VCS significa Sistema de Controle de Versão, esses sistemas permitem que desenvolvedores gerenciem seu código-fonte. O mais comum é o git e geralmente você 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 desenvolvedores automatizem a execução do código (para construir, testar, implantar... fins) após certas ações ocorrerem: Um push, um PR, cron... Eles são extremamente úteis para automatizar todos os passos do desenvolvimento à produção.
No entanto, esses sistemas precisam ser executados em algum lugar e geralmente com credenciais privilegiadas para implantar o código.
Metodologia de Pentesting VCS
Mesmo que algumas plataformas VCS permitam criar pipelines, para esta 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 desta plataforma. Estes são alguns problemas comuns nas plataformas VCS que um atacante poderia abusar:
Vazamentos: Se o seu código contém vazamentos nos commits e o atacante pode acessar o repositório (porque é público ou porque ele tem acesso), ele poderia descobrir os vazamentos.
Acesso: Se um atacante pode acessar uma conta dentro da plataforma VCS ele poderia ganhar mais visibilidade e permissões.
Registro: Algumas plataformas simplesmente permitem que usuários externos criem uma conta.
SSO: Algumas plataformas não permitem que usuários se registrem, mas permitem 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 tem o segredo
Comprometimento do código: Se um ator malicioso tem algum tipo de acesso de escrita sobre os repositórios, ele poderia tentar injetar código malicioso. Para ser bem-sucedido, ele pode precisar burlar 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 branch 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)
Metodologia de Pentesting de Pipelines
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 seja bem-sucedido realizando 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. (Verifique a metodologia de pentesting VCS para um resumo das maneiras de obter acesso).
Observe 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 nos quais a configuração depende.
Para isso, ele pode precisar ser capaz de burlar proteções de branch.
Existem 3 sabores de PPE:
D-PPE: Um ataque PPE Direto ocorre quando o ator modifica o arquivo de configuração CI que vai ser executado.
I-DDE: Um ataque PPE Indireto ocorre quando o ator modifica um arquivo no qual o arquivo de configuração CI que vai 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 eles podem enviar um PR.
Injeção de Comando 3PE: Geralmente, pipelines CI/CD irão definir 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 executando comandos sh), um atacante pode injetar comandos lá.
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 foi mencionado anteriormente, pipelines requerem privilégios para seus trabalhos (recuperar o código, construí-lo, implantá-lo...) e esses privilégios são geralmente 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 aquele pipeline tem.
Computação: O código é executado em algum lugar, dependendo de onde é executado, um atacante pode ser capaz de pivotar ainda 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 IAM tokens dela 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 sem mais acesso.
Selecioná-la: Às vezes, a plataforma de pipelines terá configurado várias máquinas e se você pode modificar o arquivo de configuração CI você pode indicar onde você quer 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 ainda 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 vai acabar rodando em produção.
Mais informações relevantes
Ferramentas & Benchmark CIS
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 CIS Software Supply Chain. A auditoria foca em todo o processo de 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/
Laboratórios
Em cada plataforma que você pode executar localmente, você encontrará como lançá-la localmente para que você possa configurá-la como quiser para testá-la
Laboratório Gitea + Jenkins: 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
Última actualización
