Nexus Repository Manager 2.x 命令注入漏洞 (CVE-2019-5475) 兩次繞過

作者: Badcode and Longofo@知道創(chuàng)宇404實(shí)驗(yàn)室  

時(shí)間: 2020年2月9日

原文鏈接: https://paper.seebug.org/1260/

英文鏈接: https://paper.seebug.org/1261/

前言

2019年9月初我們應(yīng)急了Nexus Repository Manager 2.x 命令注入漏洞(CVE-2019-5475)，其大致的原因和復(fù)現(xiàn)步驟在   YumCapability 的 activationCondition 方法中。

在上面 Path of "createrepo" 中設(shè)置的值會(huì)通過 getConfig().getCreaterepoPath() 獲取到，獲取到該值之后，調(diào)用 this.validate() 方法

傳進(jìn)來的 path 是用戶可控的，之后將 path 拼接 --version 之后傳遞給 commandLineExecutor.exec() 方法，看起來像是執(zhí)行命令的方法，而事實(shí)也是如此。跟進(jìn) CommandLineExecutor 類的 exec 方法

在執(zhí)行命令前先對(duì)命令解析， CommandLine.parse()，會(huì)以空格作為分隔，獲取可執(zhí)行文件及參數(shù)。

最終是調(diào)用了 Runtime.getRuntime().exec()執(zhí)行了命令。

例如，用戶傳入的 command 是 cmd.exe /c whoami，最后到 getRuntime().exec()方法就是 Runtime.getRuntime().exec({"cmd.exe","/c","whoami"})。

所以漏洞的原理也很簡單，就是在 createrepo或者 mergerepo路徑設(shè)置的時(shí)候，該路徑可以由用戶指定，中途拼接了 --version字符串，最終到了 getRuntime.exec()執(zhí)行了命令。

漏洞復(fù)現(xiàn)

在 Path of "createrepo"里面?zhèn)魅?payload。

在 Status 欄可以看到執(zhí)行的結(jié)果

第一次繞過分析

第一次補(bǔ)丁分析

官方補(bǔ)丁改了幾個(gè)地方，關(guān)鍵點(diǎn)在 這里

常規(guī)做法，在執(zhí)行命令前對(duì)命令進(jìn)行過濾。新增加了一個(gè) getCleanCommand() 方法，對(duì)命令進(jìn)行過濾。

allowedExecutables是一個(gè) HashSet，里面只有兩個(gè)值， createrepo和 mergerepo。先判斷用戶傳入的 command是否在 allowedExecutables里面，如果在，直接拼接 params即 --version直接返回。接著對(duì)用戶傳入的 command進(jìn)行路徑判斷，如果是以nexus的工作目錄( applicationDirectories.getWorkDirectory().getAbsolutePath())開頭的，直接返回 null。繼續(xù)判斷，如果文件名不在 allowedExecutables則返回 null，也就是這條命令需要 以 /createrepo或者 /mergerepo結(jié)尾。都通過判斷之后，文件的絕對(duì)路徑拼接 --version  之后變成了 cmd.exe \c whoami，后面是執(zhí)行不了的?？梢灾苯訄?zhí)行exe，注意后面是還會(huì)拼接 --version的，所以很多命令是執(zhí)行不了的，但是還是有辦法利用能執(zhí)行任意exe這點(diǎn)來做后續(xù)的攻擊的。

第二次繞過分析

第二次補(bǔ)丁分析

在我提交上述繞過方式后，官方修復(fù)了這種繞過方式，看下官方的 補(bǔ)丁

在 getCleanCommand()   C:\\Windows\\System32\\calc.exe \\..\\..\\win.ini

經(jīng)過 parse() 第二次繞過測(cè)試

測(cè)試環(huán)境

• 2.14.15-01 版本
• Windows

測(cè)試步驟

在 Path of "createrepo"里面?zhèn)魅?payload。

查看進(jìn)程， notepad.exe 啟動(dòng)了

可以看到，成功繞過了補(bǔ)丁。

第二次繞過分析+

經(jīng)過Badcode師傅第二次繞過分析，可以看到能成功在Windows系統(tǒng)執(zhí)行命令了。但是有一個(gè)很大的限制：

1. nexus需要安裝在系統(tǒng)盤
2. 一些帶參數(shù)的命令無法使用

在上面說到的 Artifacts Upload上傳處是可以上傳任意文件的，并且上傳后的文件名都是通過自定義的參數(shù)拼接得到，所以都能猜到。那么可以上傳自己編寫的任意exe文件了。

第二次繞過分析+測(cè)試

測(cè)試環(huán)境

• 2.14.15-01 版本
• Windows

測(cè)試步驟

導(dǎo)航到 Views/Repositories->Repositories->3rd party->Configuration，我們可以看到 默認(rèn)本地存儲(chǔ)位置的絕對(duì)路徑（之后上傳的內(nèi)容也在這個(gè)目錄下）：

導(dǎo)航到 Views/Repositories->Repositories->3rd party->Artifact Upload ，我們可以上傳惡意的exe文件：

該exe文件將被重命名為 createrepo-1.exe （自定義的參數(shù)拼接的）：

同樣在 Path of "createrepo" 里面?zhèn)魅?payload（這時(shí)需要注意前面部分這時(shí)是以nexus安裝目錄開頭的，這在補(bǔ)丁中會(huì)判斷，所以這里可以在最頂層加 ..\ 或者弄個(gè)虛假層 aaa\..\ 等）

可以看到createrepo-1.exe已經(jīng)執(zhí)行了：

最新版本分析

最新版本補(bǔ)丁分析

第二次補(bǔ)丁繞過之后，官方又進(jìn)行了修復(fù)，官方 補(bǔ)丁主要如下

刪除了之前的修復(fù)方式，增加了 YumCapabilityUpdateValidator 類，在 validate 中將獲取的值與properties中設(shè)置的值使用 equals 進(jìn)行絕對(duì)相等驗(yàn)證。這個(gè)值要修改只能通過 sonatype-work/nexus/conf/capabilities.xml

最新版本驗(yàn)證

前端直接禁止修改了，通過抓包修改測(cè)試：

在 YumCapabilityUpdateValidator.validate 斷到

可以看到這種修復(fù)方式無法再繞過了，除非有文件覆蓋的地方覆蓋配置文件，例如解壓覆蓋那種方式，不過沒找到。

不過 Artifacts Upload那里可以上傳任意文件的地方依然還在，如果其他地方再出現(xiàn)上面的情況依然可以利用到。