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

作者: Badcode and Longofo@知道創宇404實驗室  

時間: 2020年2月9日

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

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

前言

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

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

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

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

最終是調用了 Runtime.getRuntime().exec()執行了命令。

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

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

漏洞復現

在 Path of "createrepo"里面傳入 payload。

在 Status 欄可以看到執行的結果

第一次繞過分析

第一次補丁分析

官方補丁改了幾個地方，關鍵點在 這里

常規做法，在執行命令前對命令進行過濾。新增加了一個 getCleanCommand() 方法，對命令進行過濾。

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

第二次繞過分析

第二次補丁分析

在我提交上述繞過方式后，官方修復了這種繞過方式，看下官方的 補丁

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

經過 parse() 第二次繞過測試

測試環境

• 2.14.15-01 版本
• Windows

測試步驟

在 Path of "createrepo"里面傳入 payload。

查看進程， notepad.exe 啟動了

可以看到，成功繞過了補丁。

第二次繞過分析+

經過Badcode師傅第二次繞過分析，可以看到能成功在Windows系統執行命令了。但是有一個很大的限制：

1. nexus需要安裝在系統盤
2. 一些帶參數的命令無法使用

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

第二次繞過分析+測試

測試環境

• 2.14.15-01 版本
• Windows

測試步驟

導航到 Views/Repositories->Repositories->3rd party->Configuration，我們可以看到 默認本地存儲位置的絕對路徑（之后上傳的內容也在這個目錄下）：

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

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

同樣在 Path of "createrepo" 里面傳入 payload（這時需要注意前面部分這時是以nexus安裝目錄開頭的，這在補丁中會判斷，所以這里可以在最頂層加 ..\ 或者弄個虛假層 aaa\..\ 等）

可以看到createrepo-1.exe已經執行了：

最新版本分析

最新版本補丁分析

第二次補丁繞過之后，官方又進行了修復，官方 補丁主要如下

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

最新版本驗證

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

在 YumCapabilityUpdateValidator.validate 斷到

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

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