rmi反序列化导致rce漏洞修复_记一次Java反序列化漏洞的发现和修复

作者：bit4@勾陈安全

0x00 背景简介

本文是自己对一次反序列化漏洞的发现和修复过程，如有错误请斧正，大神请轻喷。

目标应用系统是典型的CS模式。

客户端是需要安装的windows桌面程序，但是它是大部分内容都是基于Java开发(安装目录有很多Jar包)。

服务端是基于Jboss开发。

客户端和服务端之间的通信流量是序列化了的数据流量。客户端接收和解析数据流量的模式和服务端一样，也是通过http服务，它在本地起了80、81端口，用于接收反序列化对象。

0x01 Java序列化流量特征

特征一

参考特征，反序列化数据看起来就是这个样子: sr 、类名、空白字符

特征二

固有特征，是Java的序列化数据就一定是这样，如果是base64编码的，就是以rO0A开头的。

特征三

参考特征，有些content-type就说明了它是是序列化数据。

0x02 检测工具

当确定是序列化数据后，我使用了2个会主动进行反序列化漏洞扫描的Burp Suite插件：

Java Deserialization Scanner - 能识别流量，也成功报了漏洞，而且使用了多种Payload。

Freddy - 只是识别了流量，并未报漏洞。

当时忘记截图了，这是后续在测试环境的截图：

Freddy的流量识别截图：

0x03 复现方法(攻击服务器端)

使用ysoserial生成一个Payload，这里以Jdk7u21为例，由于是内部系统，我知道服务器上JDK的版本。

java -jar ysoserial-master.jar Jdk7u21 "ping jdk.xxx.ceye.io" > Jdk7u21

将生成的Payload通过Burp suite向服务端进行请求，命令执行成功。

0x04 攻击客户端

晚上回家想了想，返回包也是序列化格式的，是不是可以试试攻击客户端呢？第二天来一试，还真的可以。

对客户端做了一个简单的分析，发现客户端在本地起了80和81端口，也是通过http 服务来接收序列化对象的，反序列化过程和服务端如出一辙。

java -jar ysoserial-master.jar CommonsCollections3 "calc.exe" >CC3-desktop

这里自己想象了一种攻击场景：当攻击者控制了服务器之后，可以干掉这个服务，自己开启一个恶意的服务端，当反序列化请求过来时，都返回一个恶意的响应包，比如反弹shell之类的，凡是使用了该客户端的用户都可能被攻击。危害还是不容小视的。

0x05 防护思路

到了这里就开始考虑修复了，我给开发提供了2种修复思路。

升级

升级服务端所依赖的可能被利用的jar包，当然还包括JDK。不错所料，开发一听就否了。一来升级需要经过各种功能性测试，耗时较长，二来是JDK的升级可能造成稳定性问题(之前一个AMF的反序列化问题就是如此，升了2个月了还没搞定)。

过滤

另一个思路就是过滤了，需要继承Java.io.ObjectInputStream实现一个子类，在子类中重写resolveClass方法，以实现在其中通过判断类名来过滤危险类。然后在JavaSerializer类中使用这个子类来读取序列化数据，从而修复漏洞。

0x06 失败的修复

我将以上的第二种修复思路给到了开发，并提醒参考SerialKiller项目。过了一段时间，开发告诉我修复了，然而我的验证显示漏洞依然存在。

只好硬着头皮去开发电脑上看代码，后来发现开发将过滤方法用在了下图的方法之后，而且是在判断获取到的对象是不是HashMap实例之后(开发不愿意给我截图了...)。到这里我终于发现了点不对劲，在判断对象类型了，岂不是说明已经反序列化完成了？

通过对这个getRequestData()函数的追踪，确定反序列化过程是在一个底层的Jar包中完成的。

0x07 对底层Jar包的分析

然后我拿到这个Jar进行了分析，它是公司自己开发的框架。最后艰难地理出了其中的调用逻辑：该框架基于struts2开发，从下图的调动逻辑可以看出，所有的请求到达服务端后，都会首先经过DataInterceptor这个拦截器，这个拦截器执行的动作就是反序列化数据然后给到Action。上面的getRequestData()方法，已经是在这个流程之后了，属于Action中的逻辑。故而开发的修复方式无效。

DataInterceptor类的实现如下：

public class DataInterceptor

extends BaseInterceptor

{

private static final long serialVersionUID = 1L;

public String intercept(ActionInvocation invocation)

throws Exception

{

HttpServletRequest request = (HttpServletRequest)invocation

.getInvocationContext().get("com.opensymphony.xwork2.dispatcher.HttpServletRequest");

Object action = invocation.getAction();

if ((action instanceof IDataAction))

{

IDataAction richAction = (IDataAction)action;

Serializable model = Toolkit.getSerializer().deserialize(

request.getInputStream());//这里执行了反序列化操作

richAction.setRequestData(model);//将对象传递给了Action，getRequestData()方法才能获取到

}

else if ((action instanceof IDataBundleAction))

{

IDataBundleAction richAction = (IDataBundleAction)action;

Serializable model = Toolkit.getSerializer().deserialize(

request.getInputStream());

richAction.setRequestDataBundle((DataBundle)model);

}

return invocation.invoke();

}

}

JavaSerializer的实现如下：

import java.io.BufferedInputStream;

import java.io.IOException;

import java.io.InputStream;

import java.io.ObjectInputStream;

import java.io.Serializable;

public class JavaSerializer

extends AbstractSerializer

{

public Serializable deserialize(InputStream in)

throws IOException

{

ObjectInputStream oo = new ObjectInputStream(new BufferedInputStream(in));

try

{

return (Serializable)oo.readObject();

}

catch (ClassNotFoundException e)

{

throw new IOException("序列化类文件找不到：" + e.getMessage());

}

finally

{

oo.close();

}

}

到这里就清楚了，真正有漏洞的代码就在这里。

0x08 成功修复

要修复这个漏洞，就需要将上面的第二种过滤修复方法用到这个类里，具体的实现方法和SerialKiller一样。

需要继承Java.io.ObjectInputStream实现一个子类(SerialKiller)，在子类中重写resolveClass方法，以实现在其中通过判断类名来过滤危险类。然后在JavaSerializer类中使用这个子类来读取序列化数据，从而修复漏洞。

通过如上方法修复了该漏洞，验证也是成功修复。修复后的JavaSerializer类：

import com.xxx.xxx.xxx.core.security.SerialKiller;

import java.io.BufferedInputStream;

import java.io.IOException;

import java.io.InputStream;

import java.io.ObjectInputStream;

import java.io.Serializable;

public class JavaSerializer

extends AbstractSerializer

{

public Serializable deserialize(InputStream in)

throws IOException

{

ObjectInputStream ois = new SerialKiller(new BufferedInputStream(in));//SerialKiller是重写了resolveClass方法的子类。

try

{

return (Serializable)ois.readObject();

}

catch (ClassNotFoundException e)

{

throw new IOException("序列化类文件找不到：" + e.getMessage());

}

finally

{

ois.close();

}

}

0x09 意外之喜 - 另一处XMLDecoder反序列化漏洞

然而，对Java包的分析还发现了另外一处反序列化漏洞。问题出在对XML的反序列化过程中，和weblogic的XMLDecoder RCE如出一辙。

漏洞代码如下：

import java.beans.XMLDecoder;

import java.io.IOException;

import java.io.InputStream;

import java.io.Serializable;

public class XmlSerializer

extends AbstractSerializer

{

public Serializable deserialize(InputStream in)

throws IOException

{

XMLDecoder xd = new XMLDecoder(in);//和weblogic的XMLDecoder RCE如出一辙

try

{

return (Serializable)xd.readObject();

}

finally

{

xd.close();

}

}

它的修复方式也是参考了weblogic的，需要实现一个validate 函数，在执行XML解码(XMLDecoder)前，对InputStream对象进行检查过滤。

private void validate(InputStream is){

WebLogicSAXParserFactory factory = new WebLogicSAXParserFactory();

try {

SAXParser parser = factory.newSAXParser();

parser.parse(is, new DefaultHandler() {

private int overallarraylength = 0;

public void startElement(String uri, String localName, String qName, Attributes attributes) throws SAXException {

if(qName.equalsIgnoreCase("object")) {

throw new IllegalStateException("Invalid element qName:object");

} else if(qName.equalsIgnoreCase("new")) {

throw new IllegalStateException("Invalid element qName:new");

} else if(qName.equalsIgnoreCase("method")) {

throw new IllegalStateException("Invalid element qName:method");

} else {

if(qName.equalsIgnoreCase("void")) {

for(int attClass = 0; attClass < attributes.getLength(); ++attClass) {

if(!"index".equalsIgnoreCase(attributes.getQName(attClass))) {

throw new IllegalStateException("Invalid attribute for element void:" + attributes.getQName(attClass));

}

}

}

if(qName.equalsIgnoreCase("array")) {

String var9 = attributes.getValue("class");

if(var9 != null && !var9.equalsIgnoreCase("byte")) {

throw new IllegalStateException("The value of class attribute is not valid for array element.");

}

}

}

}

});

} catch (ParserConfigurationException var5) {

throw new IllegalStateException("Parser Exception", var5);

} catch (SAXException var6) {

throw new IllegalStateException("Parser Exception", var6);

} catch (IOException var7) {

throw new IllegalStateException("Parser Exception", var7);

}

}

0x10 总结

零零散散学习反序列化漏洞已经很长时间了，这是第一次在公司自研框架中发现反序列化漏洞，所以总结记录一下，大神请轻喷！也算是对该漏洞知识的一个梳理。学习还是要实践过、做过了才算是学到了，否则永远不是自己的！

0x11 参考