翟繼強 王家乾 韓旭 孫海旭

摘 要：目前有關(guān)堆的取證研究主要是針對Windows系統(tǒng)的堆和NT堆，然而怎樣從轉(zhuǎn)儲文件中提取出Linux系統(tǒng)Glibc堆信息并沒有得到充分的研究。為了重現(xiàn)Linux系統(tǒng)中Glibc堆的內(nèi)部信息，采用內(nèi)存對象vtype描述信息中字段偏移定位結(jié)合在內(nèi)存中Glibc堆實現(xiàn)的方法提取Glibc堆內(nèi)部信息。并基于此方法研發(fā)了基于Rekall框架的3個堆信息提取插件。還研究了house of spirit類型的堆攻擊，建立了攻擊模型并提取其攻擊特征?；谔崛〉墓籼卣髟O(shè)計出針對house of spirit攻擊的檢測算法。在堆信息提取插件的基礎(chǔ)上研發(fā)了攻擊檢測插件。實驗結(jié)果表明本方法可以有效地提取Linux系統(tǒng)進程中堆在內(nèi)存中的信息，并且基于這些信息結(jié)合攻擊檢測算法成功檢測內(nèi)存中的house of spirit類型攻擊。

關(guān)鍵詞：Glibc堆；信息提取；堆攻擊檢測；Rekall框架

DOI：10.15938/j.jhust.2024.01.011

中圖分類號： TP319? 文獻標志碼： A

文章編號： 1007-2683（2024）01-0096-11

Detecting House of Spirit Attacks by Glibc Heap Information Extraction

ZHAI Jiqiang， WANG Jiaqian， HAN Xu， SUN Haixu

（School of Computer Science and Technology， Harbin University of Science and Technology， Harbin 150080， China）

Abstract：The current forensic research on heaps mainly extracts information from the heap and the NT heap of Windows However， the study of how to extract the information on the Glibc heap in the Linux from dump files is not sufficient To reproduce the internal information on the Glibc heap， this paper proposes a method to extract the internal information of Glibc heap in the Linux according to the field offset in the vtype description information of memory object combined with Glibc heap implementation in memoryBased on this method， three heap information extraction plugins were developed on the Rekall frameworkIn addition， the House of Spirit heap attack is studied， established an attack model， and extracted its attack featuresA detection algorithm for House of Spirit attack is designed based on the extracted attack features The attack detection plug-in is developed based on the heap information extraction pluginsThe experimental results show that this method can effectively extract the heap information in the memory of the Linux system process， and successfully detect the House of Spirit attack in the memory based on the information combined with the attack detection algorithm

Keywords：Glibc heap; information extraction; heap attack detection; Rekall framework

基金項目： 國家自然科學(xué)基金（61403109）；國家自然科學(xué)基金（61402126）；國家自然科學(xué)基金（61602133）.

0 引 言

近年來，黑客經(jīng)常通過網(wǎng)絡(luò)傳播惡意程序，當(dāng)計算機染上惡意程序時，內(nèi)存會留下痕跡，通過內(nèi)存取證技術(shù)就可以捕獲到這些痕跡［1］。堆中含有進程運行時的重要信息，提取出堆中的信息可以了解進程的運行情況［2］，因此對堆的內(nèi)存取證研究在信息安全的防護領(lǐng)域意義重大。

到目前為止，對用戶空間進程堆的分析還沒有得到足夠的重視”［3］。Urrea、Case et al和Light et al主要研究涉及內(nèi)核相關(guān)的工作［4-5］。Leppert和Macht研究的是分析應(yīng)用程序和它們的堆數(shù)據(jù)［6-7］。然而他們的分析主要集中在堆中包含的序列化Java對象上，而不是堆對象的管理方式。其他已經(jīng)存在的插件諸如cmdscan和bash［8］，它們分別從Windows的cmd和Linux的bash shell提取命令歷史。然而，這些插件的工作原理只是將堆作為一個大的內(nèi)聚內(nèi)存區(qū)域來識別其中可能存在的信息［9］。

此外，由Light等［10］進行的記事本程序的堆分析是唯一1個使用了堆細節(jié)的研究，但它也僅僅與Windows系統(tǒng)有關(guān)。在內(nèi)存取證范圍之外，也存在關(guān)于堆的基礎(chǔ)研究［11］，特別是關(guān)于Linux進程的堆以及如何管理堆的研究。Ferguson的研究有助于深入理解Glibc的堆實現(xiàn)［12］。然而這項研究更多地集中在利用堆的方式上，因此沒有提供足夠的信息來可靠地收集內(nèi)存取證場景中堆的所有相關(guān)信息。

為了彌補這些缺陷，本文研究了多個版本的基于Glibc堆實現(xiàn)的Linux系統(tǒng)，并且基于內(nèi)存中Glibc堆實現(xiàn)，結(jié)合字段信息偏移定位的方法，提取堆內(nèi)部信息。經(jīng)過測試，該方法能成功提取堆內(nèi)部信息，并且基于這些信息成功設(shè)計出檢測house of spirit堆溢出攻擊的插件。本文研究的主要內(nèi)容如下：

1）研究了多個Linux版本的Glibc堆實現(xiàn)及其在內(nèi)存中的結(jié)構(gòu)及字段的作用；

2）根據(jù)內(nèi)存中Glibc堆實現(xiàn)，結(jié)合內(nèi)存對象vtype描述信息中字段偏移定位實現(xiàn)提取Glibc堆內(nèi)部信息的方法；

3）分析了house of spirit類型的堆攻擊，建立其攻擊模型并提取其攻擊特征；

4）基于提取的攻擊特性設(shè)計出針對house of spirit攻擊的檢測算法。在堆信息提取插件的基礎(chǔ)上研發(fā)了攻擊檢測插件；

5）使用本文研發(fā)出的插件檢測house of spirit攻擊。

1 Glibc堆信息提取

1.1 內(nèi)存中的Glibc堆實現(xiàn)分析

圖1顯示了正在運行進程的堆布局，重點是各個元素之間的引用。Chunk包含實際的用戶/進程數(shù)據(jù)。通過malloc調(diào)用顯式分配，這些塊位于特定的內(nèi)存區(qū)域中。

1.1.1 內(nèi)存中的Arena和heap_info結(jié)構(gòu)

主堆是一個連續(xù)的內(nèi)存區(qū)域，被分割到vm_area_struct結(jié)構(gòu)體描述的多個連續(xù)內(nèi)存區(qū)域中。用于描述Main Arena的malloc_state數(shù)據(jù)結(jié)構(gòu)存儲于映射在內(nèi)存中的Libc庫中，在Main Arena中沒有heap_info結(jié)構(gòu)實例。

線程 Arena的malloc_state數(shù)據(jù)結(jié)構(gòu)與堆塊一起存儲在同一內(nèi)存區(qū)域中。在屬于線程Arena的每個映射內(nèi)存區(qū)域的開始處都存在1個heap_info結(jié)構(gòu)的實例。除此之外，在此之后的heap_info結(jié)構(gòu)最終都位于同一映射內(nèi)存區(qū)域中。

如圖2所示，灰色區(qū)域是vm_area_struct數(shù)據(jù)結(jié)構(gòu)所描述的內(nèi)存區(qū)域，藍色標記的結(jié)構(gòu)和塊屬于同一Arena，綠色標記的結(jié)構(gòu)和塊屬于另一Arena。size成員存儲的指針標記相對應(yīng)heap_info結(jié)構(gòu)所描述的內(nèi)存區(qū)域的大小，ar_ptr成員指向其關(guān)聯(lián)的Arena，prev成員指向同一Arena中的上1個heap_info結(jié)構(gòu)。

1.1.2 內(nèi)存中的已分配堆塊

內(nèi)存中的已分配塊如圖3所示。用戶數(shù)據(jù)開始于size成員之后，一直到下1個區(qū)塊的size成員。size成員后面的malloc_chunk結(jié)構(gòu)的所有成員都會被用戶數(shù)據(jù)覆蓋。用戶數(shù)據(jù)覆蓋范圍如圖藍色字段。

如果上一堆塊為已釋放堆塊prev_size字段包含前一個區(qū)塊的大小。否則prev_size成員為上1個已分配堆塊用戶數(shù)據(jù)的一部分。

1.1.3 內(nèi)存中的已釋放塊和bins

初始態(tài)時，所有bins和fastbins都是空的。對于fastbins，它們的指針都初始化為零，而bins有1個指向它們自己的指針。每個bin都包含1個正向和反向鏈接。

圖4顯示了bins 正好包含1個塊的情況?？梢钥吹?，實際釋放的塊引用Arena中的虛擬塊，該塊的fd和bk指針與bin 的指針相匹配。

圖5為帶有多個塊的bins。bin的bk指針指向該bin的最后1個塊，fd指針指向第1個塊。第1個塊的bk指針和最后1個塊的fd指針都引用Arena中的虛擬區(qū)塊，實現(xiàn)了1個循環(huán)雙鏈表。

1.1.4 內(nèi)存中的MMAPPED塊

MMAPPED塊通常位于vm_area_struct數(shù)據(jù)結(jié)構(gòu)描述的專用內(nèi)存區(qū)域中。沒有來自malloc_state或heap_info等結(jié)構(gòu)的指針引用內(nèi)存區(qū)域或塊本身。其大小為頁面大小的倍數(shù)。此外，由于內(nèi)核可以放大一個區(qū)域，多個MMAPPED塊最終可能位于1個vm_area_struct數(shù)據(jù)結(jié)構(gòu)描述的同一內(nèi)存區(qū)域中。如果1個位于同一區(qū)域的兩個或多個MMAPPED塊之間的MMAPPED塊被釋放，則連續(xù)內(nèi)存區(qū)域?qū)⒈徊鸱譃閮蓚€單獨的區(qū)域。

1.2 基于Glibc堆實現(xiàn)的堆信息提取方法

本節(jié)根據(jù)內(nèi)存對象vtype描述信息中字段偏移定位結(jié)合在內(nèi)存中Glibc的堆實現(xiàn)提出了一種提取Glibc堆內(nèi)部信息的方法。

1.2.1 堆初始化信息提取方法

當(dāng)識別出取證文件為Linux系統(tǒng)的轉(zhuǎn)儲文件時，使用內(nèi)存取證框架內(nèi)置的掃描技術(shù)掃描內(nèi)核空間并定位到task結(jié)構(gòu)體，通過task結(jié)構(gòu)體遍歷VMA結(jié)構(gòu)，獲取Glibc庫在內(nèi)存中的位置，提取Glibc庫中Main Arena的位置。根據(jù)內(nèi)存對象vtype描述信息中字段偏移定位Glibc堆的相關(guān)數(shù)據(jù)結(jié)構(gòu)并提取堆的信息。堆初始化信息提取方法的流程圖如圖6所示。

該方法可以重現(xiàn)進程運行時，堆的內(nèi)部信息。該方法首先收集內(nèi)存中所有的Arena，及其第1個堆塊信息以及MMAP塊的第1個堆塊信息。通過收集到的初始信息，進一步收集內(nèi)存中已分配及釋放的堆塊信息，通過bins列表收集bins表信息，從而實現(xiàn)對于堆的初始化信息提取。

1.2.2 堆塊信息提取方法

當(dāng)使用Glibc分配器分配堆塊時，其堆塊起始地址add加上size成員的值即下1個堆塊的地址next_add，堆塊size位的標志位PREV_INUSE指示前1個堆塊是否為已釋放堆塊。該方法基于堆初始化信息提取方法所收集到的信息，遍歷堆空間，基于malloc_chunk數(shù)據(jù)結(jié)構(gòu)追蹤程序已分配/釋放堆塊信息。提取的信息有已分配/釋放堆塊的數(shù)量、及堆塊內(nèi)部信息等。該方法執(zhí)行的步驟如下：

步驟1：基于堆初始化信息提取方法所收集到的信息，定位Main Arenafirst_chunk位置；

步驟2：提取first_chunk地址，通過其地址及malloc_chunk數(shù)據(jù)結(jié)構(gòu)追蹤next_chunk；

步驟3：獲取next_chunk相關(guān)數(shù)據(jù)結(jié)構(gòu)的size位，識別標志位PREV_INUSE。判定前一堆塊為分配對堆塊還是釋放堆塊，保存在相應(yīng)堆塊列表中，指針保存在相應(yīng)指針列表中。

步驟4：基于對初始化信息提取方法所收集到的信息，遍歷Thread Arena列表，定位線程heap_info結(jié)構(gòu)體位置，獲取線程malloc_state，緊接著定位到Thread Arenafirstchunk，獲取其地址。

步驟5：重復(fù)步驟2和步驟3。

步驟6：統(tǒng)計已分配/釋放堆塊的數(shù)量。

2 house of spirit攻擊檢測

2.1 house of spirit攻擊原理及特征

堆分配器具有廣泛的攻擊面。一系列攻擊的重點是利用分配器算法本身［13］，例如特定的fastbin或smallbin實現(xiàn)。攻擊者的目標是建立任意指針或任意代碼執(zhí)行［14］。任意指針尤其危險，因為它們可以用來操縱目標程序的控制流［15］。house of spirit攻擊便屬于此類攻擊。

house of spirit攻擊原理：①修改1個將被釋放的堆指針，使其指向包含全局指針m_ptr的可控內(nèi)存地址。②在可控內(nèi)存區(qū)域中構(gòu)建1個偽堆結(jié)構(gòu)，繞過Glibc的檢測機制?？煽貎?nèi)存可以作為堆塊釋放到堆塊的鏈表中。③在鏈表中的可控內(nèi)存再次被應(yīng)用后，可以實現(xiàn)m_ptr指針數(shù)據(jù)的可控性，并且可以寫入任意地址。以實現(xiàn)任意地址可控。圖7為house of spirit攻擊過程的示意圖。

因此，當(dāng)程序中存在1個將要釋放的可控堆指針時，意味著該程序滿足house of spirit攻擊的第1個攻擊特征。

其次如果全局指針m_ptr附近存儲空間為可控區(qū)域，并且在可控內(nèi)存空間中存在偽造堆塊。意味著該程序滿足house of spirit攻擊的第2個攻擊特征。

最后釋放受控內(nèi)存區(qū)域，并將其再次分配為堆塊?；诙训奶匦?，m_ptr變?yōu)榭煽財?shù)據(jù)，意味著滿足house of spirit攻擊的第3個攻擊特征。此時攻擊者可以通過修改全局指針數(shù)據(jù)的值來實現(xiàn)任意地址寫入的目的。

2.2 house of spirit攻擊分析及特征提取

為了實現(xiàn)對house of spirit攻擊的自動檢測，需要監(jiān)控house of spirit攻擊劫持控制流的過程，并在程序運行過程中收集程序控制流信息和堆塊的操作信息。

為了消除保護機制對檢測過程的影響，根據(jù)house of spirit的攻擊過程設(shè)計了相應(yīng)的數(shù)據(jù)體現(xiàn)過程，并建立了house of spirit攻擊的攻擊模型，如圖8所示。

如果堆指針P是可控堆指針，則表示該程序滿足house of spirit攻擊的第1攻擊特征。如果m_ptr指針附近的存儲區(qū)域為可控的，并且在可控內(nèi)存空間中存在構(gòu)建的偽造堆塊結(jié)構(gòu)。則表示該程序滿足house of spirit攻擊的第2攻擊特征。釋放指針P，將包含m_ptr的可控內(nèi)存空間作為堆塊釋放到堆鏈表中，然后再申請，將數(shù)據(jù)寫入新創(chuàng)建的堆塊中，修改m_ptr的值，實現(xiàn)任意地址寫入，則表示該程序滿足house of spirit攻擊的第3攻擊特征。最終實現(xiàn)控制流劫持。

2.3 house of spirit攻擊檢測算法

基于Glibc堆信息提取方法，動態(tài)追蹤內(nèi)存中程序用戶空間進程堆信息。結(jié)合house of spirit攻擊模型的3個攻擊特征，設(shè)計針對house of spirit攻擊的攻擊檢測模型，如圖9所示。

針對第1攻擊特性，本文設(shè)計了一種house of spirit第1攻擊特征檢測算法?；诙研畔⑻崛∷占降男畔?，獲取已分配堆塊列表Achunk和已釋放指針列表Fpointer。當(dāng)已釋放指針列表新增釋放指針FP時遍歷Achunk檢測其是否屬于之前的已分配堆塊，若其不屬于之前的已分配堆塊，則設(shè)置指針FP標志位Is_HouseOfSpirit為true。保存指針FP于特定列表。其所指向堆塊保存在特定堆塊列表中。

house of spirit第1攻擊特征檢測算法如算法1所示。

算法1 house of spirit第一攻擊特征檢測算法

輸入：已分配堆塊列表Achunk；

已釋放堆塊指針列表Fpointer；

將被釋放的堆指針FP；

輸出：house of spirit 第1攻擊特征檢測標志位

Is_HouseOfSpirit。foreach （ FP ）{?if （FP not in Achunk ）?{? FPchunk = Getchunk（FP）;? FPchunk -> Is_HouseOfSpirit = true;? AddIs_HouseOfSpiritChunkList（FPchunk）;? AddIs_HouseOfSpiritPointerList（FP）;?}?else?{? FPchunk = Getchunk（FP）;? AddFpointer（FP）;? DelAchunk（FPchunk）;? FPchunk->Is_HouseOfSpirit = false;?}

針對第2攻擊特性，本文設(shè)計了一種house of spirit第2攻擊特征檢測算法?；诙研畔⑻崛∷占降男畔?，定位malloc_state結(jié)構(gòu)體，獲取bin表信息。當(dāng)檢測到新增釋放指針P時，檢索HouseOfSpiritPointer指針列表，當(dāng)指針P屬于該列表時，獲取其所指向堆塊的相關(guān)數(shù)據(jù)結(jié)構(gòu)，識別該堆塊size位的值，確認其屬于哪個bin表，遍歷該bin表，若存在則設(shè)置標志位Is_FakeHeapBlock。

house of spirit第2攻擊特征檢測算法如算法2所示。

算法2 house of spirit第2攻擊特征檢測算法

輸入：Main Arena數(shù)據(jù)結(jié)構(gòu)體malloc_state；

第1攻擊特征指針列表HouseOfSpiritPointer；

新增釋放堆指針P；

輸出：house of spirit 第2攻擊特征檢測標志位

Is_FakeHeapBlock。

foreach （P）{?if（P in HouseOfSpiritPointer）?{? Pchunk = Getchunk（P）;? size = Getsize（Pchunk）;? bins = Getbins（malloc_statesize）;? if（Pchunk in bins）? {?? Pchunk->Is_FakeHeapBlock = true;? Fakechunk = Heapchunkdump（P，size）;? }? else? {?? Pchunk->Is_FakeHeapBlock = false;?Del（HouseOfSpiritPointer（），P） ;? Del（HouseOfSpiritChunk（），Pchunk）;?}?}}

針對第3攻擊特征，本文設(shè)計了一種house of spirit第3攻擊特征檢測算法。基于Is_HouseOfSpirit檢測組件及其Is_FakeHeapBlock檢測組件所提供信息，獲取疑似攻擊列表。當(dāng)檢測到新增分配指針P時，檢索HouseOfSpiritPointer指針列表，獲取其所指向的堆塊，追蹤新分配堆塊，在新分配堆塊內(nèi)查找變化指針，其指向控制流，即shellcode。

house of spirit第3攻擊特征檢測算法如算法3所示。

算法3 house of spirit第3攻擊特征檢測算法

輸入：第1攻擊特征指針列表HouseOfSpiritPointer；

新增分配堆指針AP；

輸出：house of spirit 第3攻擊特征檢測標志位

Is_PtrContorl。

foreach （AP）{?if（AP in HouseOfSpiritPointer）?{? if（AP->Is_HouseOfSpirit = true）? {? if（AP->Is_FakeHeapBlock = true）? {Allochunk = Getchunk（AP）;?if（Fakechunk ！= Allochunk）? AP->Is_PtrContorl = true;

基于上述3點，對house of spirit攻擊進行識別檢測。當(dāng)程序滿足上述3點，被認定為house of spirit攻擊。

即：House_HiJack=Is_HouseOfSpirit && Is_ FakeHeapBlock && Is_PtrContorl。

3 插件的設(shè)計與實現(xiàn)

3.1 內(nèi)存取證框架

本文研發(fā)的功能插件，都是基于內(nèi)存取證框架實現(xiàn)的［16］。內(nèi)存取證框架可以從轉(zhuǎn)儲文件和硬件磁盤鏡像中解析休眠文件與頁面文件信息，通過這兩個文件信息的對比能獲取隱藏進程的證據(jù)，而且還可以使用可執(zhí)行頁面檢測算法遍歷內(nèi)存頁并恢復(fù)可執(zhí)行頁面，幫助調(diào)查人員識別代碼注入等［17］。

Rekall框架是 Google 開發(fā)的內(nèi)存分析框架，是開源平臺，可以提供可視化的系統(tǒng)運行狀態(tài)，為相關(guān)的開發(fā)人員提供更多相關(guān)的數(shù)據(jù)和材料。

Rekall中含有各個Windows 10系統(tǒng)版本的配置文件，使用時不需要進行額外的制作［18］。然而Linux操作系統(tǒng)由于其內(nèi)核版本、子內(nèi)核版本和定制內(nèi)核的數(shù)量眾多，需要使用者自己進行制作［19］。配置文件里面組合了許多vtype 描述信息。在對內(nèi)存對象進行分析的時候，這些信息可以讓Rekall框架對轉(zhuǎn)儲文件中的數(shù)據(jù)進行解析。

3.2 Heapinit插件

Heapinit插件是基于內(nèi)存取證框架實現(xiàn)的，該插件提取所有的Arena，及其第1個堆塊信息以及MMAP塊的第1個堆塊信息。

Heapinit插件基于堆初始化信息提取方法實現(xiàn)，相關(guān)偽代碼如下所示：

if profile is Linux：

if taskmmdereference is vaild：? task<—Gettaskstruct? process_as<—Get_process_address_space（）? vmas = Get_vmas_for_task（task）?if vmas ：? Load_libc_profile（）? libc_offset = Get_libc_offset（vmas）?if libc_offset：?? Main_arena = libc_offset??? +libc_profilemain_arena_offset?? Initialize_arenas（Main_arena）?? Initialize_heap_first_chunks（）?? Initialize_mmapped_first_chunk（）?? check_and_report_size_inconsistencies（）

3.3 Heapchunkinfo插件

該插件輸出的信息有已分配/釋放堆塊的數(shù)量、及堆塊信息等，Heapchunkinfo插件基于堆塊信息提取方法實現(xiàn)，相關(guān)的偽代碼如下：

Heapinit<—GetHeapinit（）

while（Currentchunk.add< Topchunk.add）：

KNextchunk <—Currentchunk.add+Currentchunk.size

if（Nextchunk.PREV_INUSE）：

Add（MainAllocatedChunk（）， Currentchunk）

Add（MainAllocatedchunkPointer（），Currentchunk.add）

MainAllocatedChunkNum++

else：

Add（MainFreedChunk（）， Currentchunk）

Add（MainFreedChunkPointer（），Currentchunk.add）

MainFreedChunkNum++

for arena in Theard_Arena：

heapinfo<—arena.heapinfo

Currentchunk<—heapinfo.firstchunk

while（Currentchunk.add< Topchunk.add）：

Nextchunk <—Currentchunk.add+Currentchunk.size

if（Nextchunk.PREV_INUSE）：

Add（ThreadAllocatedChunk（）， Currentchunk）

Add（ThreadAllocedchunkP（），Currentchunk.add）

ThreadAllocatedChunkNum++

3.4 House_HiJack插件

House_HiJack插件用于檢測house of spirit攻擊。針對house of spirit攻擊模型總結(jié)出其三種攻擊特征。針對三種攻擊特征設(shè)計針對性的檢測組件。

3.4.1 Is_HouseOfSpirit組件

基于house of spirit第1攻擊特征檢測算法，實現(xiàn)Is_HouseOfSpirit檢測組件的相關(guān)偽代碼如下：

Heapinit<—GetHeapinit（）

Achunk<—MainAllocatedChunk（）

Fpointer <—MainFreedChunkPointer（）

FP<—GetAddMainFreedChunkPointer（）

if FP in Achunk：

Del（MainAllocatedChunk（）， Getchunk（FP））

Del（MainAllocatedChunkPointer（）， FP）

else：

FP.IS_HouseOfSpirit = true

Add（HouseOfSpiritPointer（），F(xiàn)P）

Add（HouseOfSpiritChunk（），Getchunk（FP））

3.4.2 Is_FakeHeapBlock組件

基于house of spirit第2攻擊特征檢測算法，實現(xiàn)Is_FakeHeapBlock檢測組件的偽代碼如下：

Heapinit<—GetHeapinit（）

main_arena<—Heapinit.main_arena

bins<—GetBins（）

P<—GetAddMainFreedChunkPointer（）

if P in HouseOfSpiritPointer：

Pchunk<—Getchunk（P）

size<—Pchunk.size

if Pchunk in Bins（size）：

P.Is_FakeHeapBlock = true

else：

Del（HouseOfSpiritPointer（），P）

Del（HouseOfSpiritChunk（），Pchunk）

3.4.3 Is_PtrContorl組件

基于house of spirit第3攻擊特征檢測算法，實現(xiàn)Is_PtrContorl檢測組件的偽代碼如下：

Heapinit<—GetHeapinit（）

P<—GetAddMainAllocatedChunkPointer（）

PA<—GetMainAllocatedChunkPointer（）

if P in HouseOfSpiritPointer&& P.Is_FakeHeapBlock：

Pchunk<—GetHouseOfSpiritChunk（P）

Heapchunkdump（Pchunk）

PAchunk<—GetChunk（PA）

Heapchunkdump（PAchunk）

if Pchunk ！= PAchunk：

P.Is_PtrContorl=true

shellcode<—GetPointer（PAchunk）

else：

Del（HouseOfSpiritPointer（），P）

Del（HouseOfSpiritChunk（），Pchunk）

4 測試與分析

測試分為堆信息提取測試和house of spirit攻擊檢測測試兩部分，堆信息提取測試是為了驗證插件能否在內(nèi)存空間中有效提取堆的相關(guān)信息，house of spirit攻擊檢測測試是為了驗證插件是否能有效檢測出house of spirit攻擊。實驗環(huán)境如下：

主機操作系統(tǒng)為Linux內(nèi)核版本4.9.5-5.7.17 64位，CPU為220GHz，內(nèi)存大小8G，硬盤容量2T。

4.1 堆信息提取測試

選取init進程和gnome-keyring-d進程作為實驗對象，在495版本、5312版本、5717內(nèi)核版本的Linux系統(tǒng)中運行g(shù)nome-keyring-d程序，隨后分別對系統(tǒng)內(nèi)存進行轉(zhuǎn)儲生成轉(zhuǎn)儲文件，使用本文研發(fā)好的3個堆信息提取插件分別提取init進程和gnome-keyring-d進程中的堆信息。

以init進程pid=1為例，圖10顯示了Heapinit插件的運行來獲取Main Arena的位置及其定位的主堆第一個堆塊位置及信息。

同樣以init進程pid=1為例，圖11顯示了Heapchunkinfo插件獲取的進程的部分已分配堆塊的位置信息。

表1顯示了對于不同進程，Heapchunkinfo插件運行后收集到的堆塊相關(guān)信息。

從表1中可以看到該插件可以有效地提取出不同版本Linux系統(tǒng)不同進程用戶空間進程堆中的堆塊相關(guān)信息。

實驗結(jié)果表明本文研發(fā)的插件能成功地提取出不同Linux版本的用戶空間進程堆信息。隨著Linux系統(tǒng)的更新，用戶空間進程堆及其結(jié)構(gòu)中字段位置發(fā)生了一些變化，當(dāng)使用vtype描述信息解析堆時，根據(jù)信息名稱就能進行解析，因此本文研發(fā)的插件具有較強的兼容性。

4.2 堆溢出攻擊檢測測試

House_HiJack使用堆信息提取插件所收集的信息。檢測是否觸發(fā)house of spirit攻擊時存在的3個攻擊特性：Is_HouseOfSpirit、Is_FakeHeapBlock和Is_PtrContorl。如果該程序只包含某些特征，則意味著該程序包含house of spirit攻擊，但危害程度較低，或者該程序不包含house of spirit攻擊。如果該程序包含所有三個攻擊特征，則意味著該程序不僅包含house of spirit攻擊，還包含危險程序。

4.2.1 house of spirit攻擊檢測測試

以house_of_ spirit_text程序的自動檢測和追蹤為例，演示House_HiJack的檢測過程。圖12顯示了house_of_ spirit_text測試程序的關(guān)鍵觸發(fā)代碼。

如代碼所示，將數(shù)據(jù)寫入輸入指針時存在溢出漏洞?？梢砸绯霾⑿薷腷in［0］的值，以寫入指向任何內(nèi)存地址的輸入指針。然后通過輸入數(shù)據(jù)來構(gòu)造1個偽堆塊結(jié)構(gòu)，當(dāng)程序釋放bin［0］時，會觸發(fā)house of spirit攻擊。此時，當(dāng)程序應(yīng)用相同大小的堆塊時，可以將目標內(nèi)存作為堆塊結(jié)構(gòu)應(yīng)用，攻擊者可以修改關(guān)鍵指針的數(shù)據(jù)，以達到任意地址寫入的目的。

通過監(jiān)視程序即將釋放的堆指針。當(dāng)堆指針即將釋放時，Is_HouseOfSpirit組件觸發(fā)第1攻擊特性檢測算法以檢查指針變化。如果釋放指針不屬于已知已分配堆塊，則觸發(fā)house of spirit第1攻擊特征。如圖13所示。檢測到了house of spirit第1攻擊特征。

在檢測到house of spirit第1攻擊特征后，在程序內(nèi)存空間中搜索堆內(nèi)存，若發(fā)現(xiàn)偽造堆塊則檢測到house of spirit第2攻擊特征。識別的偽造堆塊如圖14所示。

在檢測到house of spirit第2攻擊特征后，將檢查關(guān)鍵指針數(shù)據(jù)的可控性。如果指針數(shù)據(jù)是符號值，則表示關(guān)鍵指針數(shù)據(jù)發(fā)生了變化，追蹤控制流。指針數(shù)據(jù)變化檢查結(jié)果如圖15所示。

4.2.2 house of spirit攻擊檢測測試結(jié)果

本文從shellphish / how2heap測試集中選取5個具有堆溢出漏洞的實驗程序進行驗證。

為了更好地反映系統(tǒng)的效果，比較了插件與現(xiàn)有漏洞攻擊檢測技術(shù)的差異。在實驗期間，每個測試程序都提交給House_HiJack和CRAX系統(tǒng)進行測試。

CRAX系統(tǒng)是SKHuang等提出的一種基于動態(tài)符號執(zhí)行和著色分析技術(shù)研發(fā)的house of spirit類型攻擊檢測工具［20］。通過監(jiān)控程序的動態(tài)運行過程來檢測IP劫持的狀態(tài)，使用動態(tài)符號執(zhí)行和著色分析技術(shù)來監(jiān)視程序運行過程中的程序控制流和數(shù)據(jù)流狀態(tài)信息，對觸發(fā)house of spirit漏洞觸發(fā)點的符號數(shù)據(jù)的關(guān)鍵信息進行監(jiān)控，構(gòu)造觸發(fā)house of spirit攻擊的數(shù)據(jù)約束，并求解約束條件，可有效的對該類型攻擊進行檢測。

測試用例生成如表2所示。其中t1表示系統(tǒng)完成實驗樣本分析與檢測所需的時間，t2表示系統(tǒng)完成控制流追蹤所需的時間。

表2中的結(jié)果表明，CRAX系統(tǒng)和本文研發(fā)的系統(tǒng)都可以成功檢測全部5個house of spirit類型的堆溢出攻擊。

通過比較t1與t2的數(shù)據(jù)可以看出。CRAX系統(tǒng)對測試程序的分析時間短于本文提出的檢測方法，但CRAX系統(tǒng)無法為所有五個測試程序追蹤控制流。House_HiJack系統(tǒng)為其中3個程序成功追蹤控制流代碼。

這表明CRAX系統(tǒng)雖然能快速的檢測其是否為house of spirit類型堆溢出攻擊，但無法定位其最終的自由指針變化過程，無法追蹤其shellcode。而本文研發(fā)的系統(tǒng)可以成功定位該類型攻擊的控制流，通過控制流獲取shellcode。這表明本文提出的檢測方法是有效的。

House_HiJack插件對每個測試程序的檢測過程進行詳細記錄和分析，結(jié)果如表3所示。

從表3可以看出，對于pwn200、shaxian和house_ of_spirit_test 3個測試用例，插件可以檢測到house of spirit第1攻擊特征、第2攻擊特征和第3攻擊特征3個關(guān)鍵特征。因此，可以在3個攻擊特征檢測的同時追蹤構(gòu)造相應(yīng)的偽堆塊和關(guān)鍵指針數(shù)據(jù)變化，從而追蹤控制流，以獲得最終的shellcode代碼。house_ of _spirit和example測試用例只能檢測house_of _spirit第1攻擊特征和第2攻擊特征，但無法檢測到第3攻擊特征，表明測試用例已經(jīng)實現(xiàn)了對要釋放的指針數(shù)據(jù)的修改，并偽造了堆塊結(jié)構(gòu)，但沒有進一步的指針利用，因此無法追蹤控制流。

5 結(jié) 論

本文提出了一種在Linux下檢測house of spirit類型攻擊的技術(shù)。該技術(shù)利用動態(tài)追蹤用戶空間進程堆信息。為了提取出Glibc堆中的信息，本文分析了Glibc在內(nèi)存中的堆實現(xiàn)，堆結(jié)構(gòu)中含有的字段并結(jié)合內(nèi)存取證框架和字段在結(jié)構(gòu)信息中的偏移量，設(shè)計出提取Glibc堆及其內(nèi)部信息的功能插件，這些插件可以解析Linux系統(tǒng)中用戶空間進程堆內(nèi)部含有的信息。

在此基礎(chǔ)上，提出了一種house of spirit型堆溢出漏洞自動檢測模型?；谠撃Ｐ停瑢崿F(xiàn)了house of spirit型堆溢出漏洞的檢測與控制流追蹤。

實驗結(jié)果表明本文提出的方法可以重現(xiàn)進程運行時堆及其內(nèi)部組件在內(nèi)存中的分配情況，進而反映進程中堆內(nèi)存信息，通過利用這些信息成功的檢測出Linux平臺下house of spirit類型攻擊的存在并追蹤控制流。

參 考 文 獻：

［1］ MOSLI R， LI R， YUAN B， et al. Automated Malware Detection Using Artifacts in Forensic Memory Images［C］//2016 IEEE Symposium on Technologies for Homeland Security （HST）. USA ：IEEE， 2016：1.

［2］ JEONG D， LEE S. Forensic Signature for Tracking Storage Devices： Analysis of UEFI Firmware Image， Disk Signature And Windows Artifacts［J］. Digital Investigation， 2019， 29：21.

［3］ CASE A， RICHARD G. Memory forensics： The path forward［J］. Digital Investigation， 2017，20：23.

［4］ 張瑜，劉慶中，李濤，等.內(nèi)存取證研究與進展［J］.軟件學(xué)報，2015，26（5）：1151.

ZHANG Yu， LIU Qingzhong， LI Tao， et al. Research and Development of Memory Forensics［J］. Journal of Software， 2015，26（5）：1151.

［5］ HEDBERG T D， KRIMA S， CAMELIO J A. Embedding X.509 Digital Certificates in Three-Dimensional Models for Authentication， Authorization， and Traceability of Product Data［J］. Journal of Computing & Information Science in Engineering， 2017，17（1）：011008.

［6］ KIM D， KWON B J， DUMITRA T. Certified Malware： Measuring Breaches of Trust in the Windows Code-Signing PKI［C］//2017 ACM SIGSAC Conference on Computer and Communications Security.New York： ACM， 2017：1435.

［7］ UGARTE-PEDRERO X， GRAZIANO M， BALZAROTTI D. A Close Look at a Daily Dataset of Malware Samples［J］. ACM Transactions on Privacy and Security， 2019，22（1）：1.

［8］ 翟繼強，陳攀，徐曉，楊海陸.面向Windows 10系統(tǒng)段堆的內(nèi)存取證研究［J］.西北工業(yè)大學(xué)學(xué)報，2021，39（5）：1139.

ZHAI Jiqiang， CHEN Pan， XU Xiao， Yang Hailu. Research on Memory Forensics for Windows 10 System Segment Heap ［J］. Journal of Northwestern Polytechnical University，2021，39（5）：1139.

［9］ Description of User Account Control and Remote Restrictions in Windows Vista ［EB/OL］. （2020-9-18）［2020-12-09］.

［10］Sigcheck v2.81［EB/OL］.（2020-9-17）［2020-12-09］.

［11］UROZ D， RICARDO J. On Challenges in Verifying Trusted Executable Files in Memory Forensics［J］. Digital Investigation， 2020，32：300917.

［12］SYLVE J T， MARZIALE V， RICHARD G G. Pool Tag Quick Scanning for Windows Memory Analysis［J］. Digital Investiga-tion， 2016，16：25.

［13］翟繼強，徐曉，陳攀，等.基千元數(shù)據(jù)和指令流的 64 位 Windows 堆棧取證［J］.哈爾濱理工大學(xué)學(xué)報，2021，26（5）：51.

ZHAI Jiqiang，XU Xiao，CHEN Pan，et al.Stack Forensics Based on Meta Data and Instruction Flow of 64-bit Windows ［J］.Journal of Harbin University of Science and Technology，2021，26（5）：51.

［14］ZHANG N， ZHANG R， SUN K， et al. Memory Forensic Challenges Under Misused Architectural Features［J］. IEEE Transactions on Information Forensics & Security， 2018，13（9）： 2345.

［15］ZHU W T， LIN J. Generating Correlated Digital Certificates： Framework and Applications［J］. IEEE Transactions on Information Forensics & Security， 2016， 11（6）：1117.

［16］PANDEY A K， TRIPATHI A K， KAPIL G， et al. Current Challenges of Digital Forensics in Cyber Security［J］. Critical Concepts， Standards， and Techniques in Cyber Forensics， 2020： 31.

［17］PARIDA T， DAS S. PageDumper： a Mechanism to Collect Page Table Manipulation Information At Run-time［J］. International Journal of Information Security， 2021， 20（4）： 603.

［18］VOLATILITY： An Advanced Memory Forensics Framework［EB/OL］.（2020-11-11）［2021-6-18］.

［19］ZHAO X， HUANG S， PAN Z， et al. Buffer Overflow Vulnerability Detection Based on Unsafe Function Invocation［J］. Journal of Physics： Conference Series， 2020， 15（9）：1145.

［20］HUANG S K， HUANG M H， HUANG P Y， et al. Crax： Software Crash Analysis for Automaticexploit Generation by Modeling Attacks as Symbolic Continuations［C］// In 2012 IEEE Sixth International Conference on Software Security and Reliability， IEEE， 2012： 78.

（編輯：溫澤宇）

作者簡介：王家乾（1997—），男，碩士研究生；

韓 旭（1997—），男，碩士研究生.

通信作者：翟繼強（1972—），男，博士，教授，碩士研究生導(dǎo)師，E-mail：zaijiqiang@163.com.