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命令行工具遠程代碼執行漏洞的示例分析”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！