您好,登錄后才能下訂單哦!
這篇文章主要介紹了網(wǎng)絡安全滲透測試反序列化漏洞分析與復現(xiàn)的方法的相關知識,內(nèi)容詳細易懂,操作簡單快捷,具有一定借鑒價值,相信大家閱讀完這篇網(wǎng)絡安全滲透測試反序列化漏洞分析與復現(xiàn)的方法文章都會有所收獲,下面我們一起來看看吧。
GENESIS64軟件的多個版本存在反序列化漏洞,影響多個組件,例如:
根據(jù)CVE漏洞相關描述,下載對應GENESIS軟件版本搭建環(huán)境,進行漏洞分析與復現(xiàn)工作。
安裝完成后對整個系統(tǒng)進行熟悉,發(fā)現(xiàn)Web程序接口使用Silverlight進行數(shù)據(jù)交互,因此需要找到相關功能文件進行分析。經(jīng)過一些時間查找,找到系統(tǒng)服務開啟的配置文件,在配置文件中定義了訪問接口信息以及調(diào)用的相關配置文件信息:
經(jīng)過多方分析找到FwxServer類,類中定義了重要服務的啟動與注冊配置,跟進一下StartAsyncServer()進行查看:
StartAsyncServer()函數(shù)里對配置項進行處理,加載配置項里的配置,在后面有一個FwxServerBase()函數(shù)處理了很多的參數(shù),繼續(xù)跟進:
FwxServerBase()函數(shù)里只是對配置文件里的配置做了一些設置,但此處發(fā)現(xiàn)繼承了AsyncServer,再次跟進AsyncServer:
AsyncServer()函數(shù)最后完成配置相關參數(shù)并進行啟動。到這里就完成整個服務的創(chuàng)建與啟動,當然這里只看了一個啟動項目,其他的服務注冊與啟動都差不多:
基于前期的服務啟動流程以及配置項的分析,最后定位到Asyncserver里處理提交請求的接口中,此接口中定義了幾個接口,均為提交請求的處理,于是就用這個作為分析的突破口。
下圖中定義了一個服務契約,在服務契約里面有多個處理提交請求的操作契約:
我們來對相關參數(shù)做一個簡單的分析,因為這里只有PutRequests是處理提交請求的,所以先來看看它。這里是判斷提交過來的數(shù)據(jù)里的Session是否失效,失效返回false,如果Session未失效則進入第二層處理Request:
在下圖可以看到Request()函數(shù)對我們提交過來的數(shù)據(jù)進行了處理:
主要的SOAP數(shù)據(jù)包標簽頭:
標簽里的cat標簽對應了下面的幾種提交類型,幾種類型對應了相關的處理方式:
其他的標簽處理大同小異。來到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相關數(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ù)中,也對相關標簽值進行了判斷,這里判斷了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,須預先做一個處理才能被利用。進入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,也就是沒有找到所屬的類型,自然就會反序列化失?。?/p>
這里的序列化類型的清單均置于list清單里,System.Security.Principal.WindowsPrincipal是在list里面的,但卻沒有找到,就是因為數(shù)據(jù)存在格式問題:
根據(jù)按照序列化處理代碼對POC進行刪減構(gòu)造,即可成功獲取type:
根據(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ù)包里面即可成功利用:
關于“網(wǎng)絡安全滲透測試反序列化漏洞分析與復現(xiàn)的方法”這篇文章的內(nèi)容就介紹到這里,感謝各位的閱讀!相信大家對“網(wǎng)絡安全滲透測試反序列化漏洞分析與復現(xiàn)的方法”知識都有一定的了解,大家如果還想學習更多知識,歡迎關注億速云行業(yè)資訊頻道。
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。