怎样种蛊给人小惩罚

给JBoss种蛊分析
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-class=org.jboss.invocation.MarshalledInvocation + BSHDeployer。这个在利用方式上跟前面几个稍稍不同。前面几个上传的payload还是肉眼可以直接读出的文本,这个有变化了,它实质是发送了一个用HTTP请求发送RMI。这个过程在原理上相当于在第2个的基础上套了一层 MarshalledInvocation调用。稍微介绍下 MarshalledInvocation。 Java里,可以方便地把一次方法调用用一个Java类描述下来,随后再编译后字节码通过网络发送,服务端收到请求后,再解析这个字节码里的调用信息。这里,最终又把请求转给了 BSHDeployer。
5, &invoker/JMXInvokerServlet +application/x-java-serialized-class=org.jboss.invocation.MarshalledInvocation + MainDeployer。回到这些天爆出的利用方式(http://www./exploits/28713/)了。 这种方式跟第4种类似,不同体现在MainDeployer。上面第4种用BSHDeployer时, webshell全部内容可以在请求中传送,而MainDeployer就不行了, 它需要一个指向远程war的url,MainDeployer把这个war下来后,再正常地部署。
就到这里吧,上面的组合是比较典型的,不过,借助它们可以很好地理解JBoss漏洞利用了。
危害呢? JBoss漏洞的利用本质上是创建一个webshell,这样它的危害就转化成webshell的功能和Jboss进程的用户权限。如果放任自流,然后& 就没有然后了。
如何防御?从上面的分析,我们知道,webshell的部署过程有两个关键点:找到合适的入口调用合适的服务。顺着这个思路,把用不着的服务统统关掉,尽可能地减少访问入口(或关掉访问入口或加强权限拦截)。当然,加速乐已经完全做了相应的防护,运维的筒子们可放心滴使用啦。
您对本文章有什么意见或着疑问吗?请到您的关注和建议是我们前行的参考和动力&&
您的浏览器不支持嵌入式框架,或者当前配置为不显示嵌入式框架。

我要回帖

更多关于 九岁小蛊妃 的文章

 

随机推荐