Vulnerabilidades em Pipelines

Na última década, muito se falou sobre as metodologias DevSecOps e como esses processos automatizados podem aplicar uma sanitização em toda a infraestrutura de nossas aplicações. Esse ponto de interesse fez evoluir a forma como analisamos os sistemas. Deixamos de visualizar e auditar as aplicações do ponto final (quando estão em produção) e passamos a adotar uma abordagem dinâmica e interativa que acompanha o ciclo clássico de desenvolvimento seguro de software desde o início.

Está claro que essa mudança de perspectiva ajuda muito na forma como abordamos os projetos e a arquitetura das aplicações. Como resultado, cada desenvolvimento se torna cada vez mais robusto em termos de segurança. Agora, os analistas de segurança têm acesso à informação em tempo real e podem gerar alertas precoces para evitar assumir um custo maior ao corrigir uma vulnerabilidade durante o ciclo de desenvolvimento.

Embora as aplicações sejam agora mais robustas, os atacantes são forçados a planejar novos vetores de ataque associados aos novos recursos. Esses recursos estão ligados à forma como automatizamos as tarefas de proteção e à arquitetura que usamos para projetar nossa abordagem DevSecOps. Entre eles, um dos pontos mais importantes são os Pipelines.

Un Pipeline

Um pipeline é um conjunto de processos e ferramentas usados para coletar dados brutos de várias fontes, analisá-los e apresentar os resultados em um formato compreensível. Isso, em um fluxo de DevSecOps, é crucial, pois está associado ao processo de análise e melhoria contínua relacionado especificamente ao código. Vale ressaltar que ele não é usado apenas para fluxos de desenvolvimento seguro, mas também em diversos setores relacionados à análise de dados.

Os pipelines são ferramentas muito poderosas e úteis, por isso o processamento ou a manipulação dessa informação é frequentemente de grande interesse para os atacantes.

Pipeline CI/CD
(Continuous Integration/Continuous Development)

Um Pipeline de CI/CD é o componente fundamental do desenvolvimento de software automatizado. Embora o termo tenha sido usado para descrever muitos aspectos diferentes da computação, em grande parte da indústria de DevOps, usamos "Pipelines" para ilustrar as amplas aplicações de comportamentos e processos envolvidos na integração contínua (CI).

Dentro dessas novas funcionalidades, encontramos as seguintes vulnerabilidades potenciais que podem estar afetando os pipelines que são implantados de forma não supervisionada.

Broken Authentication en CI/CD

Descuidos no design da autorização e autenticação dos canais de CI e CD podem ocorrer no momento em que se desenha o esquema de papéis e permissões. Alguns dos seguintes exemplos podem ser evitados tendo o processo adequado que valide todas essas configurações. Entre todos os métodos, podemos encontrar os seguintes:

 • Adicionar aprovador não autorizado usando permissões de administrador:
 • Neste cenário, um atacante com permissões de administrador no canal de integração contínua (CI) adiciona um usuário não autorizado como aprovador, possivelmente contornando as verificações de segurança necessárias.
Ex: ci-tool add-approver --pipeline pipeline-name --user unauthorized-user

 • Autenticação Fraca:
 • Neste cenário, um atacante aproveita os mecanismos de autenticação fracos para obter acesso de administrador à ferramenta de integração contínua (CI) e manipular a configuração dos aprovadores, realizando, por exemplo, um ataque de força bruta.
Ex :ci-tool login --username admin --password weakpassword

 • Manipulação de Token:
Ex: ci-tool --api-token stolen-token add-approver --pipeline pipeline-name --user unauthorized-user

Má gestão de Segredos

Os pipelines estão constantemente conectados a recursos associados a outras aplicações, serviços ou, em sua falta, credenciais específicas associadas a recursos produtivos importantes. Ter uma gestão adequada de segredos é essencial para evitar os problemas listados a seguir:

 • Autorização incorreta de repositórios:
 • Neste cenário, um invasor obtém acesso a um pipeline CI/CD que interage com um gerenciador de segredos e tira proveito de permissões fracas para recuperar credenciais sensíveis.
Ex: ci-tool get-secrets --repository malicious-repo --secret-manager secretmanager-nam

 • Injeção de código:
 • O invasor envia um código malicioso manipulado para um repositório legítimo, que, quando executado no pipeline, captura segredos ou os utiliza para realizar ações não autorizadas.
Ex: echo "echo $SECRET_VARIABLE" >> main.py

 • Obter credenciais do console de administração CI/CD:
 • Recuperar o acesso à AWS e chaves secretas a partir de um console de administração CI/CD para depois passá-las como variáveis de ambiente
Ex: export AWS_ACCESS_KEY_ID=$(aws ssm get-parameter --name /path/to/access_key - -with-decryption --query Parameter.Value --output text) export AWS_SECRET_ACCESS_KEY=$(aws ssm get-parameter --name /path/to/secret_key --with-decryption --query Parameter.Value --output text) pipeline-stage-command

 • Recuperar um segredo do Hashicorp Vault e passá-lo como uma variável para a etapa do pipeline:
Ex: export SECRET=$(vault kv get -format=json secret/path/to/secret | jq -r '.data.key') pipeline-stage-command

 • Recuperar um segredo do Kubernetes a partir do console de administração e fazê-lo passar como um volume montado na etapa do pipeline:
Ex: kubectl create secret generic my-secret --from-literal=username=<username> -- from-literal=password=<password>
kubectl create volume secret my-secret-volume --secret=my-secret pipeline-stage-command --volume=my-secret-volume:/secrets

Ambiente de produção exposto por má configuração

A mesma história que ocorre nas aplicações que esses pipelines verificam. Geralmente associada a um erro acumulado ou a uma abordagem equivocada sobre a sensação de segurança aplicada à configuração dos pipelines CI/CD.

 • Variáveis de ambiente mal configuradas:
 • Este exemplo vem da identificação de variáveis mal configuradas e da exploração dessas variáveis com o objetivo de obter acesso não autorizado a diferentes recursos.
Ex: ci-tool get-secrets --repository legitimate-repo --secret-manager $MISCONFIGURED_VARIABLE

 • Modificação de uma configuração não autorizada:
 • Neste cenário, o atacante pode obter acesso ao pipeline e modificar a configuração do ambiente de produção.
Ex: # Modify the production environment configuration file echo "MALICIOUS_SETTING = True" >> production.config

 • Scripts mal configurados:
 • O atacante pode identificar o desenvolvimento de um script mal configurado e explorá-lo para modificar o ambiente de produção.
Ej: # Exploit misconfigured deployment script to modify production configuration ci-tool run-deployment-script --script "sed -i 's/ALLOW_PUBLIC_ACCESS = False/ALLOW_PUBLIC_ACCESS = True/' production.config"

 • Gerenciador de configurações inseguro:
 • A seguir, podemos visualizar um exemplo de código onde podemos encontrar essa falha. No exemplo mostrado na captura seguinte, a função deploy é parte de um script. O parâmetro repo_url pretende ser um repositório git válido. No entanto, devido a uma validação inadequada da entrada, um atacante poderia injetar comandos arbitrários adicionando-os ao parâmetro repo_url. Neste caso, o atacante pode adicionar o comando (rm -rf /) para apagar todo o sistema de arquivos..

Código:

Repositório potencialmente malicioso:

 • Armazenamento inseguro de credenciais:
 • No exemplo mostrado na captura, a função list_buckets usa o SDK da AWS para interagir com o Amazon S3. O código depende do comportamento padrão de busca de credenciais do SDK, que verifica vários arquivos de configuração em busca das credenciais da AWS. No entanto, o pipeline tem uma falha de segurança onde as credenciais da AWS são armazenadas de forma insegura. Um atacante pode executar um comando (cat ~/.aws/credentials) para recuperar as credenciais da AWS e potencialmente obter acesso não autorizado aos recursos da AWS.

Todos esses pontos são importantes para evitar o efeito conhecido como "snowball", onde o acúmulo de erros ocorre ao longo de todas as cadeias de desenvolvimento implementadas em nosso CI/CD. É por isso que abordar esses erros desde o início é de grande utilidade para evitar um problema maior no futuro.

Ferramentas que podem nos ajudar

Como veremos a seguir, o uso de componentes externos continua causando dores de cabeça se eles não passarem por uma validação adequada.

 • Trufflehog:
 • TruffleHog é um scanner de dados sensíveis para repositórios Git. Ele verifica a URL do repositório Git especificado (https://example.com/git-repo.git) usando correspondência de padrões de expressões regulares e análise de entropia para identificar informações potencialmente sensíveis, como chaves de API, senhas e outros segredos armazenados no repositório.

 • Circleci:
 • Este comando usa a ferramenta CLI do CircleCI para simular a execução de um arquivo de configuração do CircleCI (config.yml) localmente. Ele empacota o arquivo de configuração usando "circleci config pack" e depois executa o arquivo de configuração empacotado usando "circleci local execute". Isso pode ajudar a identificar configurações incorretas, vulnerabilidades ou práticas inseguras dentro do pipeline CI/CD definido no arquivo de configuração do CircleCI..
Ej: docker run -v $(pwd):/src -w /src -t circleci/circleci-cli:latest circleci config pack .circleci > config.yml && circleci local execute -c config.yml

 • Snyk:
 • Snyk é uma ferramenta popular de varredura de segurança, usada para testar todos os projetos e subprojetos no diretório atual. Snyk verifica o código-fonte e suas dependências, procurando vulnerabilidades conhecidas, práticas de codificação inseguras e outros problemas de segurança. Isso ajuda a identificar e abordar fraquezas de segurança introduzidas por práticas de codificação inseguras.
Ej: snyk test --all-projects --all-sub-projects

 • npm:
 • O comando npm audit, integrado ao Node Package Manager (npm), realiza uma auditoria de segurança das dependências em um projeto Node.js. Este comando verifica as dependências do projeto contra o Banco de Dados Nacional de Vulnerabilidades (NVD) e gera um relatório destacando quaisquer vulnerabilidades conhecidas e práticas de codificação inseguras. Isso ajuda a identificar e abordar problemas de segurança introduzidos por dependências implementadas de forma insegura ou desatualizadas.

 • Análise de Dependência de Terceiros:
 • OWASP Dependency-Check é uma ferramenta amplamente utilizada para identificar vulnerabilidades conhecidas nas dependências do projeto. Ela verifica o projeto localizado em <caminho-para-o-projeto>, analisa as dependências e gera um relatório em HTML (--format HTML) destacando quaisquer dependências inseguras e/ou componentes vulneráveis.
Ej: OWASP-Dependency-Check --scan <path-to-project> --format HTML

Conclusão

Como identificamos neste post, revisamos vários pontos interessantes ao entender que, se implementarmos mecanismos automatizados para melhorar a segurança de nossas aplicações, isso não significa que devemos prestar menos atenção à forma como projetamos nosso fluxo de automação. A atenção à segurança deve permanecer constante em todos os aspectos da nossa arquitetura e deve ser aprimorada com a mesma frequência e atenção que todos os nossos ativos.