0x00 概述

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

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

0x01 服務(wù)分析

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

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

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

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

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

0x02 漏洞分析

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

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

我們來對相關(guān)參數(shù)做一個簡單的分析，因為這里只有PutRequests是處理提交請求的，所以先來看看它。這里是判斷提交過來的數(shù)據(jù)里的Session是否失效，失效返回false，如果Session未失效則進入第二層處理Request：

在下圖可以看到Request()函數(shù)對我們提交過來的數(shù)據(jù)進行了處理：

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

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

其他的標簽處理大同小異。來到PutRequest()函數(shù)，此函數(shù)里有一個a函數(shù)處理session，跟進分析一下：

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

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

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

接下來看到存在一個if判斷，對標簽PointName和PointHandle做了值判斷，因為一般情況下都會有值，因此這個地方流程一般不會進入，進入else分支分析：

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

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

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

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

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

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

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

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

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

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

分析上圖代碼，可知代碼里面存在一個坑：代碼對用戶提交過來序列化的數(shù)據(jù)進行自定義處理，固不能直接生成POC，須預(yù)先做一個處理才能被利用。進入Deserialize()函數(shù)后，函數(shù)首先獲取序列化數(shù)據(jù)的前4個字節(jié)，然后以前4個字節(jié)作為長度讀取序列化數(shù)據(jù)，所以我們須在前面加上長度，否則無法反序列化成功，因為在前面的GetType獲取中就讀取錯了數(shù)據(jù)。

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

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

接下來帶入系統(tǒng)進行查找類型：

最后返回的type結(jié)果為null，也就是沒有找到所屬的類型，自然就會反序列化失敗：

這里的序列化類型的清單均置于list清單里，System.Security.Principal.WindowsPrincipal是在list里面的，但卻沒有找到，就是因為數(shù)據(jù)存在格式問題：

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

0x03 POC構(gòu)造

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

通過抓包可以看到請求的數(shù)據(jù)，在數(shù)據(jù)包中可以看到，標簽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é)

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

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

最新評論