记一次反序列化漏洞的利用之路
2023-3-10 16:36:5 Author: www.4hou.com(查看原文) 阅读量:55 收藏

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

0x01 前言

一次偶然的机会拿到了一套系统的源码,结合CodeQLpy很容易发现了其中存在的反序列化漏洞,如图1.1所示。这是属于标准的java反序列化,也没有进行任何过滤。(关注烽火台实验室Beacon Tower Lab,为您持续输出前沿的安全攻防技术)

CodeQlpy项目地址:

https://github.com/webraybtl/CodeQLpy

1678435371164884.png

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

0x02 探索

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

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

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

1678435473190992.png

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

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

1678435542213540.png

图2.2 序列化生成

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

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

1678435655445204.png

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

2) CommonCollections链

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

1678435744750592.png

图2.5 存在CC.jar

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

1678435839146197.png

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

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

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

1678436177771789.png

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

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

1678436228195820.png

图2.8 目标环境下InvokerTransformer类继承情况

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

3) CommonsBeanutils链

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

10.png

图2.9 存在CB.jar

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

1678436306157948.png

图2.10 直接使用CB链生成的payload反序列化报错

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

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

1678436402109088.png

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

1678436472163168.png

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

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

0x03 结论

1、 并不是所有的CommonCollections3.2都是可以作为反序列化利用链

2、 CommonsBeanutils链生成的payload会因为自身jar包版本不同导致serialVersionUID报错

3、 如果直接用ysoserial生成的payload不成功,可以在目标源码环境下来调试,避免jar包版本异常导致的错误

如若转载,请注明原文地址

  • 分享至

取消 嘶吼

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟


文章来源: https://www.4hou.com/posts/XV3W
如有侵权请联系:admin#unsafe.sh