Pentesting CI/CD Methodology

Reading time: 8 minutes

VCS

VCS significa Sistema de Controle de Versão, esses sistemas permitem aos desenvolvedores gerenciar seu código-fonte. O mais comum é git e normalmente você encontrará empresas usando-o em uma das seguintes plataformas:

• Github
• Gitlab
• Bitbucket
• Gitea
• Gitblit
• Fornecedores de cloud (eles oferecem suas próprias plataformas VCS)

CI/CD Pipelines

As pipelines CI/CD permitem que desenvolvedores automatizem a execução de código para vários fins, incluindo build, testes e deploy de aplicações. Esses fluxos de trabalho automatizados são acionados por ações específicas, como pushes de código, pull requests ou tarefas agendadas. Eles são úteis para agilizar o processo do desenvolvimento até a produção.

No entanto, esses sistemas precisam ser executados em algum lugar e geralmente com credenciais privilegiadas para deploy de código ou acesso a informações sensíveis.

VCS Pentesting Methodology

Plataformas que contêm o código-fonte do seu projeto guardam 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 nas plataformas VCS que um atacante poderia abusar:

• Leaks: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks.
• Access: Se um atacante puder acessar uma conta dentro da plataforma VCS ele poderia obter mais visibilidade e permissões.
• Register: Algumas plataformas simplesmente permitem que usuários externos criem uma conta.
• SSO: Algumas plataformas não permitem registros, mas permitem que qualquer pessoa acesse com um SSO válido (então um atacante poderia usar sua conta do github para entrar, por exemplo).
• Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... existem vários tipos de tokens que um usuário pode roubar para acessar de alguma forma um repo.
• Webhooks: Plataformas VCS permitem gerar webhooks. Se não estiverem protegidos com segredos não visíveis, um atacante pode abusar deles.
• Se não houver segredo em vigor, o atacante poderia abusar do webhook da plataforma terceira
• Se o segredo estiver na URL, o mesmo acontece e o atacante também terá o segredo
• Code compromise: Se um ator malicioso tiver algum tipo de acesso de escrita aos repos, ele poderia tentar injetar código malicioso. Para ter sucesso, pode precisar bypassar branch protections. Essas ações podem ser realizadas com diferentes objetivos:
• Comprometer a branch principal para comprometer a produção.
• Comprometer a branch principal (ou outras branches) para comprometer máquinas dos desenvolvedores (já que eles costumam executar testes, terraform ou outras coisas do repo em suas máquinas).
• Comprometer a pipeline (veja a próxima seção)

Pipelines Pentesting Methodology

A maneira mais comum de definir uma pipeline é usando um arquivo de configuração CI hospedado no repositório que a pipeline constrói. Esse arquivo descreve a ordem dos jobs executados, condições que afetam o fluxo e configurações do ambiente de build.
Esses arquivos tipicamente têm um nome e formato consistente, 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 job da pipeline puxa o código da fonte selecionada (por ex. 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 - Poisoned Pipeline Execution

O caminho Poisoned Pipeline Execution (PPE) explora permissões em um repositório SCM para manipular uma pipeline CI e executar comandos maliciosos. Usuários com as permissões necessárias podem modificar arquivos de configuração CI ou outros arquivos usados pelo job da pipeline para incluir comandos maliciosos. Isso "envenena" a pipeline CI, levando à execução desses comandos maliciosos.

Para que um ator malicioso tenha sucesso realizando um ataque PPE ele precisa ser capaz de:

• Ter acesso de escrita à plataforma VCS, já que geralmente as pipelines são acionadas quando um push ou pull request é realizado. (Consulte a VCS pentesting methodology para um resumo das formas de obter acesso).
• Note que às vezes um PR externo conta como "acesso de escrita".
• Mesmo que 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, pode ser necessário bypassar branch protections.

Existem 3 variantes de PPE:

• D-PPE: Um ataque Direct PPE ocorre quando o ator modifica o arquivo de configuração CI que será executado.
• I-DDE: Um ataque Indirect PPE ocorre quando o ator modifica um arquivo do qual o arquivo de configuração CI que será executado depende (como um makefile ou uma configuração terraform).
• Public PPE ou 3PE: Em alguns casos as pipelines podem ser acionadas por usuários que não têm acesso de escrita no repo (e que podem nem fazer parte da org) porque podem enviar um PR.
• 3PE Command Injection: Normalmente, pipelines CI/CD vã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 local perigoso (como executar comandos sh), um atacante pode injetar comandos ali.

Exploitation Benefits

Conhecendo as 3 variantes para envenenar uma pipeline, vejamos o que um atacante poderia obter após uma exploração bem-sucedida:

• Secrets: Como mencionado anteriormente, pipelines requerem privilégios para seus jobs (retrair o código, build, deploy...) e esses privilégios geralmente são concedidos em secrets. Esses secrets normalmente são acessíveis via env variables ou arquivos dentro do sistema. Portanto um atacante sempre tentará exfiltrar o máximo possível de secrets.
• Dependendo da plataforma de pipeline o atacante pode precisar especificar os secrets na config. Isso significa que, se o atacante não puder modificar a configuração CI da pipeline (I-PPE por exemplo), ele poderia apenas exfiltrar os secrets que essa pipeline possui.
• Computation: O código é executado em algum lugar; dependendo de onde é executado, um atacante pode ser capaz de pivotar mais adiante.
• On-Premises: Se as pipelines são executadas on-premises, um atacante pode terminar em uma rede interna com acesso a mais recursos.
• Cloud: O atacante poderia acessar outras máquinas na cloud mas também poderia exfiltrar tokens de IAM roles/service accounts dela para obter acesso adicional dentro da cloud.
• Platforms machine: Às vezes os jobs serão executados dentro das máquinas da plataforma de pipelines, que geralmente estão numa cloud sem acesso adicional.
• Select it: Às vezes a plataforma de pipelines terá várias máquinas configuradas e se você puder modificar o arquivo de configuração CI você pode indicar onde quer rodar o código malicioso. Nessa situação, um atacante provavelmente executará um reverse shell em cada máquina possível para tentar explorá-la mais a fundo.
• Compromise production: Se você estiver dentro da pipeline e a versão final for buildada e deployada a partir dela, você poderia comprometer o código que acabará rodando em produção.

More relevant info

Tools & CIS Benchmark

• Chain-bench é uma ferramenta open-source para auditar sua cadeia de suprimentos de software quanto à conformidade de segurança com base em um novo CIS Software Supply Chain benchmark. A auditoria foca em todo o processo SDLC, onde pode revelar riscos desde o tempo de código até o tempo de deploy.

Top 10 CI/CD Security Risk

Confira este artigo interessante sobre os top 10 riscos CI/CD segundo a Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

• Em cada plataforma que você puder rodar localmente você encontrará como lançá-la localmente para poder configurá-la como quiser para testar
• Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat

Automatic Tools

• Checkov: Checkov é uma ferramenta de análise estática para infrastructure-as-code.

References

• https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422