JBoss又发现漏洞了，安全圈儿为之一紧。 知道创宇安全研究团队再次本着科普的情怀收集跟JBoss安全相关的材料，为安全行业再出一把力。

这里先给JBoss正下名。通常所说的JBoss，全称是JBoss Application Server。 它是JavaEE体系里， 一个很流行的应用服务器开源实现。 除了这个JBossAS外，JBoss打头的还有不少产品。不过，由于其它的弟兄在安全视野里很少出场，下文也为了说明方便， 就把JBossAS也简称为JBoss。

关于JBoss安全，网上这方面的东西不少，但初看时， 总是云里雾里的， 搞不明白究竟是说什么的。 这里， 咱试着换另外一种方式来介绍。

先来看基本的攻击思路：利用漏洞部署一个war（war是JavaEE里基本部署单位，对此不了解的请自行google），这个war里一般只有一个jsp的webshell，利用此shell，黑客可做各种猥琐事。

整个过程中，怎么能搞上去一个webshell是核心。这个“搞上去”，在JBoss世界里，就是deploy一个war。 JBoss可真是煞费苦心地提供了N多种部署策略，又在无意中为这N多种部署策略提供M种调用方式，于是乎，跟JBoss相关的漏洞也就理所当然出现了N*M种。这也是造成JBoss漏洞纷繁复杂不好理解的一大原因。咱这篇文章就是要从这纷繁复杂的乱象里趟出一条“血路”来。

话题扯的有些远了，回到主题上来。 这里用最流行的那个漏洞形象地介绍上面的过程和其中的关键概念。

看下图，用这么个url可以方便地部署个“一句话后门”。这里，为了方便阅读方便，对这个长url做了分行处理并加了适当的说明。

JBoss收到这个请求后，就会部署一个shell.war的文件夹，它里面只有一个文件shell.jsp。随后就可以利用此shell.jsp执行各种命令啦。

简短介绍了部署流程后，重点说下上图中红框内标示的三部分。

1， 先说第二个“DeploymentFileRepository”， 它是JBoss运行环境里创建的JMX对象，可通过“jboss.admin:service”名找到。 这个对象实质上是一个服务，  DeploymentFileRepository名字出卖了它的作用， 可以deploy一个file。

2， 再回过头来看第一个"jmx-console/HtmlAdaptor",  它本质上是JBoss内在服务的调用接口。 这里关于JMX多说两句。 JMX作为JavaEE体系里一个标准，是为了方便运维（与监控）而设计的，其基本思想是给每一个服务主体创建一个“影子”对象，这个“影子”对象可控制查看主体对象的一切。这里的“jmx-console/HtmlAdaptor”正是控制查看所有影子对象的一个总入口。

3， 第三部分不用太多地说明， 它是黑客行为的最终目标。  其内容可以定制，表现形式又随具体的攻击组合不同而异。 也就是“蛊”可以随场景和目的不同而定制。

借助这个典型事件分析，从而对JBoss攻击所涉及概念有形象了解后，看针对JBoss常见的攻击方式，也就是种蛊方式。

1，jmx-console/HtmlAdaptor + DeploymentFileRepository。 也就是上面详细分析的那个。 之所以这里再列出来， 完全是为了向其致敬。 可以说， 这个种蛊方式最方便。 也正是它，才有了当年大名鼎鼎的JBoss蠕虫事件。 不过， 随着行业对JBoss安全的重视，适合此组合的场景已经很少有了。

2，/jmx-console/HtmlAdaptor +  BSHDeployer。 跟上面的类似， 不过， 换了另一种部署方式。 这里的BSH是一种shell语言， JVM支持， JBoss也可就出于顺便支持了。  这个方式是实际是通过HTTP请求给BSHDeployer传了一段beanshell脚本，黑客关心的webshell就内嵌在这个脚本里。

3， web-console/Invoker +  DeploymentFileRepository。 跟第一种类似， 只不过是换了调用的入口，背后的服务还是DeploymentFileRepository。

4，invoker/JMXInvokerServlet + application/x-java-serialized-object;class=org.jboss.invocation.MarshalledInvocation + BSHDeployer。这个在利用方式上跟前面几个稍稍不同。前面几个上传的payload还是肉眼可以直接读出的文本，这个有变化了，它实质是发送了一个用HTTP请求发送RMI。这个过程在原理上相当于在第2个的基础上套了一层 MarshalledInvocation调用。稍微介绍下 MarshalledInvocation。 Java里，可以方便地把一次方法调用用一个Java类描述下来，随后再编译后字节码通过网络发送，服务端收到请求后，再解析这个字节码里的调用信息。这里，最终又把请求转给了 BSHDeployer。

5，  invoker/JMXInvokerServlet +application/x-java-serialized-object;class=org.jboss.invocation.MarshalledInvocation + MainDeployer。回到这些天爆出的利用方式（http://www.exploit-db.com/exploits/28713/）了。 这种方式跟第4种类似，不同体现在MainDeployer。上面第4种用BSHDeployer时， webshell全部内容可以在请求中传送，而MainDeployer就不行了， 它需要一个指向远程war的url，MainDeployer把这个war下载下来后，再正常地部署。

...

就到这里吧，上面的组合是比较典型的，不过，借助它们可以很好地理解JBoss漏洞利用了。

危害呢？ JBoss漏洞的利用本质上是创建一个webshell，这样它的危害就转化成webshell的功能和Jboss进程的用户权限。如果放任自流，然后… 就没有然后了。

如何防御？从上面的分析，我们知道，webshell的部署过程有两个关键点：找到合适的入口调用合适的服务。顺着这个思路，把用不着的服务统统关掉，尽可能地减少访问入口（或关掉访问入口或加强权限拦截）。当然，加速乐已经完全做了相应的防护，运维的筒子们可放心滴使用啦。