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

Por OPSWAT

Dec 17, 2024

Partilhar esta publicação

Analisar e corrigir a vulnerabilidade do Git CVE-2024-32002 — Os estudantes participaram no programa de bolsas de estudo OPSWAT .

Foi recentemente divulgada uma vulnerabilidade crítica no Git que permite ataques de RCE (execução remota de código), afetando várias versões do Git e do Microsoft Visual Studio 2017. A vulnerabilidade permite que os atacantes manipulem repositórios do Git utilizando submódulos, explorando um bug no Git que permite que ficheiros sejam gravados 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 do 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, utilizando os comandos `git init ` ou `git clone `, é gerado um diretório `.git` na raiz da árvore de trabalho. A estrutura do diretório ` .git ` tem, inicialmente, o seguinte aspeto:

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 compreender melhor as vulnerabilidades de segurança, os especialistas em segurança realizam frequentemente análises de patches. Trata-se de uma técnica que ajuda a identificar funções vulneráveis e potenciais vetores de ataque. Os membros da OPSWAT analisaram as alterações introduzidas na versão corrigida para resolver a vulnerabilidade CVE-2024-32002 e descobriram que dois ficheiros foram atualizados 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

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:

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.

Uma vez que «a» aponta para o diretório.git e o sistema de ficheiros não distingue maiúsculas de minúsculas, «A» é interpretado como equivalente a «a». O Git é levado a escrever o script do gancho pós-checkout no diretório .git/modules/query/fast/hooks/. Se for encontrado um script de hook «post-checkout» na pasta .git/modules/{module_type}/{module_name}/hooks, este será acionado quando o repositório principal for clonado com a opção --recursive. Como resultado, os atacantes podem comprometer com sucesso o dispositivo do utilizador através da execução de 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 ficheiro de protocolo, ativar o 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.

Remediação

Para neutralizar a ameaça, os utilizadores podem desinstalar o Git ou aplicar a mais recente correção de segurança. Em alternativa, uma solução como MetaDefender Endpoint pode notificar imediatamente o utilizador e apresentar todas as CVEs conhecidas no ambiente através da sua interface intuitiva. MetaDefender Endpoint consegue detetar e mitigar as CVEs mais recentes, tirando partido das suas capacidades com mais de 3 milhões de pontos de dados e mais de 30 000 CVEs associadas com informações de gravidade. Ao implementar qualquer uma destas contramedidas, a CVE será totalmente contida, eliminando o risco de um ciberataque devastador.

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

Falar com um especialista