CVE-2019-11229詳細分析 --git config可控-RCE

時間 2020-03-23

標籤 cve 詳細分析 git config 可控 rce 欄目 Git 简体版

原文原文鏈接

做者：LoRexxar'@知道創宇404實驗室

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

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.github

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

分析補丁

首先根據cve的信息，肯定漏洞1.7.6和1.8.0-rc3上修復
. https://github.com/go-gitea/gitea/releases/tag/v1.7.6
. https://github.com/go-gitea/gitea/releases/tag/v1.8.0-rc3
根據漏洞文件爲repo_mirror.go這個信息鎖定更新的commit，commit主要爲 #6593和#6595
. https://github.com/go-gitea/gitea/pull/6595/commits/52af826a7aa1df6ab538d881db236698cb367cd7
根據patch能夠大體鎖定問題的關鍵點
/models/repo_mirror.go

當倉庫爲mirror倉庫時，settings頁面會顯示關於mirror的配置api

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

patch中將原來的修改配置文件中的url選項修改成NewCommand。很容易理解，將寫入文件更改成執行命令，這種修復方式必定是由於寫入文件存在沒法修復這個問題的窘境，那麼這也就說明url這裏能夠經過傳入%0d%0a來換行，致使修改config中的其餘配置。ssh

控制 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文件的內容。
比較有趣的是，若是你更新同步設置時，服務端還會格式化配置。
ide

進一步利用

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

首先，git服務端只會保留.git裏的內容，並非完整的相似咱們客戶端使用的git倉庫。因此很難引入外部文件。不然就能夠經過設置hook目錄來實現RCE，這種思路的關鍵點在於找到一個可控的文件寫入或者文件上傳。fetch

其次，另一種思路就是尋找一個可以執行命令的配置，並尋找一個可以觸發相關配置的遠程配置。
.https://git-scm.com/docs/git-configurl

經過寫文件配合 githook path RCE

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

在web界面，只有gitea的管理員才能管理git hook，因此對於普通用戶來講，咱們就不能直接經過編輯git hook來修改腳本。spa

但咱們卻能夠經過控制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="""