GIT命令行工具远程代码执行漏洞的示例分析

这篇文章主要介绍GIT命令行工具远程代码执行漏洞的示例分析，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！

问题描述

在此之前，我们曾讨论过GitHub桌面端的远程代码执行问题，但这一次受影响的组件则是Git凭证管理器核心。

默认配置下，当Git克隆带有子模块的代码库时，它首先克隆代码库的顶层（根目录），然后递归地克隆子模块。但是在这样做时，它会从顶级目录中启动一个新的Git进程。

如果一个名为git.exe的恶意程序被存放在了代码库根目录下，那么当程序尝试读取配置信息时，Git凭证管理器核心将调用此二进制文件。克隆过程正常进行，并且没有可见的迹象表明运行了恶意二进制文件而不是原始git可执行文件。

自从我们在2020年11月发布第一份报告以来，Github创建了一个SafeExec库，以减轻Windows中二进制文件搜索顺序不一致带来的风险。

简要回顾一下，Windows首先检查当前文件夹中是否存在给定的二进制文件，只有在找不到该二进制文件时，才会遍历%PATH%环境变量中的目录，直到找到目标可执行文件。

在gh的v1.2.1版本中，引入了一个safeexec.LookPath函数，当通过滥用Windows路径搜索顺序克隆新存储库时，可以阻止远程代码执行。

在仔细研究之后，我们的安全工程师Vitor Fernandes发现了一个绕过方法，这样就可以利用它来实现远程代码执行了。

在漏洞发现过程中，我们发现在fork一个新的私有存储库时，仍然可能出现远程代码执行场景。因为在克隆命令执行之后，并不会通过safeexec.LookPath函数来调用“git.exe config credential.namespace”。因此，所以Windows将返回到其默认值并搜索git.exe文件当前克隆存储库中的二进制文件：

下面给出的是src/shared/Microsoft.Git.CredentialManager/CommandContext.cs中的代码：

我们可以看到，在第89行代码处，将创建一个新的进程来搜索git.exe，而“Environment.LocateExecutable('git.exe')”将作为目录路径参数传递给GitProcess()函数。

下图显示的是Environment.LocateExecutable()函数代码：

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

函数environment.TryLocateExecutable的代码：

在使用Windows的实用工具where.exe时，它将会返回所有出现的文件或命令，包括%PATH%和当前目录的值。

漏洞利用

下面给出的是针对该漏洞的漏洞利用步骤：

创建一个新的代码库，或向现有代码库中添加文件；

向这个代码库中上传一个Windows可执行文件，然后将其重命名为exe；

等待目标用户fork这个代码库；

然后成功拿到Shell；

在下面的例子中，我们将calc.exe重命名为了git.exe，并将其上传到目标代码库中：

Fork代码库并执行“gh repo fork REPOSITORY_NAME –clone”命令之后，目标设备将弹出计算器程序：

以上是“GIT命令行工具远程代码执行漏洞的示例分析”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注亿速云行业资讯频道！