Codecov Takeaways — O que sabemos até agora

Não que alguém precisasse ser lembrado tão cedo, mas a violação recentemente anunciada do conjunto de ferramentas da Codecov, que suporta processos de Integração Contínua (CI) em muitas organizações, destaca novamente a grande densidade de interdependências que existem hoje e a exposição resultante aos ataques da cadeia de suprimentos.

Além disso, a fé muitas vezes implícita no software fornecido por fornecedores confiáveis significa que os clientes não testam adequadamente o que uma atualização está fazendo, tanto em termos do que ela está fazendo localmente no host, quanto em termos de conectividade de rede e transferência de dados. Tudo isso significa que, na maioria das vezes, o software que está sendo executado nas organizações não é totalmente compreendido.

Como isso é relevante para o que aconteceu com Codecov?

O Codecov fornece recursos de geração de relatórios que podem ser integrados aos pipelines de CI dos clientes — especificamente, suas ferramentas relatam a quantidade de código que é executado como parte do teste, ajudando a identificar lacunas no processo de validação. Essas métricas são então enviadas para sua plataforma SaaS para geração de relatórios e análises.

O upload de dados é facilitado por scripts conhecidos coletivamente como “Bash Uploaders”, que são executados como parte do processo de CI. Esses scripts do Uploader, caso sejam alterados, oferecem uma oportunidade para um invasor não apenas redirecionar o upload para um servidor de sua escolha, mas também especificar quais dados deseja incluir, tornando qualquer coisa disponível para o processo de CI potencialmente acessível.

No caso da Codecov, o comprometimento inicial foi por meio de um vazamento das credenciais do Google Cloud Storage disponibilizadas por meio de um erro no processo de criação da imagem docker da Codecov. Essas credenciais permitiram que o invasor publicasse uma versão modificada do script do Bash Uploader, que foi alterada para permitir que ele coletasse o conteúdo de todas as variáveis de ambiente disponíveis para o processo de CI no qual ele foi executado e as enviasse para seu próprio servidor.

Como esse script modificado estava disponível diretamente no site da Codecov, presumivelmente era confiável para os clientes, foi baixado e integrado com pouca validação. As variáveis de ambiente no processo de CI geralmente são usadas para inserir segredos relevantes no código para acessar os recursos necessários em tempo de execução. Assim, o script malicioso do Uploader teria acesso a eles e seria capaz de transferi-los para o atacante, fornecendo a ele uma boa colheita de credenciais e outras informações confidenciais.

Mesmo sem mais acesso persistente à rede — e ainda não há indicação de que a violação estabeleça isso — esses segredos são um baú do tesouro, já que fornecem acesso a vários recursos acessíveis pela Internet, como baldes de armazenamento, bancos de dados e outros serviços em nuvem que os aplicativos associados usaram. Agora, provavelmente, também estão comprometidos.

No mínimo, qualquer organização que acredite ter incorporado os scripts comprometidos do Bash Uploader em seu pipeline de CI deve, com urgência, redefinir todos os segredos aos quais ela tem acesso. Isso quase definitivamente exigirá uma reimplantação dos aplicativos afetados para garantir que eles tenham recebido os segredos atualizados, mas a sobrecarga desse método é preferível a prolongar a exposição de credenciais roubadas.

Além da exfiltração de segredos, o acesso privilegiado persistente oferecido ao pipeline de CI está propenso a abusos. Por definição, a responsabilidade do pipeline é gerar novas compilações de software e publicá-las em repositórios. O comprometimento da própria infraestrutura do pipeline permite ao atacante alterar o conteúdo, potencialmente inserindo backdoors para uso posterior em sistemas downstream ou em artefatos gerados. Então, quanta reconstrução precisa ser feita para ter certeza de que todos os vestígios do atacante e de seus tentáculos foram removidos?

Em seguida, vale a pena analisar o acesso à rede disponível para a infraestrutura de CI. Normalmente, eles têm acesso direto a outros componentes principais, incluindo, mas não se limitando a, sistema de controle de versão, infraestrutura de monitoramento, testes automatizados, processo de criação, gerenciamento de configuração e implantação contínua. Além disso, com o uso intenso de componentes FOSS, o pipeline de CI geralmente precisará de acesso à Internet a repositórios públicos para obter dependências relevantes.

Com os densos requisitos de conectividade que o pipeline de CI exige, a segmentação ainda pode servir como um controle de segurança valioso?

Ao considerar o valor de microssegmentação, ele pode ser apresentado de duas formas:

1. A microssegmentação permite que ativos de alto valor sejam cercados, garantindo que sua exposição de e para o resto da rede seja limitada, tornando mais difícil para um invasor alcançá-los e explorá-los.
2. A microssegmentação permite que cada carga de trabalho tenha seu próprio microperímetro baseado em regras de acesso com menos privilégios ao seu redor. Isso garante que, se for comprometido, o superfície de ataque A exposição a ela está limitada apenas ao que ela está autorizada a se conectar, limitando, em última análise, o que um invasor pode fazer a seguir.

Uma abordagem para tornar isso relevante para o pipeline de CI é mais ou menos assim:

• O pipeline de CI é definitivamente um ativo de alto valor e que deve ser protegido.
• Embora possa ter várias dependências internas e externas do ponto de vista da conectividade, elas devem ser bem compreendidas e bem definidas.
• Usando essas informações, um lista de permissõesuma política de microssegmentação baseada pode ser construída para garantir que o pipeline de CI tenha acesso apenas a e a partir dessas dependências bem compreendidas.
• Se o acesso à Internet for necessário, ele deverá ser permitido somente para uma lista de repositórios aprovados e não para o acesso irrestrito à Internet. Isso limita o acesso somente a uma lista explicitamente definida de sites de destino e é um controle eficaz e geralmente simples para mitigar as tentativas de C&C e de exfiltração de dados.

Isso protege o pipeline de CI de ser acessado por dispositivos não autorizados ou por portas e protocolos não autorizados. Também garante que, no caso de comprometimento do pipeline de CI, a exposição ao resto da rede seja limitada. Além disso, melhorou segmentação os controles geralmente andam de mãos dadas com uma visibilidade significativamente melhor das interações do sistema, fornecendo dados mais ricos para as equipes de detecção e resposta a incidentes trabalharem ao investigar possíveis violações.

Na Illumio, ajudamos os clientes a aproveitar microssegmentação para estabelecer essa contenção e monitoramento. Entre em contato com sua equipe de contas para descobrir como podemos ajudá-lo.