作者:EnsecTeam
公众号: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 参考


Paper 本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/705/