Descoberta e escopo da vulnerabilidade
Uma nova pesquisa de segurança revelou uma falha fundamental na suposição de que o hash de um commit Git assinado é um nome único e inalterável no mundo do software. Dado qualquer commit Git assinado, alguém sem a chave de assinatura pode cunhar um segundo commit com os mesmos arquivos, autor e data, e uma assinatura válida, e o GitHub ainda carimbará "Verified" (Verificado).
Tudo o que um revisor verificaria corresponde. O hash do commit não. Isso importa profundamente para a segurança da cadeia de suprimentos de software, pois compromete a integridade da rastreabilidade de commits em repositórios públicos e privados.
O que mudou agora
Esta descoberta desafia a confiança na verificação de identidade de desenvolvedores baseada em assinaturas criptográficas dentro do ecossistema Git. O GitHub, como plataforma líder de hospedagem de código, utiliza essas assinaturas para indicar que um commit foi feito por uma pessoa ou entidade específica. Se o hash pode ser reescrito mantendo a assinatura válida, a garantia de integridade do histórico de commits é enfraquecida.
Isso significa que um atacante poderia potencialmente substituir um commit legítimo por um malicioso, mantendo a aparência de verificação, sem possuir a chave privada original, desde que consiga manipular o hash de forma que a assinatura ainda seja considerada válida pelo sistema de verificação.
Impacto e alcance
O impacto é direto para equipes de DevSecOps e CISOs que dependem da integridade do histórico de commits para auditoria e conformidade. Se a verificação de commits pode ser enganada, a confiança na origem do código comprometido é reduzida. Isso afeta projetos que utilizam assinaturas de commit para garantir que apenas código aprovado seja mesclado.
A falha não afeta a criptografia subjacente da assinatura em si, mas sim a relação entre o conteúdo do commit e o hash que o identifica. Isso abre uma brecha onde a identidade do autor pode ser mantida visualmente, mas o conteúdo pode ser alterado ou reescrito de forma que o hash original não corresponda mais ao conteúdo, mas a assinatura ainda seja válida para o novo hash.
Vetor e exploração
A exploração teórica envolve a criação de um commit que, ao ser processado pelo GitHub, resulta em um hash diferente, mas que ainda passa na verificação de assinatura. Isso requer um entendimento profundo de como o Git calcula hashes e como o GitHub valida assinaturas em tempo de execução.
Os pesquisadores demonstraram que é possível mintar um segundo commit com os mesmos arquivos, autor e data, e uma assinatura válida. O GitHub ainda carimbará "Verified". Isso ocorre porque o sistema de verificação pode estar validando a assinatura contra o conteúdo do commit de uma maneira que não detecta a divergência no hash global do objeto Git.
Medidas de mitigação recomendadas
Para mitigar os riscos associados a esta descoberta, as organizações devem adotar as seguintes práticas:
- Verificação de integridade: Implementar verificações de integridade de código além das assinaturas de commit, como verificações de hash de arquivo.
- Políticas de branch: Restringir a mesclagem de commits que não tenham assinaturas verificadas por múltiplas chaves.
- Monitoramento de repositórios: Monitorar repositórios críticos para mudanças não autorizadas no histórico de commits.
- Atualização de ferramentas: Garantir que as ferramentas de CI/CD estejam atualizadas para detectar anomalias no histórico de commits.
Implicações regulatórias e operacionais
Para organizações sob regulamentações como LGPD ou SOX, a integridade do histórico de commits é crucial para auditoria. Se a verificação de commits pode ser enganada, a conformidade pode ser comprometida. É necessário revisar as políticas de segurança de software para garantir que a verificação de identidade seja robusta o suficiente para resistir a ataques de reescrita de hash.
Perguntas frequentes
Isso afeta todos os repositórios? A falha afeta repositórios que utilizam a verificação de commits do GitHub. Revisores devem estar cientes.
Como identificar commits comprometidos? Monitorar divergências entre o hash do commit e o conteúdo verificado.
Qual a severidade? Crítica para a integridade da cadeia de suprimentos de software, pois compromete a confiança na origem do código.