记一次反序列化漏洞的利用之路

一次偶然的机会拿到了一套系统的源码，结合CodeQLpy很容易发现了其中存在的反序列化漏洞，如图1.1所示。这是属于标准的java反序列化，也没有进行任何过滤。

CodeQlpy项目地址：

https://github.com/webraybtl/CodeQLpy

图1.1 目标源码中存在的反序列化漏洞

1） 确认反序列化漏洞存在

一般来说确认反序列化漏洞都可以使用URLDNS链，因为这条链是属于JDK自带的，不依赖于第三方jar包，只要目标DNS出网一般即可利用成功，具有较强的通用性。

直接使用ysoserial就可以生成URLDNS链需要的序列化内容，为了方便我们使用，需要稍微修改一下ysoserial.payloads.util.PayloadRunner的run方法，如图2.1所示。这里主要修改的内容是保存序列化的数据到文件cc.ser，并且不进行反序列化操作。

图2.1 修改yso中的方法保存序列内容

这样之后下一步就可以通过run方法来生成我们想要的序列化内容，如图2.2所示。

在目标环境下进行测试发现确实可以通过URLDNS链来触发DNS请求，如图2.3，图2.4所示。

图2.3 发送序列化的数据内容

图2.4 DNSLOG中查看日志

上面URLDNS链的利用情况是很顺利的，也确实证明了这个位置存在反序列化漏洞。但是URLDNS链只能产生DNS请求，并不具有实际的危害，要达到RCE的效果还需要其他利用链。

2） CommonCollections链

CommonCollections链作为反序列化中最常见的链，正好在目标的源码中也存在相应的jar包，如图2.5所示。

图2.5 存在CC.jar

起初看到这个jar包是很开心的，认为已经成功了一半，直接用ysoserial中的CC链来生成对应序列化的内容，如图2.6所示。

图2.6 生成cc1链对应的序列化文件

但是在实际环境中却失败了，并没有收到ping发出来的dns请求，也就是命令执行失败了。目标环境是linux的，这个已经提前确认。

抱着不死心的态度，把cc1-cc7的整个7条链都试了一遍，都没有成功。基本确认应该是有问题的，这才想起我是有源码的，虽然这个源码并不能完整的搭建，但是调试反序列化还是完全可行的，在目标源码中来反序列化刚才用yso生成的序列化的文件，如图2.7所示。

图2.7 目标环境下反序列化cc.ser报错

从图2.7的报错中可以看出这里爆出org.apache.commons.collections.functors.InvokerTransformer反序列化中的异常，根本原因在于目标环境中的InvokerTransformer没有继承Serializable接口，如图2.8所示。

图2.8 目标环境下InvokerTransformer类

继承情况

这应该是apache官方修复CommonCollections包导致反序列化利用的一种修复方式，所以这里就没办法继续使用CC链来进行攻击了。

3） CommonsBeanutils链

CC链虽然不能用了，但是在系统存在的jar包中发现了CB链对应的jar包，如图2.9所示。

图2.9 存在CB.jar

从版本来看是属于有漏洞的版本，但是实际测试的时候还是没有成功，用同样的方式在本地进行调试，报错如图2.10所示。

图2.10 直接使用CB链生成的payload

反序列化报错

从网上找了一下这个报错的原因，是因为commons-beanutils版本不一致导致的错误。如果两个不同版本的库使用了同一个类，而这两个类可能有一些方法和属性有了变化，此时在序列化通信的时候就可能因为不兼容导致出现隐患。因此，Java在反序列化的时候提供了一个机制，序列化时会根据类的属性和方法，通过固定算法计算出一个当前类的serialVersionUID值，写入数据流中；反序列化时，如果发现对方的环境中这个类计算出的serialVersionUID不同，则反序列化就会异常退出，避免后续的未知隐患。

找到了问题的原因，那解决办法也就很简单了，为了避免其他包的版本不一致导致问题，我直接把ysoserial的源码拷贝到目标源码中来执行，使用目标源码的jar包来作为依赖。如图2.11，图2.12所示

图2.11 发送CB链生成的序列化数据

图2.12 使用ping命令查看的DNS日志

到这一步，已经通过CB链来达到RCE的效果。

通过这次对这次遇到的反序列化漏洞进行跟踪，可以总结下面的经验：