一種多通道件加載漏洞檢測方法

一種多通道件加載漏洞檢測方法

dll（組件）是一組包含公共代碼和數(shù)據(jù)的函數(shù)。其他程序使用組件所需的接口調用所需的函數(shù)。在Windows操作系統(tǒng)中,除核心模塊外,應用程序可調用相對獨立的組件模塊,不僅便于程序功能的擴展、更新、排錯,而且能實現(xiàn)代碼重用以及功能模塊的按需加載,減少物理內存的占用量。因此,應用程序自身往往帶有許多特定的DLL組件,自身沒有組件的應用程序也會加載操作系統(tǒng)預設的系統(tǒng)組件。一旦應用程序需要加載一個DLL組件,操作系統(tǒng)必須知道該組件所在的存儲位置。Windows提供了2種方式說明待加載DLL組件的位置:組件完整路徑(帶文件名的絕對路徑)和組件文件名(相對路徑)。前者按照指定路徑尋找該加載的DLL,而后者沒有指定該DLL所在位置。為此,操作系統(tǒng)提供了預設的搜索目錄列表,按序逐一搜索給定的DLL文件名,一旦搜索成功就加載該位置的DLL。如果攻擊者把偽造的DLL放入該位置前的任意目錄(位于搜索目錄列表)中,則產生DLL劫持攻擊。Windows開啟了安全搜索模式(standardsearchorder,SSO)和備用搜索模式(LOAD_WITH_ALTERED_SEARCH_PATH),以減少被劫持的概率,微軟和應用軟件廠商也通過補丁技術給DLL添加完整路徑。同時,編程人員杜絕使用相對路徑的組件加載也可以減少被劫持的概率。但是,組件劫持漏洞不斷被發(fā)現(xiàn),如MS11-071、MS11-076、MS11-085、MS12-012、MS12-014等。除操作系統(tǒng)本身存在DLL劫持漏洞外,第三方應用軟件自身攜帶的DLL同樣存在該漏洞,如AutoCAD2007、GoogleEarth、Winamp、Skype等。這種漏洞從本地利用延伸到可以遠程利用,如MS12-014。同時,利用該漏洞的劫持攻擊能夠繞過現(xiàn)有對堆棧保護的安全機制,如DEP,StackGuard以及地址隨機化等,其威脅程度日趨嚴重。而且操作系統(tǒng)軟件和應用軟件還存在許多未知DLL加載漏洞,挖掘這些漏洞可以達到防范于未然,提早預備防護措施。利用可信計算平臺作為可信計算基,可以完成實體信任的傳遞和組件完整性驗證。虛擬化技術也為二進制代碼的完整性驗證提供了支持,可以檢測出隱秘的組件。Dymo提供了內存代碼的度量,防止外部代碼在合法代碼中的執(zhí)行。如果偽造的DLL是未知的組件,該技術可以阻止該組件的加載。但未知組件的信任識別依然是一個難題。因此,研究DLL組件動態(tài)加載漏洞的檢測具有重要的實際應用價值。Kwon等提出了程序動態(tài)分析和程序靜態(tài)分析挖掘DLL加載漏洞的方法。動態(tài)分析采用Pin的動態(tài)代碼插樁技術(dynamicbinaryinstrument,DBI)截獲9個函數(shù)獲取程序的加載信息,然后離線檢測漏洞。該方法屬于動態(tài)程序分析,在用戶態(tài)截獲的函數(shù)較多,導致性能開銷過高,同時受限于程序執(zhí)行的單一行為跡。靜態(tài)分析采用IDA和逆向切片技術分析可能存在的程序漏洞,檢出的漏洞數(shù)明顯高于動態(tài)分析。該方法解決了動態(tài)分析代碼覆蓋不足的問題,檢測結果更準確,但參數(shù)解析失敗、反匯編失敗等因素會產生漏報。DLLHijackAuditKit提供了利用ProcMon工具動態(tài)檢測組件加載漏洞的工具集,需要手工操作。程序分析方法的分析時間比較長,難以在主機系統(tǒng)在線部署和動態(tài)檢測。同時,一旦主機系統(tǒng)的程序更新,需要對更新后的代碼進行分析,才能檢測新的漏洞。根據(jù)動態(tài)鏈接庫加載時的路徑搜索行為,本文提出一種在線檢測動態(tài)鏈接庫加載漏洞的方法,以實現(xiàn)離線檢測DLL劫持攻擊,從而緩解程序分析方法中的單一行為跡問題。同時,結合組件加載的上下文,該方法實現(xiàn)監(jiān)測點的最小化,以減少對系統(tǒng)干擾,緩解系統(tǒng)部署難的問題。1對該組件的攻擊進行檢測DLL加載分為隱式加載和顯式加載。應用程序在初始化階段,會根據(jù)導入表(IAT)加載所需的DLL以及這些DLL導入的其他DLL,這屬于隱式加載。顯式加載是指應用程序內部代碼顯式調用LoadLibrary或LoadLibraryEx加載一個指定的DLL。隱式加載時,DLL一般都通過文件名來搜索并加載;顯式加載時,既可以指定DLL的完整路徑,也可以只指定DLL文件名來加載。然而,不管是隱式加載還是顯式加載,其實質都是調用LoadLibrary實現(xiàn),LoadLibraryEx在LoadLibrary內部被調用。通過逆向分析LoadLibrary函數(shù),發(fā)現(xiàn)其DLL加載過程可以分為3個階段:搜索、映射和初始化。LoadLibrary根據(jù)傳入的DLL完整路徑或DLL文件名來搜索待加載DLL,將其映射到進程的內存空間,再調用DLL入口函數(shù)完成對DLL初始化。操作系統(tǒng)根據(jù)傳入的DLL文件名或文件完整路徑來查找DLL的物理位置,從而獲得DLL文件句柄。搜索階段,先查找該DLL是否已加載,如果已加載則直接返回已經加載的組件的句柄,并將其引用計數(shù)加1,以避免重復加載。如果沒有加載,接著查找注冊表鍵HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\KnownDLLs,判斷該組件是否為KnownDLL。如果該組件屬于KnownDLL,則根據(jù)注冊表中設定的路徑加載該組件DLL。如果該組件既沒有已經加載,也不是系統(tǒng)已知DLL,操作系統(tǒng)會根據(jù)LoadLibrary傳入的組件參數(shù)進行組件的位置搜索。組件參數(shù)為完整路徑,則直接搜索該組件。如果搜索成功,則直接加載。如果組件參數(shù)為文件名,操作系統(tǒng)會按照事先設定的搜索目錄列表對DLL文件進行搜索,直到DLL找到或者目錄搜索完畢。如果搜索成功,則根據(jù)搜索階段得到的DLL完整路徑打開DLL文件并獲取文件句柄。接著分配內存區(qū)域,然后將DLL文件內容映射到內存,把獲得DLL的入口地址保存到數(shù)據(jù)表中,并將DLL入口加入到加載模塊列表中。最后,操作系統(tǒng)載入該組件引用的其他DLL組件,修改IAT表項,更新DLL引用計數(shù),并調用DLL入口函數(shù)對DLL進行初始化。對于以文件名方式傳入的組件,操作系統(tǒng)采用一套搜索機制確定組件所在的物理存儲位置。操作系統(tǒng)默認的搜索目錄列表為:{應用程序所在目錄、當前目錄、系統(tǒng)目錄、16位系統(tǒng)目錄、Windows目錄、環(huán)境變量目錄}。該列表也稱為標準搜索模式(StandardSearchMode)。操作系統(tǒng)從列表的第一個路徑開始搜索給定的組件名稱,直到找到該組件所在的位置或者搜索失敗。該過程也稱為DLL組件的解析,找到了DLL組件稱為組件解析成功,搜索失敗稱為組件解析失敗。對于解析成功,如果組件所在的路徑不是搜索目錄列表的第一個,則搜索目錄中解析失敗過的路徑存在被劫持的風險。而DLL解析失敗意味著搜索目錄的全部路徑都存在被劫持的風險。因此,在DLL組件解析過程中,只要存在解析失敗的路徑,就存在該路徑被劫持的風險。在WindowsXPSP2及以后的版本中,Windows默認開啟安全搜索選項,將當前目錄移至Windows目錄之后,搜索目錄列表改為{應用程序所在目錄、系統(tǒng)目錄、16位系統(tǒng)目錄、Windows目錄、當前目錄、環(huán)境變量目錄}。該搜索模式簡稱安全搜索模式(SafeDllSearchMode)。該模式可以減少當前目錄被劫持的風險。另外,搜索目錄和順序也可以通過參數(shù)設置或調用特定函數(shù)來改變。應用程序目錄可以通過LoadLibraryEx傳入的LOAD_WITH_ALTERED_SEARCH_PATH標志,修改應用程序所在的完整路徑。從WindowsXPSP1起,微軟提供SetDllDirectory函數(shù),在調用LoadLibrary前動態(tài)修改當前目錄為該函數(shù)傳入的路徑值,該搜索模式可以減少當前目錄被劫持的攻擊面。當采用這種方式時,安全搜索模式將無效。操作系統(tǒng)還提供SetCurrentDirectory函數(shù)來在程序中動態(tài)修改某進程的當前目錄,將存儲進程當前目錄的變量值設置為傳入的絕對路徑,并且這種方式可以與安全搜索模式結合使用。上述的搜索安全增強方法歸納為移動搜索目錄列表中路徑項的位置和修改對應的路徑項。它們的本質都是減少路徑被劫持的攻擊面,從而減少搜索失敗的概率,達到安全增強的目的。但對于組件解析失敗而言,這些技術都失去防護作用。2基于白盒的系統(tǒng)行為監(jiān)控為了檢測組件加載漏洞和劫持攻擊,需要監(jiān)測組件的加載行為。監(jiān)控系統(tǒng)運行必須要在被監(jiān)控對象中部署探針以獲取系統(tǒng)運行的狀態(tài)數(shù)據(jù),然后根據(jù)這些數(shù)據(jù)分析或者檢測可能的異常。觀察系統(tǒng)運行的方法有黑盒和白盒2種。黑盒方法是把系統(tǒng)看作是不透明的盒子,無需源代碼,通過外部觀察系統(tǒng)的資源訪問(文件、進程等)或者資源消耗(CPU、內存、網(wǎng)絡帶寬等)。黑盒的好處是對系統(tǒng)干擾小,但獲取的信息可能不夠精準。白盒方法借助設計文檔或者程序員的幫助,往程序代碼中定向地植入探針。其優(yōu)點是監(jiān)測的針對性強、信息準確,但對系統(tǒng)的干擾比較多,且后期維護難度加大。Kwon等Hooking了用戶態(tài)的9個函數(shù),實現(xiàn)了組件加載漏洞的檢測,其監(jiān)控方法可以歸于白盒方法。傅建明等通過在核心態(tài)Hooking應用程序的系統(tǒng)調用構建軟件行為模型,其監(jiān)控方法可以歸于黑盒。源于該內核態(tài)監(jiān)控思路,利用系統(tǒng)調用的上下文,給出一種基于灰盒的系統(tǒng)行為監(jiān)控方法。因此,灰盒方法的難點在于如何獲取行為的上下文信息,提高監(jiān)控的準確性。2.1定向和按需監(jiān)控從內核態(tài)選擇監(jiān)控點實現(xiàn)組件加載行為監(jiān)控,需要明確組件加載的過程,第一節(jié)描述了組件加載分為3個階段:搜索、內存分配和映射、初始化。組件加載漏洞源于第一個階段,操作系統(tǒng)對組件的遍歷搜索。Kwon等放置探針的9個函數(shù)只有LdrpResoveDllName函數(shù)負責組件的搜索。通過逆向分析,LdrpResoveDllName會通過KiFastSystemCall進入內核態(tài),調用ZwQueryAttributesFile檢測組件是否存在。因此,ZwQueryAttributesFile作為組件加載漏洞檢測的監(jiān)控點,也是唯一的監(jiān)控點。該監(jiān)控點位于核心態(tài),任何調用該函數(shù)的信息都會記錄。就是說,LdrpResoveDllName會調用該函數(shù)外,GetFileAttributesW和SearchPathW等函數(shù)也會調用ZwQueryAttributesFile查詢資源是否存在。因此,必須做到按需監(jiān)控,即只監(jiān)控組件加載時的路徑搜索行為。一種直觀的方法是從輸入?yún)?shù)中可以提取路徑信息,利用DLL組件的后綴名過濾非DLL路徑查詢的調用,從而部分減少監(jiān)控的范圍。同時,采用?；厮菁夹g定位該調用是否為組件搜索,從而剔除不屬于組件加載搜索的ZwQueryAttributesFile調用,實現(xiàn)定向和按需監(jiān)控。程序的函數(shù)在調用過程中,會將調用的上下文信息,如棧的基址、局部存儲空間、調用參數(shù)和返回地址等,保存到內存的棧中,棧中保存上下文信息的結構稱為棧幀,這些信息用于被調用函數(shù)結束后能順利地返回調用點。函數(shù)可以嵌套調用,調用一次壓入相應的調用上下文到棧中,從而形成棧幀鏈。因此,當前函數(shù)中的EBP寄存器保存當前棧幀的基址,該(EBP+4)保存的則是此次調用結束后返回的地址。通過解析棧的結構,可以通過一個個棧幀回溯到應用程序最初引發(fā)系統(tǒng)調用的代碼地址。采用逆向分析方法,獲得了從ZwQueryAttributesFile到LdrpResolveDllName的返回地址,如圖1所示。從圖1可以看出,棧幀回逆到LdrpResolveDllName++0x12d的位置,對應的內存地址為0x7C93CE16。LdrpResolveDllName位于ntdll.dll中,其返回地址0x7C93CE16可以作為LdrpResolveDllName發(fā)出調用的判據(jù)。但是,操作系統(tǒng)的地址空間分布隨機化技術會隨機化PE格式映像的加載基址,返回地址會變化。不過,地址空間隨機化并不會對地址的后2個字節(jié)造成影響。采用LdrpResolveDllName返回地址的末尾2個字節(jié)0XCE16,以及該地址中連續(xù)的8個字節(jié)0xE3840F944589C33B,作為判據(jù),確定ZwQueryAttributesFile調用是組件加載搜索路徑時發(fā)出的。因此,通過獲取ZwQueryAttributesFile的調用參數(shù)和調用棧幀的上下文信息,實現(xiàn)監(jiān)控行為的準確定位。2.2對組件加載的檢測在進行DLL組件搜索時,系統(tǒng)會根據(jù)當前設置的搜索選項,生成DLL搜索目錄字符串,里面包含了待搜索的所有目錄項。系統(tǒng)依次獲取每個目錄項,與DLL名稱字符串拼接,形成一個完整的文件路徑,然后判斷該路徑是否真實存在于磁盤中。如果找到了待加載DLL,打開獲取文件句柄后進入映射階段;否則,繼續(xù)搜索下一個目錄項,直到文件存在或所有目錄項均被搜索完。在拼接形成一個完整路徑后,系統(tǒng)最終會調用內核函數(shù)ZwQueryAttributesFile來完成判斷路徑是否對應真實存在的磁盤文件的操作,并根據(jù)該函數(shù)的返回結果進行下一步的操作。因此,通過內核態(tài)SSDTHOOKING技術,掛鉤ZwQueryAttributesFile,截獲DLL加載時的搜索信息。該函數(shù)的輸入?yún)?shù)包含了DLL路徑信息,輸出參數(shù)會在DLL搜索成功時得到設置。函數(shù)的返回狀態(tài)為STATUS_SUCCESS時,表示文件真實存在,否則,表示文件不存在或文件信息不符合。因此,可以通過解析輸入?yún)?shù)和判斷函數(shù)返回值,檢測DLL搜索是否成功。會話(session)可以描述一個組件加載的搜索結果。該Session包含每一次搜索的全路徑和搜索結果。每次搜索用2元組描述,形如{State,FullPath}。例如,{0C:\ProgramFiles\InternetExplorer\LPK.DLL}表示搜索C:\ProgramFiles\InternetExplorer\LPK.DLL失敗,而{1C:\WINDOWS\system32\LPK.DLL}表示搜索LPK.DLL成功。會話的構建過程就是組件加載漏洞的檢測過程。如果會話含有狀態(tài)為0記錄,則檢測出組件加載漏洞。Windows操作系統(tǒng)采用線程調度任務,因此,可以采用PID-TID-DLL標記一個會話,如0000-5e4-00000df4-MSISIP.DLL。任何時候,一個線程只有一個會話。當獲取一個組件搜索的調用時,解析其參數(shù)和上下文,得到一組信息{State,FullPath,DLL,PID,TID}。如果該PID和TID沒有會話-則新建一個會話,用PID-TID-DLL標記該新會話,同時插入記錄{State,FullPath}。如果該PID和TID有會話,但其會話的DLL名稱與該調用的不同,則把舊會話寫入日志,同時清空該會話,插入新的記錄{State,FullPath}。如果該DLL屬于原有會話,則直接在會話尾部插入新的記錄。因此,當線程檢索不同名組件或者超時時,把該舊的會話寫入日志。Algorithm1描述了組件搜索的會話構建過程,其中WriteSession函數(shù)負責把會話寫入日志,寫入時把PID解析為進程名,便于人們直觀理解。組件劫持檢測依賴于日志文件SLOG和FLOG。如果某進程同一個組件的不同搜索會話存在前后不一致,可能是組件劫持。組件劫持檢測算法如Algorithm2所示。該算法輸入為日志文件SLOG和FLOG,每次檢測出可疑的攻擊DLL被保存到FakeDLLList中。如果ReadSession的第二個參數(shù)為NULL,則表示從日志文件中取第一個會話;否則,表示獲取與第二個參數(shù)具有相同進程標識和組件標識的會話。RemoveSession是刪除日志文件中相同的會話;FindDllHiJacked尋找Session中搜索失敗的路徑是否在SLOG中,如果找到攻擊,則寫入攻擊列表中;IntersectSession從進程名和組件名都相同的兩個會話中尋找攻擊,如果找到攻擊,則寫入攻擊列表中。圖3描述了組件加載漏洞的檢測框架,該框架描述了用戶態(tài)的組件加載函數(shù)調用過程和調用關系。該檢測器D2HAT(dynamicDLLhijackaudittool)實現(xiàn)了堆棧回逆、參數(shù)解析、會話構建以及日志寫磁盤等基本功能。SLOG存放搜索成功的會話,FLOG存放含有搜索失敗的會話。漏洞檢測的結果直接放在FLOG中。劫持檢測按照Algorithm2,采用python實現(xiàn)。該編程語言在處理文本和大數(shù)據(jù)時,具有靈活、高效的特性。腳本程序讀取文件SLOG和FlOG作為輸入,將處理結果輸出到FakeDLLList中,完成離線檢測。3系統(tǒng)已下載的應用軟件實驗環(huán)境為VMWare環(huán)境下的WindowsXPSP3,虛擬機配置均為512M內存、40G硬盤。應用軟件直接從互聯(lián)網(wǎng)上下載,DLL劫持的樣本部分來自于exploit-db。下面從組件加載漏洞檢測、組件劫持檢測以及系統(tǒng)開銷分別介紹。3.1惡意4.2攻擊過程一個正常的程序啟動時,根據(jù)導入表加載DLL,可以將其加載的DLL分為3類:LoadedDLL、KnownDLL和需要搜索的DLL。存在加載漏洞的是后面2類。KnownDLL為操作系統(tǒng)自帶的系統(tǒng)DLL,注冊表中保存了該類DLL的加載路徑,系統(tǒng)會嘗試用該絕對路徑來加載DLL,劫持很難發(fā)生,除非該DLL缺失。需要搜索的DLL,系統(tǒng)會按照前面講到的搜索機制來進行搜索,可能會使得DLL劫持有機可乘。為了更加細致的分析哪些DLL的加載會導致劫持,本文將需要搜索的Dll組件分為部分搜索的DLL(PartialSearch)和搜索全部失敗的DLL(SearchFailure)。PartialSearch的DLL位于搜索目錄列表的中間路徑,操作系統(tǒng)經過至少一次的搜索失敗才能成功找到該組件。如果將同名的、偽造的DLL組件放置于搜索失敗的路徑上,則可以成功實施惡意DLL的加載。SearchFailure的DLL是指該DLL不存在搜索目錄列表的任何路徑中,該類DLL面臨本地劫持和遠程劫持的威脅。在測試環(huán)境中加載檢測工具-D2HAT,然后加載相應的測試軟件,模仿正常用戶的操作使用該軟件,操作過程若3～5min左右,卸載該測試軟件。根據(jù)日志文件FLOG,整理出DLL加載漏洞信息如表1所示。表1中PartialSearch所列的數(shù)據(jù)表示這些組件都能在搜索目錄列表的路徑中找到,但至少在第一個路徑上搜索失敗,攻擊者在任何失敗路徑上放置偽造組件,該偽造組件都可以被加載。PartialSearch型漏洞會造成組件被本地或者遠程劫持,安全風險較高。該列數(shù)據(jù)分為本文檢測的漏洞和文中提到的漏洞,本文的檢測方法明顯優(yōu)于文的動態(tài)插樁的分析方法。究其原因,可能是文的分析時間較短,或者沒有模仿用戶操作軟件,使得需要用戶觸發(fā)的漏洞都沒有被檢測到。另外,按照搜索成功的路徑統(tǒng)計PartialSearch的數(shù)據(jù),結果如表2所示,大部分被劫持的組件都是系統(tǒng)組件,也是產生風險的主要源泉。因此,應用軟件在加載系統(tǒng)組件時,應采用完整路徑,以避免被劫持。SearchFailure所列的數(shù)據(jù)表示該組件無法在給定的路徑上找到。如果全路徑的組件沒有找到,則該組件可以被定向劫持,該類型漏洞還比較多,其安全風險一般。例如QQ.exe在點擊“開始視頻會話”或“開始音頻會話時”,會以絕對路徑C:\ProgramFiles\Tencent\QQ\Plugin\Com.Tencent.NetDisk\Bin\Disk.dll嘗試加載Disk.dll,但由于該DLL不存在于該目錄,會出現(xiàn)加載失敗。第二種是組件在所有搜索路徑上都不存在,此類漏洞較少,但安全風險最高,可以容易地被用于遠程劫持。例如OfficePowerPoint2007運行時,點擊菜單欄“審閱”,powerpnt.exe會嘗試加載msdrm.dll,由于該DLL不存在,所以powerpnt.exe會對搜索路徑上的所有目錄進行搜索,并都出現(xiàn)搜索失敗。如果將惡意DLL放置于任何一條搜索目錄中,劫持都會成功。3.2f機構計算機病毒動態(tài)如果FLOG對同一個進程和組件而言,存在2個不同的會話,則利用Algorithm2可以檢測出攻擊組件。采用2個實例說明該檢測過程,一個是在部分搜索(PartialSearch)的會話中的劫持;另一個是搜索失敗(SearchFailure)的會話中的劫持。第三節(jié)中的圖2描述了應用程序InternetExplorer6加載組件LPK.DLL時的搜索會話,D2HAT會記錄該會話到FLOG中。如果攻擊者把偽造的LPK.DLL放置在IE的程序目錄,則其搜索會話變?yōu)閳D4,該會話記錄在SLOG中。根據(jù)圖2和圖4的會話,利用Algorithm2中FindDllHiJacked可以得到攻擊者的組件為C:\ProgramFiles\InternetExplorer\LPK.DLL。應用程序OfficePowerPoint2007打開pptx文檔時,點擊菜單欄“審閱”,會嘗試加載msdrm.dll,但搜尋失敗,其會話如圖5所示,被記錄在FLOG中。如果攻擊者把偽造組件放置在當前目錄,則可以實現(xiàn)遠程劫持,其會話如圖6所示,被記錄在FLOG中。利用Algorithm2中IntersectSession可以得到攻擊者的組件為msdrm.dll。3.3其他加載實驗數(shù)據(jù)微軟提供了一套工具集監(jiān)測系統(tǒng)的運行,如注冊表、文件、網(wǎng)絡、進程/