git config RCE CVE-2019-11229的示例分析

今天就跟大家聊聊有關git config RCE CVE-2019-11229的示例分析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

2019年4月15號，gitea曾爆出過一個漏洞，恰逢當時對這個漏洞比較好奇就著手去研究了一下，漏洞的描述是這樣的：

models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to remote code execution.

在和朋友@hammer的一同研究下，成功控制了git config的內容，但是在從git config到RCE的過程遇到了困難，就暫時擱置了，在過了幾個月之后，偶然得到@Lz1y和@x1nGuang兩位大佬的啟發，成功復現了這個漏洞，下面我們就來仔細研究下這個問題。

分析補丁

首先根據cve的信息，確定漏洞1.7.6和1.8.0-rc3上修復

根據漏洞文件為repo_mirror.go這個信息鎖定更新的commit，commit主要為 #6593和#6595

根據patch可以大致鎖定問題的關鍵點

/models/repo_mirror.go

當倉庫為mirror倉庫時，settings頁面會顯示關于mirror的配置

if !repo.IsMirror {
        ctx.NotFound("", nil)
        return
    }

patch中將原來的修改配置文件中的url選項修改為NewCommand。很容易理解，將寫入文件更改為執行命令，這種修復方式一定是因為寫入文件存在無法修復這個問題的窘境，那么這也就說明url這里可以通過傳入%0d%0a來換行，導致修改config中的其他配置。

控制 gitconfig

跟隨前面的邏輯，首先我們新建一個mirror倉庫。

抓包并修改mirror_address為相應的屬性。

mirror_address=https%3A%2F%2Ftest%3A%40github.com%2FLoRexxar%2Ftest_for_gitea.git"""%0d%0a[core]%0d%0atest=/tmp%0d%0aa="""

可以傳入各種配置，可以控制config文件的內容。

比較有趣的是，如果你更新同步設置時，服務端還會格式化配置。

進一步利用

而重要的是如何從config文件可控到下一步利用。

首先，git服務端只會保留.git里的內容，并不是完整的類似我們客戶端使用的git倉庫。所以很難引入外部文件。否則就可以通過設置hook目錄來實現RCE，這種思路的關鍵點在于找到一個可控的文件寫入或者文件上傳。

其次，另外一種思路就是尋找一個能夠執行命令的配置，并尋找一個能夠觸發相關配置的遠程配置。

https://git-scm.com/docs/git-config

通過寫文件配合 githook path RCE

在git中，存在一個叫做Git Hook的東西，是用于在處理一些操作的時，相應的hook就會執行相應的腳本。

在web界面，只有gitea的管理員才能管理git hook，所以對于普通用戶來說，我們就不能直接通過編輯git hook來修改腳本。

但我們卻可以通過控制git config來修改hook存放的目錄。

當我們構造發送

mirror_address=https%3A%2F%2Fgithub.com%2FLoRexxar%2Ftest_for_gitea.git"""%0d%0a[core]%0d%0ahooksPath=/tmp%0d%0aa="""

服務端的config文件變為

這樣我們只要能在服務端的任意位置能夠寫入文件或者創建文件，我們就可以設置hookspath到那里，并觸發git hook來執行命令。

在經過我們的仔細研究之后，我們發現，在漏洞存在的版本1.7.5版本以下，如果編輯服務端的文件，那么服務端的文件就會保存在gitea的運行目錄下生成。

/data/tmp/local-repo/{repo_id}

而這個文件在不重啟gitea的情況下不會清除，而這個repo_id可以從其他的api處挖掘到。

具體詳細利用鏈可以看

https://www.jianshu.com/p/684fa071026a

值得注意的是，這種方式需要知道服務端運行的位置，雖然我們可以認為go的路徑都是比較形似的，也有部分人會在當前編譯目錄下執行。但可以說這種方式還是不算靠譜。

通過控制 git config 配置來 RCE

在@x1nGuang大佬的幫助下，我重新審視了和git config相關的一些配置。

gitProxy

gitProxy是用來針對git協議需要fetch等操作時，需要執行的命令。是一個用來應對特殊場景的配置選項。一般是應用于，在git請求時，可能的需要使用代理應用的場景。

這里我們設置服務端

[core]
    gitproxy                = calc.exe

然后需要注意，同步的url必須為git開頭

但問題在于，由于gitProxy在git設計中，就是執行一個代理應用，所以無論輸入什么，都會被當作一個應用執行，也就沒辦法帶參數。

這樣一來，在實際的利用場景中就又受到了很大的局限，這里可以嘗試用普通項目中的上傳文件功能來上傳一個bin，然后抓包獲取文件路徑，最后通過gitProxy來執行后門。

但同樣的是，這種思路仍舊受限于gitea的運行目錄，不過比起之前的利用方式來說，1.8.0版本也可以利用這種方式來RCE。

sshCommand

在git的文檔中，還有一個配置是sshCommand。

這是一個在git中允許通過特殊的配置，使git fetch/git push 通過ssh來連接遠端的系統。在@Lz1y大佬的博客中也提到了這種利用方式。

https://www.lz1y.cn/2019/07/20/CVE-2019-11229-Gitea-RCE/

我們設置sshCommand為指定的命令

mirror_address=https%3A%2F%2Ftest%3A%40github.com%2FLoRexxar%2Ftest_for_gitea.git"""%0d%0a[core]%0d%0asshCommand=calc.exe%0d%0aa="""

然后設置協議為ssh保存，并點擊同步。

而與gitProxy不同的是，這里可以跟參數

&mirror_address=https%3A%2F%2Ftest%3A%40github.com%2FLoRexxar%2Ftest_for_gitea.git"""%0d%0a[core]%0d%0asshCommand="touch 2333"%0d%0aa="""

看完上述內容，你們對git config RCE CVE-2019-11229的示例分析有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。