JavaMelody组件XXE漏洞解析

======================================================

转载原处：https://mp.weixin.qq.com/s/Tca3GGPCIc7FZaubUTh18Q

微信公众号：EnsecTeam（欢迎关注）

======================================================

0x00 概述

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

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

 

0x01 漏洞复现

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

 

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

 

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

DTD文件构造如下：

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

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

0x02 漏洞细节

 

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

https://github.com/javamelody/javamelody/commit/ef111822562d0b9365bd3e671a75b65bd0613353

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

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

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

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

然后来到了PayloadNameRequestWrapper-> initialize方法中：

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

在该方法中直接调用了XMLStreamReader对XML进行了解析，并没有对外部实体解析以及dtd解析进行限制，因此出现了XXE漏洞。

 

0x03 漏洞修复

 

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

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

因此，如果在生产环境部署使用了JavaMelody，那就需要自行配置基础认证或者编写代码来限制其访问权限。

 

0x04 参考

 

[1]https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15531
[2]https://github.com/javamelody/javamelody/commit/ef111822562d0b9365bd3e671a75b65bd0613353