Incidente de segurança na cadeia de suprimentos da CircleCI: rotacione seus segredos

Em 4 de janeiro, a CircleCI, uma ferramenta de configuração automatizada de pipelines de CI/CD, comunicou um incidente de segurança em seu produto por meio de um comunicado.

Contexto do incidente da CircleCI

Em 27 de dezembro, o engenheiro de segurança Daniel Hückmann recebeu uma notificação por e-mail sobre uma possível invasão em sua conta da CircleCI, graças a um AWS CanaryToken que ele havia inserido. O chamariz, na forma de uma chave da AWS, provavelmente foi acionado pelo invasor. Esses chamarizes, também conhecidos como honeytokens, podem ser inseridos nos sistemas para investigar e detectar invasões. Quando acionados por um invasor, eles alertam você sobre possíveis violações de segurança.

Em 4 de janeiro de 2022, a CircleCI recomendou que os clientes rotacionassem seus segredos em resposta a um incidente de segurança:

Para sermos totalmente transparentes, a Snyk é parceira e cliente da CircleCI.

Recomendações da CircleCI para usuários

A CircleCI recomendou que todos os usuários rotacionem imediatamente os segredos armazenados na plataforma, seja em variáveis de ambiente de projetos ou em contextos. Além disso, a empresa recomenda revisar os logs internos em busca de acessos não autorizados entre 21 de dezembro de 2020 e 4 de janeiro de 2023, ou após a conclusão da rotação dos segredos. A CircleCI invalidou os tokens de API pessoais e de projeto e rotacionou todos os tokens OAuth do GitHub e do Bitbucket.

Se você trabalha com desenvolvimento de software ou infraestrutura, precisa saber que rotacionar segredos pode ser difícil e interromper os fluxos de trabalho de CI/CD. Veja o que você pode fazer:

• Crie um inventário das variáveis de ambiente usadas em todos os seus projetos e pipelines, incluindo as armazenadas nos níveis de contexto e de projeto.

• Não exclua seus segredos da CircleCI; em vez disso, revogue-os para impedir que possíveis agentes mal-intencionados os acessem.

• Lembre-se de rotacionar as variáveis de ambiente e as chaves SSH.

O impacto da proliferação de segredos na cadeia de suprimentos de software

Armazenar segredos, como senhas e chaves de API, em vários locais é conhecido como “proliferação de segredos” e pode dificultar o gerenciamento e a proteção eficaz desses dados. Isso pode acontecer tanto dentro de uma organização quanto na cadeia de suprimentos de software. Quando os segredos ficam espalhados por diferentes locais, é difícil rastreá-los e atualizá-los, o que aumenta o risco de acesso não autorizado. Outro problema é o uso de privilégios de longa duração, também chamados de segredos estáticos, que não são rotacionados regularmente.

Embora as plataformas de gerenciamento de segredos possam armazenar e criptografar segredos com eficácia, os segredos estáticos ainda são vulneráveis. Eles podem vazar quando incluídos em texto simples no código-fonte de um aplicativo, registrados nos logs da aplicação ou armazenados em arquivos de configuração. Quanto mais um segredo é usado, maior o risco de comprometimento. Além disso, segredos estáticos podem conceder privilégios persistentes em vários sistemas, dando aos hackers acesso contínuo à sua infraestrutura.

O uso de credenciais estáticas compartilhadas e amplamente utilizadas pode gerar vários problemas. Entre eles estão a falta de um responsável claro; credenciais obsoletas que não foram removidas após a desativação de serviços; a ausência de um processo regular de rotação; a falta de prazo de validade ou limite de tempo de vida; e o uso desnecessário de credenciais estáticas quando há mecanismos de controle de acesso mais seguros disponíveis, como tokens dinâmicos de curta duração.

Em um ataque à cadeia de suprimentos, um hacker se infiltra na cadeia de suprimentos de uma empresa para acessar seus sistemas ou dados. Isso pode ser particularmente perigoso, pois permite que o hacker contorne as medidas de segurança e acesse informações confidenciais. Muitas vezes, o invasor tenta comprometer o código-fonte ou os processos de build, iniciar atividades maliciosas ou viabilizar novos ataques ao longo da cadeia de suprimentos.

É importante que as organizações reconheçam os riscos da proliferação de segredos e adotem medidas para evitar ataques à cadeia de suprimentos. Os produtos de software costumam ser compostos por vários componentes de diferentes fornecedores, armazenados em repositórios distintos. Se hackers conseguirem obter acesso, poderão inserir malware e garantir que o subcomponente seja assinado, fazendo com que ele seja considerado confiável à medida que percorre a cadeia de suprimentos.

Para resolver esses problemas, as organizações podem usar uma solução de gerenciamento de segredos com um cofre criptografado para proteger credenciais e chaves. A solução também deve oferecer aos desenvolvedores fluxos de trabalho simplificados para acessar segredos quando necessário, seguindo políticas aprovadas pela equipe de segurança. Para proteger ainda mais as chaves e credenciais, a solução deve facilitar a rotação de segredos.

Segredos dinâmicos são credenciais geradas sob demanda que concedem acesso temporário a um recurso por um período limitado e com um conjunto restrito de permissões. Como não são armazenados, ficam menos vulneráveis a ataques. Mesmo que um segredo dinâmico seja comprometido, ele se torna inútil antes que um cibercriminoso consiga usá-lo. Segredos dinâmicos costumam ser usados junto com o princípio de privilégios permanentes zero (ZSP, na sigla em inglês): os clientes recebem acesso privilegiado a um recurso apenas com os direitos mínimos necessários para realizar uma tarefa específica e pelo menor tempo possível. Essa abordagem ajuda a reduzir o risco de acesso não autorizado e garante que os privilégios sejam concedidos somente quando necessário.

Como rotacionar segredos

Rotacionar segredos significa substituir um segredo existente, como uma senha, chave de API ou chave SSH, por um novo para reduzir o risco de comprometimento. Isso pode ser feito manual ou automaticamente, dependendo do sistema utilizado.

Há algumas estratégias diferentes para rotacionar segredos:

• Em intervalos regulares: você pode definir um cronograma para rotacionar segredos regularmente. Isso ajuda a reduzir o risco de comprometimento, pois limita o tempo que um invasor tem para tentar explorá-los.

• Sob demanda: você também pode rotacionar segredos sempre que suspeitar que algum foi comprometido ou quiser reduzir proativamente o risco de comprometimento.

• Automação: você pode usar ferramentas e scripts para automatizar a rotação de segredos. Isso ajuda a garantir que eles sejam rotacionados de forma consistente e pontual.

Ao rotacionar segredos, é importante garantir que o novo segredo esteja devidamente protegido, implementado e configurado. Também é necessário comunicar a mudança às partes envolvidas, como administradores de sistemas e usuários.

Repensando a estratégia de gerenciamento de segredos

Embora antes pudéssemos acreditar que nossos segredos estavam seguros, casos anteriores de comprometimento de plataformas levaram as organizações a reavaliar suas estratégias de armazenamento e a buscar os métodos mais seguros. É importante considerar que, depois de usados e incluídos no código, os segredos deixam de ser secretos. Então, qual é a melhor forma de gerenciar segredos? Eles não deveriam ser usados ou deveriam ser usados uma única vez e depois revogados?

Esta publicação será atualizada caso surjam novas informações.