Pipelines automatizados de CI/CD (integração contínua/entrega contínua) são usados para acelerar o desenvolvimento. É incrível ter gatilhos ou agendamento que peguem seu código, mesclem-no, construam-no, testem-no e enviem-no automaticamente. No entanto, ter sido construído para ser rápido e fácil de usar significa que a maioria dos pipelines não é inerentemente construída com a segurança em mente. Como os pipelines geralmente precisam ter acesso à Internet para baixar dependências e aos seus vários segredos para fazer upload para o seu ambiente de produção, isso significa que, uma vez comprometido esse pipeline, o invasor terá uma ampla gama de opções para interromper sua operação ou exfiltrar informações ou segredos.
Todas as histórias apresentadas neste artigo descrevem violações em ferramentas importantes de CI/CD. O facto de a maioria das empresas confiar em tais ferramentas significa que, tal como muitas outras ataques à cadeia de suprimentos de software, tudo o que os malfeitores precisam é violar um único alvo para obter um vasto raio de explosão.
Vamos dar uma olhada em algumas histórias importantes dos últimos anos que demonstram as vulnerabilidades inerentes a esse vetor de ataque. No final do artigo, oferecerei minhas recomendações para fortalecer e proteger seus pipelines, independentemente das ferramentas que você estiver usando.
A violação do CircleCI
Em janeiro de 2023, a CircleCI, uma plataforma de integração e entrega contínua, divulgou um falha de segurança que permitiu que um invasor obtivesse acesso não autorizado à infraestrutura da empresa. O ataque foi iniciado por um e-mail de phishing que enganou um funcionário para que compartilhasse suas credenciais, que o invasor usou para acessar os sistemas da empresa. O funcionário estava utilizando 2FA, mas o invasor conseguiu obter um cookie de sessão assim que o funcionário já havia feito login no sistema, permitindo-lhe se passar por funcionário e, eventualmente, aumentar o acesso a um subconjunto de sistemas de produção do CircleCI.
O invasor acessou alguns dados de clientes, incluindo nomes, endereços de e-mail e informações de cobrança. A empresa informou que nenhum código ou propriedade intelectual foi acessado e nenhum cliente relatou qualquer acesso não autorizado às suas contas ou dados.
A CircleCI respondeu rapidamente à violação, conduzindo uma investigação e trabalhando com especialistas em aplicação da lei e em segurança cibernética para identificar o escopo do ataque e remediar as vulnerabilidades que permitiram sua ocorrência. A empresa também redefiniu todas as credenciais de funcionários e clientes e implementou medidas de segurança adicionais, como maior monitoramento de seus sistemas.
DevOps interrompido: a violação de segurança do Argo CD
Argo CD é uma ferramenta popular de código aberto para implantação contínua de aplicativos em clusters Kubernetes. Em fevereiro de 2022, um nova vulnerabilidade foi descoberta no Argo CD que permitiu que usuários não autenticados acessassem informações confidenciais sobre aplicativos Kubernetes gerenciados pela ferramenta. A vulnerabilidade foi causada por uma configuração incorreta no servidor API do Argo CD que permitiu que usuários não autorizados executassem solicitações à API e recuperassem informações como segredos, configurações e metadados de aplicativos. Contanto que o invasor tivesse permissão para criar ou atualizar aplicativos e soubesse ou pudesse adivinhar o caminho completo para um arquivo contendo um YAML válido, ele poderia criar um gráfico Helm malicioso e continuar consumindo arquivos YAML como valores até encontrar um dado interessante que normalmente seria inacessível.
A vulnerabilidade recebeu uma pontuação CVSS de 7.5 (alta gravidade) e afetou todas as versões do Argo CD até a versão 2.1.4 inclusive. Argo CD lançou um patch para a vulnerabilidade na versão 2.1.5, e os usuários foram aconselhados a atualizar para esta versão o mais rápido possível.
A vulnerabilidade foi considerada particularmente preocupante porque o Argo CD é frequentemente usado para gerenciar aplicações e infraestruturas críticas em ambientes de produção. O vazamento de informações confidenciais poderia ter permitido que um invasor obtivesse acesso a dados confidenciais ou realizasse outras ações maliciosas que poderiam afetar a disponibilidade ou a segurança dos aplicativos.
Descobrindo a violação do Codecove: lições aprendidas
Codecov é uma ferramenta de rastreamento e análise de cobertura de código usada em pipelines de CI/CD que permite aos desenvolvedores medir e analisar a eficácia de seus testes. Conforme publicado no Codecov's Atualização de segurança:
“Na quinta-feira, 1º de abril de 2021, soubemos que alguém obteve acesso não autorizado ao nosso Carregador Bash script e o modificou sem nossa permissão. O ator obteve acesso devido a um erro no processo de criação de imagem Docker do Codecov que permitiu ao ator extrair a credencial necessária para modificar nosso script Bash Uploader.”
O Bash Uploader é usado pelos clientes para fazer upload de seus relatórios de cobertura de código para a plataforma Codecove. Com esse acesso, o invasor modificou o script Bash Uploader adicionando código malicioso que coletava variáveis de ambiente, tokens de autenticação e outros dados confidenciais do sistema do usuário durante o processo de upload. Esses dados foram então enviados para um servidor remoto controlado pelo invasor.
De acordo com a Codecove, a violação impactou aproximadamente 1% de sua base de clientes, que incluía grandes empresas dos setores de tecnologia, finanças e saúde. A empresa confirmou que nenhum código de cliente ou relatório de cobertura de código foi alterado durante a violação, mas que os tokens de autenticação do usuário e outras informações confidenciais podem ter sido comprometidos.
A Codecove tomou medidas imediatas para remover o código malicioso e alertar os clientes afetados para redefinir seus tokens de autenticação e tomar outras medidas de segurança. A empresa também lançou uma investigação sobre o incidente e contratou especialistas em aplicação da lei e segurança cibernética para identificar a origem do ataque.
Como você pode defender seu pipeline?
Conjuntos de torres de resfriamento em edifícios de data center.
Conforme mencionado acima, os pipelines de CI/CD são construídos para velocidade e automação, não necessariamente para segurança. O facto de três grandes e respeitadas empresas terem sido vítimas de algum tipo de ataque, expondo potencialmente as informações dos seus clientes, demonstra a vulnerabilidade do seu próprio pipeline e dos seus dados.
Não importa quais ferramentas ou plataforma de CI/CD você esteja empregando, você pode fazer algumas coisas para melhorar sua segurança e reduzir os possíveis danos caso um agente mal-intencionado consiga obter acesso ao seu pipeline ou rede.
- Modelagem de Ameaça – A modelagem de ameaças é uma abordagem estruturada para identificar possíveis ameaças à segurança de um sistema ou aplicativo e projetar contramedidas apropriadas para mitigar essas ameaças. Como exercício, imagine que alguém obteve acesso ao seu pipeline. Quais ambientes eles podem acessar agora? Que segredos e chaves eles podem ver e usar? Eles podem modificar seu código? Testes de influência? Extrair arquivos da web ou executar um shell reverso? Mesmo se você achar que limpou seu pipeline e segmentou adequadamente o acesso à rede, não custa nada imaginar e depois verificar apenas para estar ciente do pior cenário. Você pode se surpreender com os segredos e opções de acesso que estão ocultos à vista de todos em sua plataforma ou ferramentas de pipeline.
- Segmentação de rede – A segmentação de rede é a prática de dividir uma rede maior em sub-redes ou segmentos menores e mais seguros, cada um com seus próprios controles e políticas de segurança. O objetivo da segmentação de rede é aumentar a segurança de toda a rede, limitando o escopo de uma potencial violação de segurança e minimizando o impacto potencial de um ataque. A divisão de uma rede em segmentos menores limita o movimento lateral dos invasores e reduz o risco de acesso não autorizado ou vazamento de dados.
Com a crescente popularidade dos ataques de phishing, qualquer um dos seus desenvolvedores ou outros funcionários pode ser vítima de tal golpe – somos todos humanos. Presumir que as credenciais dos seus desenvolvedores possam ser usadas por agentes mal-intencionados significa que você precisa ter certeza de que a esmagadora maioria dos desenvolvedores não deve ter o tipo de acesso que lhes permitiria exfiltrar segredos sozinhos, implantar código malicioso em uma imagem de produção, ou apenas enviar sua própria versão de um código de produção incontestado. Garantir que cada indivíduo tenha o mínimo de acesso necessário para seu trabalho é demorado, e a tentação de apenas conceder acesso de administrador a todos e pronto é forte. Não fique tentado pelo lado negro – siga as regras de confiança zero e privilégios mínimos. - Monitoramento e alertas – Seguindo o último ponto, mesmo que você tenha treinado minuciosamente seus desenvolvedores para que se cansem de phishing e outros golpes de engenharia social, uma violação ainda pode acontecer. Você não sabe quando ou como, mas deve estar preparado para descobrir, pelo menos. Como a maioria dos ambientes de pipeline são efêmeros, isso significa que, uma vez concluído o trabalho, não há nenhum vestígio de evidência sobre o que aconteceu, a menos que você mesmo crie esses vestígios.
Certifique-se de registrar tudo o que acontece em seus pipelines, em cada PR, mesclagem, construção e teste realizado. Certifique-se de que as informações dos usuários também estejam registradas, para serem revisadas caso algum problema exija tal verificação. Quaisquer alterações nos arquivos de configuração ou no próprio ambiente também devem ser registradas. O objetivo aqui é ser capaz de fazer uma análise clara de uma violação para poder dizer o que aconteceu e como. Determine antecipadamente quais eventos devem justificar um alerta e garanta que as pessoas certas recebam esse alerta. Tenha cuidado para não inundar as pessoas com alertas inúteis ou falsos – isso causaria fadiga de alerta que apenas as levaria a ignorar os alertas ou a responder muito mais tarde do que o aconselhável. Obviamente, nenhum desses logs deve conter segredos ou chaves abertas – o que leva ao próximo ponto:
- Gerenciamento de segredos – Certifique-se de usar algum tipo de ferramenta de gerenciamento de segredos. No mínimo, seria mais fácil alternar seus segredos e senhas caso ocorresse uma violação. Ele também deve fazer o trabalho de redigir segredos abertos e chaves de acesso encontrados no pipeline de qualquer registro feito no sistema. Em nenhum momento alguém não autorizado deverá ter acesso a tais informações e, definitivamente, não deverá poder alterá-las.
O gerenciamento de segredos está se tornando cada vez mais importante à medida que as organizações dependem cada vez mais de serviços baseados em nuvem, aplicativos em contêineres e outros ambientes distribuídos que exigem compartilhamento e gerenciamento seguros de segredos em diferentes sistemas e aplicativos. - Use o princípio RBAC combinado com menos privilégios – O princípio do Controle de Acesso Baseado em Função (RBAC) é fornecer acesso aos recursos do sistema com base na função ou função atribuída a um usuário dentro de uma organização. No RBAC, os usuários recebem funções que definem as permissões e direitos de acesso que possuem a vários recursos do sistema, como arquivos, pastas ou aplicativos. O princípio do Menor Privilégio, por outro lado, é a prática de conceder aos usuários o nível mínimo de acesso e privilégios necessários para desempenhar suas funções profissionais. Isso significa que os usuários só têm acesso aos recursos necessários para realizar suas tarefas específicas e nada mais. O RBAC e o Privilégio Mínimo são frequentemente usados juntos como princípios de segurança complementares. No RBAC, são atribuídas funções aos usuários que possuem o nível apropriado de acesso aos recursos necessários para desempenhar suas funções de trabalho, e o princípio do Privilégio Mínimo garante que os usuários tenham acesso apenas ao nível mínimo de recursos necessários para executar suas tarefas específicas. Juntos, esses princípios ajudam a manter um sistema seguro e bem gerenciado, com risco mínimo de acesso não autorizado ou violação de dados. Como um pouco mais de segurança, você pode configurá-lo para que ações críticas no sistema exijam a realização de múltiplas autorizações de usuário. Esta abordagem deve ser adoptada com cuidado, uma vez que tem o potencial de abrandar significativamente o trabalho de desenvolvimento. No entanto, para atualizações críticas, como excluir uma ramificação principal ou modificar uma lista de dependências, você deve fazer isso de forma que pelo menos duas pessoas com o acesso apropriado precisem aprová-la.
Olhando para a frente
Ninguém vai parar de usar CI/CD e outras ferramentas de automação para acelerar seu trabalho. Vivemos em um mundo onde buscamos constantemente atualizações de código cada vez mais rápidas. Precisamos apenas ter certeza de que faremos isso com consciência de segurança e não comprometeremos nosso código e ambiente de produção ao longo do caminho.
Uma das coisas mais importantes que você pode fazer é pensar um pouco sobre o que poderia acontecer se pessoas não autorizadas obtivessem acesso. Depois que você estiver ciente do perigo e dos diferentes locais vulneráveis em seus dutos e na rede, acredito que você será capaz de tomar as medidas corretas para tapar os possíveis vazamentos.
A Scribe é uma empresa de segurança da cadeia de suprimentos de software cuja plataforma foi projetada para oferecer transparência sobre o que acontece em seu processo e pipeline de desenvolvimento. Para saber mais sobre como o Scribe pode ajudá-lo a proteger seus pipelines entre em contato.
Este conteúdo é oferecido a você pela Scribe Security, um fornecedor líder de soluções de segurança de cadeia de suprimentos de software ponta a ponta – fornecendo segurança de última geração para artefatos de código e processos de desenvolvimento e entrega de código em todas as cadeias de suprimentos de software. Saiba mais.
Artigos Relacionados
