JavaMelody组件XXE漏洞解析

我们专注漏洞检测方向：danenmao、arnoxia、sharker、lSHANG、KeyKernel、BugQueen、zyl、隐形人真忙、oxen（不分先后）

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