Para ajudar a mitigar o impacto da falha de exposição de credenciais, o GitHub alternou chaves potencialmente expostas.
Sim. O GitHub alternou chaves potencialmente expostas por uma vulnerabilidade corrigida em dezembro que poderia permitir que invasores acessassem credenciais em contêineres de produção por meio de variáveis de ambiente.
GitHub alternou chaves potencialmente expostas
Esta vulnerabilidade de reflexão insegura (rastreada como CVE-2024-0200) pode permitir que invasores obtenham execução remota de código em servidores não corrigidos.
Também foi corrigido na terça-feira nas versões 3.8.13, 3.9.8, 3.10.5 e 3.11.3 do GitHub Enterprise Server (GHES), com a empresa pedindo a todos os clientes que instalem a atualização de segurança o mais rápido possível.
Embora permita que os agentes da ameaça obtenham acesso às variáveis de ambiente de um contêiner de produção, incluindo credenciais, a exploração bem-sucedida requer autenticação com uma função de proprietário da organização (com acesso de administrador à organização).
“Em 26 de dezembro de 2023, o GitHub recebeu um relatório por meio de nosso Programa Bug Bounty demonstrando uma vulnerabilidade que, se explorada, permitia acesso a credenciais dentro de um contêiner de produção. Corrigimos essa vulnerabilidade no GitHub.com no mesmo dia e começamos a alternar todos os potencialmente expostos credencial”, disse o vice-presidente do Github e diretor adjunto de segurança, Jacob DePriest.
“Após realizar uma investigação completa, avaliamos com alta confiança, com base na singularidade deste problema e na análise de nossa telemetria e registro, que esta vulnerabilidade não foi encontrada e explorada anteriormente.”
Embora o requisito da função de proprietário da organização seja um fator atenuante significativo e o impacto da vulnerabilidade seja limitado ao pesquisador que encontrou e relatou o problema por meio do Bug Bounty Program do GitHub, DePriest diz que as credenciais ainda foram alternadas de acordo com os procedimentos de segurança e “de uma abundância de Cuidado”.
Embora a maioria das chaves rotacionadas pelo GitHub em dezembro não exija nenhuma ação do cliente, aqueles que usam a chave de assinatura de commit do GitHub e GitHub Actions, GitHub Codespaces e chaves de criptografia do cliente Dependabot terão que importar as novas chaves públicas.
“Recomendamos fortemente extrair regularmente as chaves públicas da API para garantir que você esteja usando os dados mais atuais do GitHub. Isso também permitirá a adoção perfeita de novas chaves no futuro”, disse DePriest.
O GitHub também corrigiu uma segunda vulnerabilidade de injeção de comando do Enterprise Server de alta gravidade (CVE-2024-0507) que permitiria que invasores usassem uma conta de usuário do Management Console com função de editor para escalar privilégios.
Esta não é a primeira vez que a empresa teve que alternar ou revogar segredos expostos ou roubados no ano passado.
Por exemplo, ele também alternou sua chave SSH privada do GitHub.com em março passado, depois que ela foi acidentalmente e “brevemente” exposta por meio de um repositório público do GitHub, impactando as operações do Git sobre SSH usando RSA.
O incidente ocorreu semanas depois que a empresa começou a implementar a verificação de segredos para todos os repositórios públicos, que deveria ter capturado a chave exposta, uma vez que suporta chaves de API, senhas de contas, tokens de autenticação e outros alertas de dados confidenciais.
Meses antes, o GitHub também teve que revogar certificados de assinatura de código para seus aplicativos Desktop e Atom depois que invasores desconhecidos os roubaram após violar os repositórios de desenvolvimento e planejamento de lançamento da empresa em dezembro de 2022.
