Lições aprendidas com a vulnerabilidade zero-day do Argo CD (CVE-2022-24348)

Em 30 de janeiro de 2022, a equipe do Argo CD foi contatada por pesquisadores da Apiiro sobre uma vulnerabilidade que haviam descoberto na popular plataforma de entrega contínua, que poderia permitir que agentes mal-intencionados roubassem informações confidenciais de implantações. A equipe do Argo CD conseguiu desenvolver rapidamente correções para as três versões com suporte no momento e disponibilizá-las aos usuários em até 48 horas. Em seu artigo sobre a CVE, o cofundador da CodeFresh e mantenedor do projeto Argo Dan Garfield atribui a agilidade da resposta ao foco em segurança em toda a plataforma que o projeto manteve nos últimos 18 meses.

Neste artigo, vamos falar sobre a vulnerabilidade e as implicações mais amplas para proteger você contra o tipo de ataque à cadeia de suprimentos que ela poderia ter causado.

O que é a vulnerabilidade do Argo CD?

Em essência, a CVE-2022-24348 é uma vulnerabilidade de travessia de diretórios/caminhos que permite que um invasor use um chart Helm criado de forma maliciosa para acessar dados pertencentes a outros aplicativos. Isso pode levar à escalada de privilégios e ampliar a exploração do cluster Kubernetes no qual o Argo CD está sendo executado.

Como saber se estamos vulneráveis?

Se você está usando o Argo CD nas versões de 0.5.0 a 2.1.12, 2.2.7 ou 2.3.1, está vulnerável e deve atualizar imediatamente para as versões mais recentes. Em 24 de março de 2022, elas eram:

• 2.3.2

• 2.2.8

• 2.1.14

Quais são os riscos?

Este é mais um exemplo de uma das várias formas de ataque à cadeia de suprimentos, uma lista que não para de crescer. Nesses ataques, agentes mal-intencionados tentam se infiltrar no software durante sua criação, em vez de invadir os sistemas depois que ele é lançado. Alguns exemplos recentes incluem os ataques ao CodeCov, à App Store do iOS e, o mais famoso, à SolarWinds. Neste incidente mais recente, um invasor poderia criar um chart Helm malicioso que explora a vulnerabilidade e permite acessar dados confidenciais de outros aplicativos no reposerver do Argo CD.

Os detalhes de como essa vulnerabilidade específica funciona estão na divulgação original da CVE, então não vamos repetir tudo aqui. Basta dizer que, ao criar um chart Helm com um URI que contenha um caminho de arquivo absoluto, específico e previsível, um invasor poderia exfiltrar dados confidenciais do sistema de arquivos nesse caminho no reposerver do Argo — inclusive dados de outros aplicativos e do escopo de seus usuários.

Como corrigir?

Se você chegou aqui procurando uma correção para a CVE-2022-24348 nos seus clusters, é simples: pare de ler e atualize imediatamente suas implantações do Argo CD! Depois, volte para continuar lendo e conhecer o contexto mais amplo.

Pronto? Ótimo! Agora vamos falar sobre os desafios mais amplos que enfrentamos em relação à segurança da cadeia de suprimentos de software.

Como mitigar ataques à cadeia de suprimentos

Como podemos nos proteger contra o próximo zero-day como este? Como a vulnerabilidade é específica do aplicativo Argo CD, não há uma resposta simples ou genérica. Mas você pode adotar algumas práticas em um nível mais amplo para evitar que arquivos criados de forma maliciosa — como o chart Helm neste caso — entrem nos seus sistemas:

1. Prefira commits pequenos e fáceis de revisar

A prática ágil de fazer mudanças pequenas e iterativas não é apenas uma boa ideia para manter o desenvolvimento organizado: ela também facilita a identificação de alterações inseguras ou suspeitas durante a revisão. Não estamos dizendo que alguém na sua organização copiaria e colaria código duvidoso do StackOverflow, mas seria muito mais fácil identificá-lo em uma revisão de código se ele não estivesse escondido em um commit de mil linhas.

2. Trate todos os sistemas do seu SDLC como sistemas de produção

Muitos de nós cometemos o erro de tratar nossos servidores de build — principalmente os montados por conta própria — como brinquedos. Sabe aquele servidor Jenkins, GitLab ou RunDeck que roda em um desktop sobrando no armário de rede, com uma senha de administrador conhecida e algumas centenas de plugins usando as credenciais de um desenvolvedor qualquer para se conectar a serviços externos? Pois é, esse mesmo! (Não estamos criticando esses projetos especificamente: qualquer ferramenta mal administrada é um alvo fácil para invasores.)

Historicamente, servidores de build e implantação foram tratados como sistemas de baixa prioridade e sem proteção suficiente contra ataques. Os ataques à SolarWinds e ao CodeCov, por exemplo, comprovam que esses sistemas precisam ser tratados com a mesma seriedade que os servidores de produção que armazenam os dados dos seus usuários.

• Não use credenciais compartilhadas.

• Não use plugins, ações ou módulos personalizados que não tenham sido verificados.

• Sempre implemente um controle de acesso baseado em função (RBAC) adequado e centralizado para limitar os acessos corretamente.

3. Conheça sua cadeia de suprimentos

É fundamental saber a origem dos artefatos que seus sistemas estão compilando e o que eles contêm. Implementar uma cadeia de suprimentos segura é um assunto tão amplo que poderia render vários livros. Na verdade, há conferências inteiras dedicadas a esses temas! Veja algumas áreas importantes às quais você deve dar atenção:

• Não confie cegamente em imagens de contêineres, pacotes de sistema operacional, bibliotecas de código — nem em charts Helm — que venham de fontes fora do seu controle. Repositórios privados e gerenciados, com artefatos verificados e assinados, são essenciais para garantir que as dependências dos seus aplicativos sejam confiáveis. Uma prática comum que vimos funcionar bem nesse cenário é usar um repositório de “quarentena”, onde as equipes podem importar novos artefatos para verificação pela segurança e para testes funcionais. Depois, os artefatos podem ser transferidos para um repositório ao qual desenvolvedores e sistemas de build tenham acesso geral. Essa verificação, é claro, precisa equilibrar a necessidade de agilidade da equipe — por isso, o processo deve ser adaptado ao contexto do negócio — na forma de diretrizes de segurança. As equipes também devem analisar esses artefatos em busca de vulnerabilidades, incluindo, sempre que possível, arquivos de configuração de IaC. É importante fazer novas análises regularmente, caso surjam vulnerabilidades. A Snyk pode ajudar você a detectar e corrigir vulnerabilidades e configurações incorretas.

• Implemente uma lista de materiais de software (SBoM) para seus aplicativos. Essa área está evoluindo rapidamente e, felizmente, recebendo bastante atenção graças às exigências estabelecidas em uma ordem executiva presidencial dos EUA de 2021.

• Outro tema relevante: commits Git assinados, que permitiriam detectar alterações no código feitas por terceiros não verificados. Para ser sincero, não vejo essa prática sendo muito adotada, e ela não é a solução mágica que pode parecer. Dan Lorenc, especialista na área, explica muito bem as vantagens e desvantagens em seu artigo de julho de 2021: Você deve assinar commits Git?.

Tudo gira em torno de DevSecOps

As ferramentas e práticas apresentadas aqui apontam para um fato importante: proteger nossas cadeias de suprimentos exige o envolvimento de toda a equipe, de desenvolvedores a SREs e de todas as pessoas entre essas funções. Quanto mais capacitarmos os desenvolvedores com ferramentas e processos que os incluam, em vez de simplesmente restringi-los ou controlá-los, mais sucesso teremos na proteção dos nossos aplicativos. Ao integrar ferramentas como a Snyk ao SDLC, podemos ajudar desenvolvedores a encontrar vulnerabilidades de segurança no próprio código antes mesmo de lançar uma versão! É isso que significam shift-left e DevSecOps: a segurança é incorporada desde o início. Isso me lembra o comentário de Dan sobre o foco da equipe do Argo CD em segurança. Embora eu não saiba como a equipe trabalha internamente, fica claro que a rapidez da resposta e a transparência na discussão dessa vulnerabilidade tiveram impacto direto na velocidade com que ela foi corrigida.

No nosso Relatório sobre o estado da segurança de aplicativos cloud native em 2021, descobrimos que empresas que automatizam amplamente os testes no SDLC têm o dobro de probabilidade de implementar testes de segurança. Mais de 72% delas relataram um tempo médio de correção de vulnerabilidades inferior a uma semana, e 36% levam, em média, um dia ou menos! De acordo com a documentação do projeto Argo, a equipe segue claramente essas práticas. A rapidez com que resolveu esse problema comprova isso.

Para saber mais

Confira outros recursos sobre os temas abordados:

• Saiba mais sobre vulnerabilidades de travessia de diretórios

• Como proteger sua cadeia de suprimentos de software moderna

• Como prevenir pacotes maliciosos e ataques à cadeia de suprimentos com a Snyk

• SnykCon 2021: segurança da cadeia de suprimentos, o futuro da segurança cibernética, automação como facilitadora e muito mais