Integração Contínua e Implantação Contínua (CI/CD) pipelines desempenham um papel fundamental na facilitação do desenvolvimento simplificado de software. Ainda assim, como estes pipelines se tornam cada vez mais cruciais, o imperativo de protegê-los de vulnerabilidades se torna mais pronunciado. Esta investigação aprofundada se concentra em abordar um risco proeminente identificado no OWASP Top-10 CI/CD Riscos de segurança: envenenado Pipeline Execução (EPI).
O que está envenenado Pipeline Execução (EPI)
De acordo com o OWASP Top-10 CI/CD Riscos de segurança, “Envenenado Pipeline Execução (EPP) risco refere-se à capacidade de um invasor com acesso a sistemas de controle de origem – e sem acesso ao ambiente de construção – manipular o processo de construção injetando códigos/comandos maliciosos na construção pipeline • Configuração, essencialmente 'envenenando' o pipeline e execução de código malicioso como parte do processo de construção”
Em poucas palavras, envenenado Pipeline A execução (EPI) é produzida quando o invasor pode modificar o pipeline lógica.
Há dois variantes:
- EPI direto (D-EPI): Em um cenário D-PPE, o invasor modifica o arquivo de configuração do CI em um repositório ao qual eles têm acesso, seja enviando a alteração diretamente para uma ramificação remota desprotegida no repositório ou enviando um PR com a alteração de uma ramificação ou bifurcação. Desde o CI pipeline a execução for definida pelos comandos no arquivo de configuração do CI modificado, os comandos maliciosos do invasor serão executados no nó de compilação assim que a compilação pipeline é acionado.
- EPI indireto (I-EPI): Em certos casos, a possibilidade de D-PPE não está disponível para um adversário com acesso a um SCM repositório (por exemplo, se o pipeline está configurado para extrair o arquivo de configuração do CI de uma ramificação separada e protegida no mesmo repositório). Nesse cenário, em vez de envenenar o pipeline em si, um invasor injeta código malicioso em arquivos referenciados pelo pipeline (por exemplo: scripts referenciados dentro do pipeline arquivo de configuração)
Em ambos os casos, GitHub executará o modificado pipeline sem necessidade de revisão ou aprovação prévia.
Detecção precoce de EPI
Como podemos detectar esse tipo de vulnerabilidade?
Vamos ver este exemplo pipeline :
name: PR CI
on:
pull_request:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
jobs:
pr_build_test_and_merge:
runs-on: ubuntu-latest
steps:
# checkout PR code
- name: Checkout repository
uses: actions/checkout@v4
# Simulation of a compilation
- name: Building ...
run: |
echo $MY_SECRET
mkdir ./bin
touch ./bin/mybin.exe
# Simulation of running tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh "${{ github.event.pull_request.user.Conecte-se }}" "${{ github.workflow }}"
echo Tests executed. E o conteúdo de um script de shell fictício (runtests.sh):
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0O processo de pipeline é bastante simples: seu objetivo é fornecer ao revisor algumas dicas preliminares para o Pull Request Processo de aceitação (RP):
- Será acionado em pull_request (ou seja, sempre que um PR é criado)
- Ele verifica o código PR (ou seja, o código contribuído)
- Isso fará com que a construção
- Ele executará testes no código contribuído (por exemplo, executando um script shell)
As etapas 3 (fazer a compilação) e 4 (executar o teste) falharão se o código não for compilado ou não passar nos testes. Portanto, essas etapas funcionam como condição necessária, mas não suficiente, para aceitar o PR. Se for bem-sucedido, o administrador do repo procederá à revisão do código contribuído e, com base nisso, aceitará/rejeitará/comentará o PR.
Scanner Xygeni
Xygeni fornece uma CLI (o “Scanner Xygeni”) que pode ser incorporado em um pipeline ou execute em uma linha de comando. O Xygeni Scanner processará o pipelines para verificar vulnerabilidades e, se um GitHub PAT for fornecido, ele se conectará ao GitHub para descobrir vulnerabilidades no nível organizacional/repo.
Inventário Xygeni
Quando executamos o Xygeni Scanner neste repositório, ele descobre um conjunto útil de ativos (o Inventário Xygeni). O inventário será preenchido com muitos tipos diferentes de CI/CD ativos, Tais como:
- O processo de SCM System onde o repositório está armazenado
- O processo de SCM Plugins instalado/usado
- O processo de Repositório de código se
- O processo de SCM Organização onde o repo pertence
- O processo de CI/CD Pipelinese empregos
- O processo de CI/CD System executando o pipelines
- IaC Regal definido no repositório
- Externo Dependências
- etc ..
Em nosso exemplo, podemos filtrar o inventário por algum tipo de ativo específico (SCM- e ativos relacionados ao CICD), então podemos ver que:
- SCM sistema é GitHub Cloud
- O repositório é armazenado no GitHub Cloud e pertence a uma organização GitHub específica
- Há dois pipelines alimentado pelo GitHub (CI/CD sistema)
- Cada pipeline contém uma etapa específica
Ao selecionar o acima pipeline podemos ver algumas vulnerabilidades:
- At pipeline nível, é vulnerável a ambos direto e EPI indireto.
Podemos ver os detalhes daqueles envenenados Pipeline Vulnerabilidades de execução
Xygeni detecta que é vulnerável ao D-PPE porque é acionado em um Pull Request evento e não há controles de segurança adicionais, então qualquer usuário do repositório pode modificar o pipeline e essas modificações serão executadas sem qualquer revisão ou aprovação.
No mesmo sentido, o Xygeni também detecta que é vulnerável ao EPI por causa da chamada para o script de shell do pipeline: qualquer usuário do repositório pode modificar o shell script e essas modificações serão executadas sem qualquer revisão ou aprovação.
Você quer saber mais?
Explorando EPI
Para explorar o EPI vamos considerar um cenário onde há dois tipos de usuários de repositório:
- An usuário interno (um desenvolvedor interno trabalhando nesse repositório), com permissões de gravação no repositório
- An usuário externo (um desenvolvedor terceirizado trabalhando nesse repositório, mas com permissões de leitura no repositório), ou seja, não tem permissão para ramificar o repositório e é forçado a trabalhar em um fork.
Vamos imaginar que ambos sejam invasores mal-intencionados (ou personificados por um ator mal-intencionado). O repo contém algum segredo e ambos querem para roubar o segredo do repositório e envie-o para um servidor controlado por hackers. Para isso, eles vão aproveitar o Envenenado Pipeline Vulnerabilidades de execução do pipeline.
Em ambos os casos (usuário externo e interno), eles abrem uma Pull Request com as mesmas modificações:
- O processo de pipeline e o script de shell são modificados para leia o segredo do meio ambiente e envie-o para um servidor controlado por hackers
As modificações podem ser as seguintes:
Ambos os usuários criarão um Pull Request com as modificações. Após a criação do PR, GitHub executará ambas as modificações (sem necessidade de revisão ou aprovação prévia), resultando no seguinte:
O mesmo para usuários de gravação e leitura, em ambos os casos D-PPE e I-PPE são executados, com a diferença que o usuário lido não consegue acessar os segredos. (!!!!)
Esta razão é porque, no caso de um PR proveniente de um fork, o GitHub não permite acesso aos segredos do repositório. Embora o usuário que lê não possa ler os segredos, ele ainda pode executar qualquer outro programa. Um exemplo típico de ataque é a criação de PRs que baixam um minerador de criptografia, de modo que o executor do GitHub executará o minerador de criptografia ao executar um minerador envenenado. pipeline.
Este não é um ambiente seguro, claro!! O que o administrador do repositório pode fazer para evitá-lo?
Depois de pesquisar no Google, o administrador do repositório decide modificar o pipeline ser acionado em um pull_request_target evento. Por que? Porque pipelines acionados em pull_request_target não permitem execução pipeline modificações, ou seja, apesar de qualquer modificação do usuário, o “original” pipeline será executado.
Seguindo nosso exemplo, o ataque será o mesmo de antes. O que acontecerá depois disso pipeline modificação?
Como esperado, D-PPE não é executado mas, como o I-PPE ainda existe, o usuário lido agora pode acessar o segredo do repositório!!!
Qual é a razão pela qual o usuário lido agora tem acesso aos segredos? Apesar de pipeline não pode ser modificado, ainda é possível modificar o script de shell. Quando um pipeline é acionado em pull_request_target, será executado em modo privilegiado so também será o script de shell, resultando no shell script tendo acesso aos segredos do repositório!!
Medidas preventivas
O GitHub fornece algumas medidas para proteção contra PRs maliciosos.
Regras de proteção de filiais
Com o GitHub você pode definir regras de proteção de filiais em filiais selecionadas.
Para suas ramificações protegidas, você pode especificar uma política que requer uma pull request antes de fundir (bem como condições adicionais, como número necessário de aprovações, revisões dos proprietários do código, etc.)
Algumas condições que merecem consideração especial são:
- "Permitir que atores especificados ignorem o necessário pull requests".
- "Não permita ignorar as configurações acima"
Embora a maioria das condições acrescente rigor à política, estas flexibilizam a política e isso pode implicar uma porta aberta a atividades maliciosas, por exemplo, no caso de credenciais serem roubadas por intervenientes “privilegiados”.
Restringir permissões GITHUB_TOKEN (privilégio mínimo)
Restrinja as permissões do token GitHub apenas às necessárias; desta forma, mesmo no caso de os invasores conseguirem comprometer o seu pipeline, eles não serão capazes de fazer muito.
Evite a interpolação de strings usando pipeline variáveis ambientais
Sempre que você usar algumas variáveis de entrada em seu pipeline, esteja ciente de que eles devem ser considerados por padrão como dados “não confiáveis” (seu conteúdo é controlado pelo usuário final). Ver Ações e fluxos de trabalho não confiáveis seguros e Aprenda ações do Github.
Você deve sempre usar variáveis de ambiente para inserir variáveis de entrada dentro de scripts em vez de usar interpolação de strings.
Execuções de fluxo de trabalho e requisitos de aprovação
Para público repositórios, o GitHub permite especificar como trabalhar com PRs “externos”.
As configurações da organização do GitHub (“Organização >> Configurações >> Ações >> Geral”) permitem especificar como gerenciar PRs externos:
Por padrão, o GitHub exigirá aprovação de RP para contribuidores de primeira viagem, tornando os ataques de solicitação maliciosa mais complicados. Mesmo assim, o invasor pode ganhar a confiança dos mantenedores do projeto, por exemplo, contribuindo com alguma informação inocente pull request antes do ataque real.
Nesse sentido, o A terceira opção (exigir aprovação de todos os colaboradores externos) adiciona um nível mais alto de controle.
Para investidores privados repositórios, o GitHub também fornece controle útil tanto no nível da organização quanto no nível do repositório.
"Executar fluxos de trabalho de Pull Requests” (não marcado por padrão) permite que os usuários executem fluxos de trabalho a partir de PRs de fork (usando um GITHUB_TOKEN com permissões somente leitura e sem acesso a segredos). Ao selecionar esta opção juntamente com a última (“Exigir aprovação para fluxos de trabalho de PRs bifurcados”) , você pode alcançar uma política semelhante aos repositórios privados (conforme mostrado acima).
Como vimos na exploração do PPE de um usuário lido, permitindo a execução de fluxos de trabalho a partir do fork pull requests não é seguro!!
As opções restantes (“Enviar tokens de gravação para fluxos de trabalho do fork pull requestseEnvie segredos e variáveis para fluxos de trabalho de for pull requests") diminuir o nível de segurança aplicado a PRs bifurcados.
Você pode definir essa política de bifurcação no nível da organização ou no nível do repositório. Se a política estiver desabilitada no nível da organização, ela não poderá ser habilitada no nível do repositório. Mas, se a política estiver habilitada no nível da organização, ela poderá ser desabilitada no nível do repositório.
Recapitular
Esperamos que você tenha visto as implicações de ter algum pipeline vulnerável a envenenado Pipeline Execução. É muito fácil commit um vulnerável pipeline, e é difícil escrever um seguro.
Portanto, é altamente valioso usar o Xygeni Scanner para estar ciente de tais vulnerabilidades.
Você não pode resolver uma vulnerabilidade a menos que esteja ciente de sua existência!!
Mas… ainda há uma questão pendente… Como evitar o EPI?
Esse será o assunto do nosso próximo post 🙂… Envenenado Indireto Pipeline Execução (I-PPE) !!
