網絡安全滲透測試反序列化漏洞分析與復現的方法

這篇文章主要介紹了網絡安全滲透測試反序列化漏洞分析與復現的方法的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇網絡安全滲透測試反序列化漏洞分析與復現的方法文章都會有所收獲，下面我們一起來看看吧。

0x00 概述

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

根據CVE漏洞相關描述，下載對應GENESIS軟件版本搭建環境，進行漏洞分析與復現工作。

0x01 服務分析

安裝完成后對整個系統進行熟悉，發現Web程序接口使用Silverlight進行數據交互，因此需要找到相關功能文件進行分析。經過一些時間查找，找到系統服務開啟的配置文件，在配置文件中定義了訪問接口信息以及調用的相關配置文件信息：

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

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

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

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

0x02 漏洞分析

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

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

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

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

主要的SOAP數據包標簽頭：

標簽里的cat標簽對應了下面的幾種提交類型,幾種類型對應了相關的處理方式：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

反序列化調用了DataContractSerializer進行序列化操作：

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

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

看到函數已經對數據進行了處理，處理完數據之后我們發現，取出的變量值并不完整

接下來帶入系統進行查找類型：

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

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

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

0x03 POC構造

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

通過抓包可以看到請求的數據，在數據包中可以看到，標簽cat為4，type為0，但是Inparams還不是SubscribeProcedureInParams，借用抓到的數據包構造POC，刪除數據包中一些不必要的數據并添加一些能夠讓漏洞觸發的數據：

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

關于“網絡安全滲透測試反序列化漏洞分析與復現的方法”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“網絡安全滲透測試反序列化漏洞分析與復現的方法”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業資訊頻道。