某反序列化漏洞分析与复现工作

本文阅读 9 分钟

0x00 概述

GENESIS64软件的多个版本存在反序列化漏洞,影响多个组件,例如:

[](https://p3.ssl.qhimg.com/t0162b3208eda76a2de.png)

[](https://p0.ssl.qhimg.com/t01ad4e1e2aa7ee7ab8.png)

根据CVE漏洞相关描述,下载对应GENESIS软件版本搭建环境,进行漏洞分析与复现工作。

【一>所有资源获取<一】
1、200份很多已经买不到的绝版电子书
2、30G安全大厂内部的视频资料
3、100份src文档
4、常见安全面试题
5、ctf大赛经典题目解析
6、全套工具包
7、应急响应笔记
8、网络安全学习路线

0x01 服务分析

安装完成后对整个系统进行熟悉,发现Web程序接口使用Silverlight进行数据交互,因此需要找到相关功能文件进行分析。经过一些时间查找,找到系统服务开启的配置文件,在配置文件中定义了访问接口信息以及调用的相关配置文件信息:

img

经过多方分析找到FwxServer类,类中定义了重要服务的启动与注册配置,跟进一下StartAsyncServer()进行查看:

img

StartAsyncServer()函数里对配置项进行处理,加载配置项里的配置,在后面有一个FwxServerBase()函数处理了很多的参数,继续跟进:

img

FwxServerBase()函数里只是对配置文件里的配置做了一些设置,但此处发现继承了AsyncServer,再次跟进AsyncServer:

img

AsyncServer()函数最后完成配置相关参数并进行启动。到这里就完成整个服务的创建与启动,当然这里只看了一个启动项目,其他的服务注册与启动都差不多:

img

0x02 漏洞分析

基于前期的服务启动流程以及配置项的分析,最后定位到Asyncserver里处理提交请求的接口中,此接口中定义了几个接口,均为提交请求的处理,于是就用这个作为分析的突破口。

下图中定义了一个服务契约,在服务契约里面有多个处理提交请求的操作契约:

img

我们来对相关参数做一个简单的分析,因为这里只有PutRequests是处理提交请求的,所以先来看看它。这里是判断提交过来的数据里的Session是否失效,失效返回false,如果Session未失效则进入第二层处理Request:

img

在下图可以看到Request()函数对我们提交过来的数据进行了处理:

img

主要的SOAP数据包标签头:

img

标签里的cat标签对应了下面的几种提交类型,几种类型对应了相关的处理方式:

img

img

其他的标签处理大同小异。来到PutRequest()函数,此函数里有一个a函数处理session,跟进分析一下:

img

a()函数里,判断了标签Actor和用户提交的数据A_1,跟进a(A_1)重载函数:

img

可以看到a(A_1)重载函数里只是一个值选项判断,再次回到之前,跟进a(A_0)重载函数:

img

a(A_0)重载函数处理了Session相关数据,也没什么可分析的,接着往下看:

img

接下来看到存在一个if判断,对标签PointName和PointHandle做了值判断,因为一般情况下都会有值,因此这个地方流程一般不会进入,进入else分支分析:

img

在else分支里面进行了一系列的标签值判断,下面代码对提交的数据进行了处理

PointManager.ValidationResult validationResult = this.a(session, request, out pointManagerWrapper, out pointHint);

只要validationResult的值不为Invalid和Unknown,则不会进行处理request数据,否则处理完成后进行返回:

img

继续往下看,这里调用了IsRequestAllowed()函数,这个函数是属于ISecurityManager接口的,跟进看一下处理:

img

在IsRequestAllowed()函数中,也对相关标签值进行了判断,这里判断了cat标签值是否为4以及InParams的值是否为SubscribeProcedureInParams;接着判断了Session信息是否失效,后面判断了PointName的值是否为“cfg:”开头的,如果是则进入tj.a()函数里,跟进tj.a()函数:

img

函数根据cat标签的值进行处理,如果我们提交了cat的值为4且InParams的值为SubscribeProcedureInParams的话,就会进入case 4分支处理,再次跟进tj.a()重载处理函数看看:

img

这里首先进行了一次判断,使用的是RepositoryIdentifier类,跟进RepositoryIdentifier.TryParse()函数:

img

这里把用户提交过来的PointName数据用”|”进行分割,加到list变量里面:

img

在处理完数据后,判断了数据的格式是否正常,这里主要判断了数据的长度,Guid.值,“rpt:“, “ctx:” ,“tag:”,随后处理了”tag:”标签,可以看到这里将”tag:”标签Base64解密后进行了反序列化的操作,跟进Deserialize()函数:

img

反序列化调用了DataContractSerializer进行序列化操作:

img

分析上图代码,可知代码里面存在一个坑:代码对用户提交过来序列化的数据进行自定义处理,固不能直接生成POC,须预先做一个处理才能被利用。进入Deserialize()函数后,函数首先获取序列化数据的前4个字节,然后以前4个字节作为长度读取序列化数据,所以我们须在前面加上长度,否则无法反序列化成功,因为在前面的GetType获取中就读取错了数据。

我们可以看到在DataContractSerializer()函数中,GetType的参数是可以控制的,分析一下对type的处理过程:首先使用工具生成一个测试poc,然后带入函数进行处理:

img

看到函数已经对数据进行了处理,处理完数据之后我们发现,取出的变量值并不完整

img

接下来带入系统进行查找类型:

img

最后返回的type结果为null,也就是没有找到所属的类型,自然就会反序列化失败:

img

这里的序列化类型的清单均置于list清单里,System.Security.Principal.WindowsPrincipal是在list里面的,但却没有找到,就是因为数据存在格式问题:

img

根据按照序列化处理代码对POC进行删减构造,即可成功获取type:

img

0x03 POC构造

根据上节的漏洞分析,我们可以构造出漏洞利用POC,并使用DataContractSerializer()作为反序列化的载体进行利用测试:

通过抓包可以看到请求的数据,在数据包中可以看到,标签cat为4,type为0,但是Inparams还不是SubscribeProcedureInParams,借用抓到的数据包构造POC,删除数据包中一些不必要的数据并添加一些能够让漏洞触发的数据:

img

数据包构造完成后,使用工具生成POC,此处使用ysoserial.NET,把漏洞利用POC修改后添加到数据包里面即可成功利用:

img

0x04 总结

这个GENESIS64 .NET的反序列化漏洞的分析过程比较曲折,一方面没有太多的资料可供参考,加之软件程序十分庞大,系统开启服务太多,漏洞分析过程中发现的坑点也很多,导致漏洞定位难度增大,但总的来说,整个漏洞的利用过程还是很有意思,个人收获很大。

本文为互联网自动采集或经作者授权后发布,本文观点不代表立场,若侵权下架请联系我们删帖处理!文章出自:https://blog.csdn.net/kali_Ma/article/details/122382548
-- 展开阅读全文 --
KillDefender 的 Beacon 对象文件 PoC 实现
« 上一篇 02-09
Web安全—逻辑越权漏洞(BAC)
下一篇 » 03-13

发表评论

成为第一个评论的人

热门文章

标签TAG

最近回复