0x00 概述

GENESIS64軟件的多個(gè)版本存在反序列化漏洞，影響多個(gè)組件，例如：

根據(jù)CVE漏洞相關(guān)描述，下載對(duì)應(yīng)GENESIS軟件版本搭建環(huán)境，進(jìn)行漏洞分析與復(fù)現(xiàn)工作。

0x01 服務(wù)分析

安裝完成后對(duì)整個(gè)系統(tǒng)進(jìn)行熟悉，發(fā)現(xiàn)Web程序接口使用Silverlight進(jìn)行數(shù)據(jù)交互，因此需要找到相關(guān)功能文件進(jìn)行分析。經(jīng)過(guò)一些時(shí)間查找，找到系統(tǒng)服務(wù)開(kāi)啟的配置文件，在配置文件中定義了訪問(wèn)接口信息以及調(diào)用的相關(guān)配置文件信息：

經(jīng)過(guò)多方分析找到FwxServer類，類中定義了重要服務(wù)的啟動(dòng)與注冊(cè)配置，跟進(jìn)一下StartAsyncServer()進(jìn)行查看：

StartAsyncServer()函數(shù)里對(duì)配置項(xiàng)進(jìn)行處理，加載配置項(xiàng)里的配置，在后面有一個(gè)FwxServerBase()函數(shù)處理了很多的參數(shù)，繼續(xù)跟進(jìn)：

FwxServerBase()函數(shù)里只是對(duì)配置文件里的配置做了一些設(shè)置，但此處發(fā)現(xiàn)繼承了AsyncServer,再次跟進(jìn)AsyncServer：

AsyncServer()函數(shù)最后完成配置相關(guān)參數(shù)并進(jìn)行啟動(dòng)。到這里就完成整個(gè)服務(wù)的創(chuàng)建與啟動(dòng)，當(dāng)然這里只看了一個(gè)啟動(dòng)項(xiàng)目，其他的服務(wù)注冊(cè)與啟動(dòng)都差不多：

0x02 漏洞分析

基于前期的服務(wù)啟動(dòng)流程以及配置項(xiàng)的分析，最后定位到Asyncserver里處理提交請(qǐng)求的接口中，此接口中定義了幾個(gè)接口，均為提交請(qǐng)求的處理，于是就用這個(gè)作為分析的突破口。

下圖中定義了一個(gè)服務(wù)契約，在服務(wù)契約里面有多個(gè)處理提交請(qǐng)求的操作契約：

我們來(lái)對(duì)相關(guān)參數(shù)做一個(gè)簡(jiǎn)單的分析，因?yàn)檫@里只有PutRequests是處理提交請(qǐng)求的，所以先來(lái)看看它。這里是判斷提交過(guò)來(lái)的數(shù)據(jù)里的Session是否失效，失效返回false，如果Session未失效則進(jìn)入第二層處理Request：

在下圖可以看到Request()函數(shù)對(duì)我們提交過(guò)來(lái)的數(shù)據(jù)進(jìn)行了處理：

主要的SOAP數(shù)據(jù)包標(biāo)簽頭：

標(biāo)簽里的cat標(biāo)簽對(duì)應(yīng)了下面的幾種提交類型,幾種類型對(duì)應(yīng)了相關(guān)的處理方式：

其他的標(biāo)簽處理大同小異。來(lái)到PutRequest()函數(shù)，此函數(shù)里有一個(gè)a函數(shù)處理session，跟進(jìn)分析一下：

a()函數(shù)里，判斷了標(biāo)簽Actor和用戶提交的數(shù)據(jù)A_1，跟進(jìn)a(A_1)重載函數(shù)：

可以看到a(A_1)重載函數(shù)里只是一個(gè)值選項(xiàng)判斷，再次回到之前，跟進(jìn)a(A_0)重載函數(shù)：

a(A_0)重載函數(shù)處理了Session相關(guān)數(shù)據(jù)，也沒(méi)什么可分析的，接著往下看：

接下來(lái)看到存在一個(gè)if判斷，對(duì)標(biāo)簽PointName和PointHandle做了值判斷，因?yàn)橐话闱闆r下都會(huì)有值，因此這個(gè)地方流程一般不會(huì)進(jìn)入，進(jìn)入else分支分析：

在else分支里面進(jìn)行了一系列的標(biāo)簽值判斷，下面代碼對(duì)提交的數(shù)據(jù)進(jìn)行了處理

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

只要validationResult的值不為Invalid和Unknown，則不會(huì)進(jìn)行處理request數(shù)據(jù)，否則處理完成后進(jìn)行返回：

繼續(xù)往下看，這里調(diào)用了IsRequestAllowed()函數(shù)，這個(gè)函數(shù)是屬于ISecurityManager接口的，跟進(jìn)看一下處理：

在IsRequestAllowed()函數(shù)中，也對(duì)相關(guān)標(biāo)簽值進(jìn)行了判斷，這里判斷了cat標(biāo)簽值是否為4以及InParams的值是否為SubscribeProcedureInParams；接著判斷了Session信息是否失效，后面判斷了PointName的值是否為“cfg:”開(kāi)頭的，如果是則進(jìn)入tj.a()函數(shù)里，跟進(jìn)tj.a()函數(shù)：

函數(shù)根據(jù)cat標(biāo)簽的值進(jìn)行處理，如果我們提交了cat的值為4且InParams的值為SubscribeProcedureInParams的話，就會(huì)進(jìn)入case 4分支處理，再次跟進(jìn)tj.a()重載處理函數(shù)看看：

這里首先進(jìn)行了一次判斷，使用的是RepositoryIdentifier類，跟進(jìn)RepositoryIdentifier.TryParse()函數(shù):

這里把用戶提交過(guò)來(lái)的PointName數(shù)據(jù)用”|”進(jìn)行分割，加到list變量里面：

在處理完數(shù)據(jù)后，判斷了數(shù)據(jù)的格式是否正常，這里主要判斷了數(shù)據(jù)的長(zhǎng)度，Guid.值，“rpt:“， “ctx:” ，“tag:”，隨后處理了”tag:”標(biāo)簽，可以看到這里將”tag:”標(biāo)簽Base64解密后進(jìn)行了反序列化的操作，跟進(jìn)Deserialize()函數(shù)：

反序列化調(diào)用了DataContractSerializer進(jìn)行序列化操作：

分析上圖代碼，可知代碼里面存在一個(gè)坑：代碼對(duì)用戶提交過(guò)來(lái)序列化的數(shù)據(jù)進(jìn)行自定義處理，固不能直接生成POC，須預(yù)先做一個(gè)處理才能被利用。進(jìn)入Deserialize()函數(shù)后，函數(shù)首先獲取序列化數(shù)據(jù)的前4個(gè)字節(jié)，然后以前4個(gè)字節(jié)作為長(zhǎng)度讀取序列化數(shù)據(jù)，所以我們須在前面加上長(zhǎng)度，否則無(wú)法反序列化成功，因?yàn)樵谇懊娴腉etType獲取中就讀取錯(cuò)了數(shù)據(jù)。

我們可以看到在DataContractSerializer()函數(shù)中，GetType的參數(shù)是可以控制的,分析一下對(duì)type的處理過(guò)程：首先使用工具生成一個(gè)測(cè)試poc，然后帶入函數(shù)進(jìn)行處理：

看到函數(shù)已經(jīng)對(duì)數(shù)據(jù)進(jìn)行了處理，處理完數(shù)據(jù)之后我們發(fā)現(xiàn)，取出的變量值并不完整

接下來(lái)帶入系統(tǒng)進(jìn)行查找類型：

最后返回的type結(jié)果為null，也就是沒(méi)有找到所屬的類型，自然就會(huì)反序列化失?。?/p>

這里的序列化類型的清單均置于list清單里，System.Security.Principal.WindowsPrincipal是在list里面的，但卻沒(méi)有找到，就是因?yàn)閿?shù)據(jù)存在格式問(wèn)題：

根據(jù)按照序列化處理代碼對(duì)POC進(jìn)行刪減構(gòu)造，即可成功獲取type：

0x03 POC構(gòu)造

根據(jù)上節(jié)的漏洞分析，我們可以構(gòu)造出漏洞利用POC，并使用DataContractSerializer()作為反序列化的載體進(jìn)行利用測(cè)試：

通過(guò)抓包可以看到請(qǐng)求的數(shù)據(jù)，在數(shù)據(jù)包中可以看到，標(biāo)簽cat為4，type為0，但是Inparams還不是SubscribeProcedureInParams，借用抓到的數(shù)據(jù)包構(gòu)造POC，刪除數(shù)據(jù)包中一些不必要的數(shù)據(jù)并添加一些能夠讓漏洞觸發(fā)的數(shù)據(jù)：

數(shù)據(jù)包構(gòu)造完成后，使用工具生成POC，此處使用ysoserial.NET，把漏洞利用POC修改后添加到數(shù)據(jù)包里面即可成功利用：

0x04 總結(jié)

這個(gè)GENESIS64 .NET的反序列化漏洞的分析過(guò)程比較曲折，一方面沒(méi)有太多的資料可供參考，加之軟件程序十分龐大，系統(tǒng)開(kāi)啟服務(wù)太多，漏洞分析過(guò)程中發(fā)現(xiàn)的坑點(diǎn)也很多，導(dǎo)致漏洞定位難度增大，但總的來(lái)說(shuō)，整個(gè)漏洞的利用過(guò)程還是很有意思，個(gè)人收獲很大。

以上就是網(wǎng)絡(luò)安全滲透測(cè)試反序列化漏洞分析與復(fù)現(xiàn)工作的詳細(xì)內(nèi)容，更多關(guān)于網(wǎng)絡(luò)安全滲透測(cè)試反序列化漏洞分析與復(fù)現(xiàn)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論