JavaMelody元件XXE漏洞解析
轉載請註明出處並附上源連結
版權所有，侵權必究
我們專注漏洞檢測方向：danenmao、arnoxia、sharker、lSHANG、KeyKernel、BugQueen、zyl、隱形人真忙、oxen（不分先後）
0x00 概述
JavaMelody 是一個用來對 Java 應用進行監控的元件。通過該元件，使用者可以對記憶體、 CPU 、使用者 session 甚至 SQL 請求等進行監控，並且該元件提供了一個視覺化介面給使用者使用。
最近，該元件被爆出一個 XXE 漏洞—— CVE-2018-15531 ，由於該元件的啟動特性，攻擊者無需特定的許可權即可發起攻擊。
0x01 漏洞復現
我們使用 SpringBoot web 來搭建基礎專案，然後將 JavaMelody 整合進來，在 maven 中配置如下：
訪問http://127.0.0.1/monitoring出現如下頁面表示環境搭建成功
由於這裡是沒有回顯的，因此可以使用 Blind XXE 來讀取檔案進行攻擊：
DTD 檔案構造如下：
在 JavaMelody 的預設配置下，直接發包就可以觸發該漏洞。
需要注意的是，構造回顯通道時，如果是低版本的 jdk ，可以直接使用 gopher 協議回傳。如果是高版本 jdk ，則不支援 gopher 協議，那麼可以使用 FTP 回顯技巧來讀取多行檔案。
0x02 漏洞細節
我們先來看一下官方的補丁程式碼： https://github.com/javamelody/javamelody/commit/ef111822562d0b9365bd3e671a75b65bd0613353
可以看到，官方在net/bull/javamelody/PayloadNameRequestWrapper.java中新增了對XMLInputFactory配置的程式碼，禁用了外部實體解析和dtd實體解析。因此，很容易判斷出這裡是一個XXE漏洞。
為什麼這個漏洞隨意發包即可觸發漏洞呢？這和JavaMelody啟動過程有關。在觸發該漏洞後，我們在PayloadNameRequestWrapper中下斷點：
通過呼叫歷史資訊可以發現，請求進入了一個MonitoringFilter攔截器中。
Springboot中肯定是沒有配置這個filter的，檢視jar包發現，該攔截器是通過web-fragment.xml進行的配置：
在配置項中我們可以發現這個filter預設是處理所有請求：
因此，外部請求會進入MonitoringFilter的doFilter方法，之後呼叫了createRequestWrapper方法：
然後來到了PayloadNameRequestWrapper-> initialize方法中：
在處理soap相關的content-type時，只關注application/soap+xml,text/xml。如果發現content-type型別滿足if條件，則呼叫parseSoapMethodName方法執行解析，繼續跟進該方法：
在該方法中直接呼叫了XMLStreamReader對XML進行了解析，並沒有對外部實體解析以及dtd解析進行限制，因此出現了XXE漏洞。
0x03 漏洞修復
該漏洞修復比較簡單，直接更新JavaMelody至1.74.0即可，或者自己寫攔截器來處理惡意請求。
當然，值得注意的是，如果洩漏了/monitoring路由，其實本身就是一個很嚴重的資訊洩露漏洞。因為JavaMelody提供了非常豐富的功能，比如執行gc，殺掉執行緒，檢視SQL請求，檢視系統資訊、程序，檢視資料庫schema資訊等。
因此，如果在生產環境部署使用了JavaMelody，那就需要自行配置基礎認證或者編寫程式碼來限制其訪問許可權。
0x04 參考
[1]https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15531
[2]https://github.com/javamelody/javamelody/commit/ef111822562d0b9365bd3e671a75b65bd0613353
