JavaMelody组件XXE漏洞解析

文章转载:https://mp.weixin.qq.com/s/Tca3GGPCIc7FZaubUTh18Q
0x00 概述

JavaMelody是一个用来对Java应用进行监控的组件。通过该组件,用户可以对内存、CPU、用户session甚至SQL请求等进行监控,并且该组件提供了一个可视化界面给用户使用。

最近,该组件被爆出一个XXE漏洞——CVE-2018-15531,由于该组件的启动特性,攻击者无需特定的权限即可发起攻击。
 
0x01 漏洞复现

我们使用SpringBoot web来搭建基础项目,然后将JavaMelody集成进来,在maven中配置如下:

20180921164234342.png

访问http://127.0.0.1/monitoring出现如下页面表示环境搭建成功

20180921164323297.png

由于这里是没有回显的,因此可以使用Blind XXE来读取文件进行攻击:

20180921164329795.png

DTD文件构造如下:

20180921164334774.png

 
在JavaMelody的默认配置下,直接发包就可以触发该漏洞。

需要注意的是,构造回显通道时,如果是低版本的jdk,可以直接使用gopher协议回传。如果是高版本jdk,则不支持gopher协议,那么可以使用FTP回显技巧来读取多行文件。
 
0x02 漏洞细节

我们先来看一下官方的补丁代码:

https://github.com/javamelody/javamelody/commit/ef111822562d0b9365bd3e671a75b65bd0613353
 
可以看到,官方在net/bull/javamelody/PayloadNameRequestWrapper.java中新增了对XMLInputFactory配置的代码,禁用了外部实体解析和dtd实体解析。因此,很容易判断出这里是一个XXE漏洞。
为什么这个漏洞随意发包即可触发漏洞呢?这和JavaMelody启动过程有关。在触发该漏洞后,我们在PayloadNameRequestWrapper中下断点:
20180921164348851.png

通过调用历史信息可以发现,请求进入了一个MonitoringFilter拦截器中。
Springboot中肯定是没有配置这个filter的,查看jar包发现,该拦截器是通过web-fragment.xml进行的配置:

20180921164354943.png

在配置项中我们可以发现这个filter默认是处理所有请求:

20180921164400415.png

因此,外部请求会进入MonitoringFilter的doFilter方法,之后调用了createRequestWrapper方法:

20180921164409166.png

然后来到了PayloadNameRequestWrapper-> initialize方法中
20180921164414844.png

在处理soap相关的content-type时,只关注application/soap+xml,text/xml。如果发现content-type类型满足if条件,则调用parseSoapMethodName方法执行解析,继续跟进该方法:
20180921164420245.png


0x03 漏洞修复
该漏洞修复比较简单,直接更新JavaMelody至1.74.0即可,或者自己写拦截器来处理恶意请求。

当然,值得注意的是,如果泄漏了/monitoring路由,其实本身就是一个很严重的信息泄露漏洞。因为JavaMelody提供了非常丰富的功能,比如执行gc,杀掉线程,查看SQL请求,查看系统信息、进程,查看数据库schema信息等。
 

0 个评论

要回复文章请先登录注册