Ciberataques com IA: Como detetar, prevenir e defender-se contra ameaças inteligentes

Ler agora
Utilizamos inteligência artificial para as traduções dos sítios e, embora nos esforcemos por garantir a exatidão, estas podem nem sempre ser 100% precisas. Agradecemos a sua compreensão.

Analisar e corrigir a vulnerabilidade do Git CVE-2024-32002

por OPSWAT
Partilhar esta publicação
Minh Pham e Thai Do, estudantes da Universidade de Tecnologia de Ho Chi Minh, que participaram no Programa de Bolsas de Estudo OPSWAT
Os estudantes participaram no programa de bolsas de estudo OPSWAT .

Uma vulnerabilidade crítica no Git que permite ataques RCE (execução remota de código) foi recentemente divulgada, afetando várias versões do Git e do Microsoft Visual Studio 2017. A vulnerabilidade permite que os atacantes manipulem repositórios Git usando submódulos, explorando um bug no Git que permite que os arquivos sejam escritos fora da árvore de trabalho do submódulo e no diretório .git/. Este bug permite a execução de um hook malicioso enquanto uma operação de clonagem de repositório ainda está a decorrer [1]. 

A vulnerabilidade CVE-2024-32002 afeta o Microsoft Visual Studio 2017 versão 15.9 e as versões do Git anteriores a 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2 e 2.39.4. Pode ser explorada em ambientes em que o suporte de ligações simbólicas está ativado em sistemas operativos que não fazem distinção entre maiúsculas e minúsculas. 

CVSS (Common Vulnerability Scoring System) 3.x informações de gravidade e vetor com uma pontuação base de 9.0 rotulada como crítica, fornecida pela GitHub, Inc.

Compreender o Git

O Git é um sistema de controlo de versões distribuído, gratuito e de código aberto, concebido para ajudar os programadores de software a gerir bases de código de forma rápida e eficiente. Melhora a colaboração entre os membros da equipa de desenvolvimento, organizando e acompanhando as alterações aos ficheiros e diretórios de uma forma normalizada e estruturada. 

O Git é amplamente utilizado no desenvolvimento de software. Plataformas como o GitHub, o GitLab e o Bitbucket são construídas com base no Git para melhorar a colaboração entre os programadores devido às suas poderosas funcionalidades: 

  • Registo de alterações rastreáveis em ficheiros de código, conhecidas como commits
  • Reverter as edições de código para versões anteriores, quando necessário. 
  • Combinar eficazmente alterações de diferentes ramos ou contribuidores. 
  • Manter um registo do histórico de quem fez as alterações e as respectivas datas.
Uma representação visual de uma estrutura de pastas .git, exibindo diretórios como config, HEAD, hooks, objetos e refs.

Ganchos do Git 

Quando um repositório Git é criado ou clonado, usando os comandos git init ou git clone, um diretório .gité gerado na raiz da árvore de trabalho. A estrutura de diretórios do diretório .git inicialmente se parece com isso: 

Os hooks do Git são scripts executáveis, localizados no diretório .git/hooks ou no diretório .git/modules/module_type/module_name/hooks. Os hooks são automaticamente acionados quando ocorrem eventos específicos num repositório Git.  

Quando um ficheiro no diretório de hooks não tem um sufixo .sample, os comandos nesse ficheiro serão executados antes ou depois de uma determinada ação do Git que esteja incluída no nome do ficheiro, tal como pre-commit, post-commit e post-checkout

Submódulos Git

Um submódulo Git é um registo dentro de um repositório Git que faz referência a um commit específico num repositório externo. Quando um submódulo é adicionado a um repositório, é criado um novo ficheiro no diretório .gitmodules com metadados do mapeamento entre o URL do submódulo e o seu diretório local. Quando um repositório contém vários submódulos, o arquivo .gitmodules incluirá uma entrada para cada um. [3] 

Diagrama que mostra a interação de repositórios e submódulos, ilustrando a relação entre o Repositório A, o Submódulo B e a Pasta C
Exemplo de conteúdo de um ficheiro .gitmodules, que mostra a configuração de um submódulo chamado "Example"
A imagem seguinte mostra o aspeto de um ficheiro .gitmodules: 

Ligações simbólicas (Symlinks)

Uma ligação simbólica, também designada por ligação simbólica ou ligação suave, é um ficheiro que aponta para outro ficheiro ou diretório (designado por "destino") especificando o seu caminho. Se uma ligação simbólica for eliminada, o seu destino não é afetado. [4] 

Uma ligação simbólica no Git é criada como um ficheiro com metadados que o fazem funcionar como uma referência ou um atalho para outro ficheiro. As ligações simbólicas podem ser utilizadas para criar várias referências a um ficheiro sem replicar o seu conteúdo.

Diagrama que ilustra as ligações simbólicas e físicas a um ficheiro (Ficheiro A), mostrando como estas ligações acedem ao mesmo conteúdo do ficheiro
O Git trata os links simbólicos como arquivos especializados que armazenam o caminho para o arquivo ou diretório que eles referenciam. 
Visualização de ligações simbólicas num repositório Git, demonstrando estruturas de diretórios e ficheiros e os seus caminhos de ligações simbólicas
Quando um repositório ou um ramo que contenha uma ligação simbólica é clonado ou submetido a check-out, a ligação simbólica armazenada no Git é convertida numa ligação simbólica no sistema de ficheiros local. 

Análise de vulnerabilidades de segurança do GIT

Análise de patches

Para obter uma compreensão mais profunda das vulnerabilidades de segurança, os especialistas em segurança efectuam frequentemente análises de correcções. Trata-se de uma técnica que ajuda a identificar funções vulneráveis e potenciais vectores de ataque. Os bolseiros OPSWAT examinaram as alterações efectuadas na versão corrigida para resolver a vulnerabilidade CVE-2024-32002 e descobriram que dois ficheiros foram actualizados para resolver esta vulnerabilidade.

Um dos arquivos atualizados é o arquivo submodule--helper.c, que inclui o código que lida com a clonagem de submódulos Git. O novo commit na versão corrigida incluiu os dois seguintes:  

  1. Adição da função dir_contains_only_dotgit para garantir que o diretório dos submódulos não contém quaisquer ficheiros ou diretórios .git.
Alterações de código num ficheiro chamado submodule-helper.c na interface Git, mostrando 83 adições sem eliminações
  1. Foram feitas alterações à função clone_submodule() para incluir uma condição para verificar se o diretório do submódulo existe e está vazio. Se o diretório não estiver vazio, o processo de clonagem será abortado. 
Trecho de código detalhado de um commit do Git, destacando uma função que verifica o conteúdo do diretório durante as operações do submódulo

A segunda atualização no novo commit foi no arquivo t/t7406-submodule-update.sh, adicionando um script de teste para verificar se a vulnerabilidade de segurança foi resolvida. 

Modificações de código expandidas num ficheiro de teste T7406-submodule-update.sh, detalhando as configurações de teste para caminhos de submódulos e ligações simbólicas

Da análise à exploração

Análise do fluxo de trabalho de ligações simbólicas e submódulos no Git

Para além dos conhecimentos obtidos a partir da análise dos patches e da descrição da vulnerabilidade CVE-2024-32002, os bolseiros OPSWAT trabalharam na investigação do fluxo de trabalho das ligações simbólicas e dos submódulos no Git. Desvendaram a sequência de eventos que acontece quando um utilizador clona um repositório:

  1. O Git começa por descarregar ficheiros e diretórios do repositório principal. 
  2. Utiliza as definições especificadas nos ficheiros de ligações simbólicas para recriar as ligações simbólicas correspondentes no sistema de ficheiros local.  
  3. Se a ligação simbólica apontar para um ficheiro existente, a ligação simbólica será funcional; caso contrário, a ligação simbólica permanece inoperante até que o destino seja restaurado.  
  4. Se o repositório for clonado com a opção --recursive, o Git clona os submódulos (repositórios externos) e os coloca em caminhos de diretório conforme indicado no arquivo .gitmodules.  
  5. Se um link simbólico fizer parte do caminho do submódulo (por exemplo, util/module/test, onde util é um link simbólico que aponta para outro diretório, como symlink_folder), o Git armazenará o conteúdo do submódulo no diretório real referenciado pelo link simbólico (por exemplo, symlink_folder/module/test), permitindo o acesso através do caminho original do link simbólico. 
Um fluxograma visual que mostra os passos para clonar um repositório, descarregar ficheiros e diretórios, recriar ligações simbólicas, clonar submódulos e mover para o caminho correto

Compreender a vulnerabilidade de segurança CVE-2024-32002 do Git 

Criação de repositórios maliciosos

Os membros OPSWAT examinaram ainda a criação de repositórios maliciosos com base nas actualizações feitas ao ficheirot/t7406-submodule-update.sh e dividiram este processo nos seguintes passos:

  1. Criar um repositório que contenha um gancho pós-checkout
Um trecho de código de terminal que apresenta os comandos para configurar um gancho pós-checkout no Git, incluindo a criação de diretórios e a adição de scripts
  1. Criação de outro repositório que inclui um submódulo, localizado no caminho A/modules/x. O novo submódulo faz referência ao repositório criado anteriormente.
Um trecho de código de terminal que demonstra o processo de adicionar um submódulo a um repositório usando comandos Git
  1. Criando um link simbólico chamado a, apontando para a pasta .git no índice do Git. 
Um exemplo de script de terminal que destaca comandos para criar e confirmar um ficheiro .git como um utilitário num repositório
Um fluxograma que descreve um cenário de ataque em que um repositório de ganchos maliciosos é adicionado como um submódulo a um repositório principal, levando à execução de scripts
Um diagrama que mostra como um atacante pode explorar o CVE clonando um repositório 

Compreender a falha de segurança

Quando um utilizador clona um repositório malicioso, criado no passo anterior, utilizando a opção --recursive, o script malicioso do gancho pós-checkout será ativado, permitindo ao atacante comprometer o dispositivo do utilizador. 

Esta execução remota de código ocorre porque o repositório principal detecta uma ligação simbólica denominada a que aponta para o diretório .git quando clonado. Com o modo recursivo ativado, os submódulos também são puxados para o repositório clonado. Este repositório contém uma pasta hooks, que contém o script de hook pós-checkout, e o seu diretório local está em A/modules/x.  

Como a aponta para o diretório.git e o sistema de arquivos não diferencia maiúsculas de minúsculas, A é interpretado como equivalente a a. O Git é induzido a escrever o script do gancho pós-checkout no diretório .git/modules/query/fast/hooks/. Se um script de gancho pós-checkout for encontrado na pasta . git/modules/{module_type}/{module_name}/hooks, será acionado quando o repositório principal for clonado com a opção --recursive. Como resultado, os atacantes podem comprometer com êxito o dispositivo do utilizador executando código remoto.

Um diagrama que ilustra a interação da vítima com um repositório malicioso, incluindo a clonagem, a extração de submódulos e a execução não intencional de scripts
Um diagrama que mostra o fluxo do ataque

Simulando a exploração da vulnerabilidade do Git

Com base nas conclusões anteriores, os bolseiros OPSWAT criaram um repositório principal e um gancho para simular a criação de um repositório malicioso:

  1. Inicialmente, recomenda-se configurar o Git para permitir sempre o protocol.file, ativar core.symlinks e definir o nome do ramo predefinido como main (para evitar mensagens de aviso). 
Um snippet de terminal que apresenta comandos para configurar globalmente as definições do Git para o tratamento de links simbólicos e a configuração padrão do ramo
  1. Um script malicioso de hook pós-checkout é adicionado ao diretório hooks. Para garantir que o script post-checkout pode ser executado no dispositivo do utilizador, o script bash que cria este hook inclui o comando chmod +x fast/hooks/post-checkout
Um script de terminal que apresenta um comando Python codificado malicioso incorporado num gancho pós-checkout do Git
  1. É criada uma ligação simbólica no repositório principal, apontando para o diretório .git.
Um script de terminal que demonstra o processo de confirmação de alterações para incluir utilitários e um ficheiro .git no repositório
Uma captura de ecrã de uma listagem de diretórios de repositórios com pastas como src, libs e .gitmodules apresentada numa interface Git
O repositório principal vulnerável
Captura de ecrã de uma interface de repositório Git que mostra um diretório com um gancho de pós-checkout

A pasta /hooks com um gancho pós-checkout

Captura de ecrã que mostra comandos de terminal para clonar um repositório Git e uma sessão do PowerShell com uma ligação de rede estabelecida
Quando o utilizador clona este repositório malicioso, o atacante pode comprometer o dispositivo da vítima. 

Remediação

Para neutralizar a ameaça, os utilizadores podem desinstalar o Git ou aplicar o patch de segurança mais recente. Em alternativa, uma solução como MetaDefender Endpoint pode notificar prontamente o utilizador e apresentar todos os CVEs conhecidos no ambiente através da sua interface intuitiva. MetaDefender Endpoint pode detetar e mitigar os CVEs mais recentes, aproveitando seus recursos com mais de 3 milhões de pontos de dados e mais de 30.000 CVEs associados com informações de gravidade. Ao implementar qualquer uma das contramedidas, o CVE será totalmente contido, eliminando o risco de um ataque cibernético devastador.

Está pronto para colocar MetaDefender Endpoint na linha da frente da sua estratégia de cibersegurança?


Mantenha-se atualizado com OPSWAT!

Inscreva-se hoje para receber as últimas actualizações da empresa, histórias, informações sobre eventos e muito mais.