Ataque dos Clones 2: A Execução Remota de Código na CLI do Git Contra-ataca

Introdução

Este post é a segunda parte da história de uma vulnerabilidade que poderia ser usada como um ataque à cadeia de suprimentos para hackear milhões de desenvolvedores de software ao redor do mundo.

Descreveremos todos os detalhes sobre a CVE-2020-26233, uma vulnerabilidade que afeta todas as versões anteriores à 2.0.280 do Git Credential Manager Core na ferramenta Github CLI (também chamada de gh) para Windows.

Descrição do problema

Este problema era semelhante à execução remota de código no Github for Desktop que descobrimos e publicamos em nosso blog, mas desta vez outro componente foi afetado: o Git Credential Manager Core.

Por padrão, quando o Git clona um repositório com submódulos, ele primeiro clona o nível superior do repositório e, em seguida, clona os submódulos recursivamente. No entanto, ao fazer isso, ele inicia um novo processo Git a partir do diretório de nível superior.

Se um executável malicioso chamado git.exe fosse colocado no diretório raiz do repositório, esse binário seria chamado pelo Git Credential Manager Core ao tentar ler a configuração. O processo de clonagem ocorre normalmente e não há indicação visual de que um binário malicioso foi executado em vez do executável original do git.

Desde o nosso primeiro relatório em novembro de 2020, uma biblioteca SafeExec foi criada pelo Github para mitigar os riscos trazidos pela discrepância na ordem de busca de binários no Windows.

Como uma rápida recapitulação, o Windows verifica primeiro a presença de um determinado binário na pasta atual e, apenas se não o encontrar, percorre os diretórios na variável de ambiente %PATH% até encontrar o executável em questão.

Na versão 1.2.1 do gh, a função safeexec.LookPath foi introduzida, em teoria impedindo a execução remota de código ao clonar um novo repositório através do abuso da ordem de busca de caminhos do Windows.

Ao analisar mais de perto, nosso engenheiro de segurança Vitor Fernandes descobriu um bypass que poderia ser explorado para obter RCE, exatamente como antes.

Durante o processo de descoberta da vulnerabilidade, Blaze notou que, ao criar um novo repositório privado, um cenário de execução remota de código ainda era possível, pois após o clone, o comando git.exe config credential.namespace é chamado sem a função safeexec.LookPath , fazendo com que o Windows recorra ao seu padrão e procure pelo binário git.exe no repositório clonado atual:

A partir do código em src/shared/Microsoft.Git.CredentialManager/CommandContext.cs:

Como podemos ver, na linha 89 um novo processo será criado buscando pelo git.exe e, como argumentos de caminho de diretório, o Environment.LocateExecutable(‘git.exe’) será passado para a função GitProcess() .

A imagem abaixo mostra a função Environment.LocateExecutable() :

/src/shared/Microsoft.Git.CredentialManager/EnvironmentBase.cs

O código da função environment.TryLocateExecutable pode ser encontrado aqui:

Ao utilizar o utilitário do Windows where.exe ele retorna TODAS as ocorrências de um arquivo ou comando, incluindo os valores de %PATH% e o diretório atual, conforme explicado nesta thread do StackOverflow

Explorando a vulnerabilidade

As seguintes etapas são necessárias para explorar a falha:

a) Crie um novo repositório ou tenha permissão para adicionar arquivos a um existente;
b) Faça o upload de um executável do Windows para este repositório e renomeie-o para git.exe;
c) Aguarde até que a vítima faça um fork do repositório
d) Aproveite seu shell

No exemplo abaixo, o calc.exe foi renomeado para git.exe e enviado para o repositório:

Ao realizar o fork do repositório com o comando gh repo fork REPOSITORY_NAME –clone a calculadora é aberta:

Correções e soluções alternativas

A versão 2.0.289 do GCM Core contém a correção para esta vulnerabilidade. Ela também está incluída na versão 2.29.2(3) do Git para Windows.

Uma solução alternativa sugerida em [1] orienta os usuários a evitar a clonagem recursiva de repositórios não confiáveis usando o parâmetro de linha de comando –recurse-submodules.

O commit 5b4a08dcb9bc63f8da5f966b4e47d73edf87f3b7 introduz uma correção para esta vulnerabilidade.