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.
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.

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]
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.
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:
- 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.
- 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.
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.
Da análise à exploração
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:
- O Git começa por descarregar ficheiros e diretórios do repositório principal.
- 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.
- 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.
- 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.
- 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.
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:
- Criar um repositório que contenha um gancho pós-checkout
- 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.
- Criando um link simbólico chamado a, apontando para a pasta .git no índice do Git.
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.
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:
- 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 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.
- É criada uma ligação simbólica no repositório principal, apontando para o diretório .git.
A pasta /hooks com um gancho pós-checkout
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?