實用級反主動防禦rootkit設計思路

關鍵字：rootkit，反主動防禦，網絡監控，ring0，mcafee8.5i，KIS6，ZoneAlarm Pro，實用級產品測試
目錄：
反主動防禦rootkit的產生背景及其必要性
反網絡訪問主動防禦
反API鉤子進程行爲主動防禦
反系統Notify進程行爲主動防禦
繞過監控進入ring0安裝驅動
實用級反主動防禦rootkit的通用性問題


反主動防禦rootkit的產生背景及其必要性
        當前隨着新型木馬，病毒，間諜軟件對網絡安全的威脅日益加重，傳統的特徵查殺型的安全產品和簡單的封包過濾型防火牆已不能有效保護用戶，因此各大安全公司紛紛推出自己的主動防禦型安全產品，例如卡巴斯基kis6，mcafee8.5i，ZoneAlarm Pro等，這些產品應對未知的病毒木馬都有很好的效果，若非針對性的作過設計的木馬和rootkit，根本無法穿越其高級別防禦。因此，反主動防禦技術，作爲矛和盾的另一方，自然被滲透者們提上日程；由於主動防禦安全產品的迅速普及，爲了不使後門木馬被彈框報警，具有反主動防禦能力的rootkit成爲了一種必然選擇。


反網絡訪問主動防禦
        幾乎現在每個防火牆都具有應用程序訪問網絡限制功能。一個未知的程序反彈連接到外網，或者是在本地監聽端口，基本上都會引起報警。而且對系統進程的行爲也有了比較嚴格的審查，原先的注射代碼到winlogon等系統進程，在向外反彈連接的方法，很多主動防禦軟件都會阻止了。
        很多防火牆的應用程序訪問網絡限制，都可以通過摘除tcpip.sys上面的過濾驅動，並還原tcpip.sys的Dispatch Routines來繞過。據稱這是因爲在ndis層次取得進程id不方便而導致的。但是如果在一個實用級的rootkit裏應用此方法則是不智之舉，因爲存在部分防火牆，如ZoneAlarm，其ndis過濾層必須和tdi過濾層協同工作，纔會放行網絡連接。至於ndis層次的中間層驅動的摘除，和NDIS_OPEN_BLOCK的還原，則是一項不太可能完成的任務，因爲無法從原始文件中讀取的方法，獲得NDIS_OPEN_BLOCK的原始值；即使能夠成功恢復ndis鉤子，也不能保證系統可以正常運行，很可能會出現各種不明症狀。
        到現在爲止，繞過應用程序訪問網絡限制最好的選擇，還是那兩個：簡單的一個，注射代碼到一個ie進程，用它反彈連接出來，訪問外網；複雜的選擇則是應用內核驅動，如ndis hook/添加新的ndis protocol，來實現端口複用，或者使用tdi client driver反彈連接。已經有很多木馬和rootkit使用前者，因其簡單易行，在實際開發中工程量小，出現問題的可能性也少得多，產品成熟的時間代價也小。但是目前很多的主動防禦已經注意到這一點，並且在程序行爲監控中嚴密防範了其他程序對ie的感染行爲。

    如圖，想要使用殭屍IE訪問網絡的木馬被攔截


反API鉤子進程行爲主動防禦
        接下來是主動防禦系統的很重要的一部分：進程行爲監控。該部分主動防禦軟件一般通過兩種解決方案來執行，一是API鉤子，二是windows支持的notify routine。
        大量的主動防禦安全軟件，如KIS6，ZoneAlarm Pro，使用API鉤子來監控進程的危險行爲。如注射遠程線程，啓動傀儡IE，加載驅動，註冊服務，修改敏感系統註冊表鍵值等。但是作爲一個rootkit，完全繞過這些操作，基本上是不可能的；於是擺放在面前的任務，就是如何擊敗這種主動防禦。
        對於特定種類的監控，總是有特定的方法可以繞過。比如注射遠程線程，如果常用的CreateRemoteThread被監控了，可以嘗試採用Debug API， SetThreadContext的方法繞過，也可以嘗試採用hook其ntdll!ZwYieldExecution等頻繁調用的函數來裝載自己的DLL模塊。 註冊表監控，我的朋友xyzreg曾經寫過系列文章，提出了很多種方法，包括RegSaveKey, Hive編輯等方法繞過卡巴斯基的註冊表監控，其Hive編輯的方法目前仍未能有任何主動防禦系統攔截。
        但是從一個通用型，爲實戰設計的實用型rootkit來說，採用這些特定的技術並不是一個非常好的選擇；因爲這些技術可以保證對付一個主動防禦軟件，卻不能保證通用，甚至通用性很差。而且針對每一個可能被主動防禦攔截的行爲，都採用一套特定的繞過技術，從工程代價上來講，太過巨大，開發耗時，等其成熟更是不知道要多少時間來測試和更改。因此我們需要的一個相對涵蓋範圍廣，能夠解決絕大多數主動防禦技術的解決方案。
        針對API鉤子實現的進程行爲監控，一個較好的通用解決方案就是卸載所有安全軟件所安裝的API鉤子。爲兼容性和穩定起見，幾乎所有的安全軟件在安裝API鉤子時都會選擇hook SSDT表，例如KIS6，ZoneAlarm Pro。我們如果能夠進入ring0，就可以使用一個驅動程序，讀取系統文件ntoskrnl.exe/ntkrnlpa.exe/ntkrpamp.exe，從中提出我們所希望的SSDT表的原始函數地址，替換被安全軟件hook的地址，用此方法可以通用性很好的解決絕大多數的API鉤子實現的進程行爲監控。不過此方法有一個前提，就是事先必須繞過監控進入ring0。關於如何實現此前提，請閱讀第五部分，“繞過監控進入ring0安裝驅動”。
    
    如圖，ZoneAlarm Pro更改了大量的SSDT函數地址來監控程序行爲。



反系統Notify進程行爲主動防禦
        部分主動防禦安全軟件不僅僅是用API鉤子，同時使用了微軟提供的Notify Routine，來監視進程的行爲。使用該技術的安全軟件不是太多，但是也不至於少到一個實用級別rootkit可以忽略的程度。
        以下幾個微軟DDK函數，PsSetCreateProcessNotifyRoutine，PsSetCreateThreadNotifyRoutine，PsSetLoadImageNotifyRoutine，被用作支持主動防禦軟件監控新進程的建立，新線程的建立，和一個新的模塊被加載。處理該種類型的防禦不能簡單的清空NotifyRoutine就完事，因爲系統本身，還有一些第三方正常模塊和驅動，可能添加和使用該鏈表。
        解決方案，一是可以先將使用了該技術的主動防禦系統的驅動程序模塊做一個列表出來，然後遍歷這三條鏈表，找出地址指向這些驅動模塊的項，再將這些項刪除脫鏈。但是這需要對大量主動防禦系統的研究和測試，並且通用型也不好。第二種方法，由於Notify Routine的監控力度要遠弱於API鉤子，因此在純ring3將程序做一些小的改動，就可以越過這種類型的監控。
        另外還有幾個SDK函數，可以提供對文件和註冊表的更改的notify。不能排除也有部分主動防禦軟件使用了它們。例如國產的超級巡警(AST.exe)，使用了RegNotifyChangeKeyValue，做了對註冊表敏感鍵值修改的事後警告提示。如果僅僅使用了API鉤子清除技術，那麼在此時就會被AST報警。和以上介紹的三個內核notify類似的也是，有不少正常的notify在被使用，不分青紅皁白的全部卸載，會導致系統異常。
        因此可見，Notify類監控雖然使用的不多，但是其對付的難度和需要的工程量，比API監控還要大。

    如圖，已經處理了API鉤子監控的rootkit仍然被notify方式的AST報警。


繞過監控進入ring0安裝驅動
        這部分是重中之重。由於幾乎每個主動防禦系統都會監控未知驅動的加載和試圖進入ring0的舉動， 而我們在第一，第二和第三部分繞過主動防禦要做的處理，都必須需要ring0權限。因此監控進入ring0，是一個獨立的話題，也是我們實現前三個部分需要的條件。
        直接添加註冊表項，ZwLoadDriver安裝驅動，是幾乎要被任何主動防禦系統報警。必須要採用一些隱蔽的或者是爲人不知的方法。總結目前已經公佈出來的進入ring0的辦法，
有以下幾種：
        感染文件，例如win32k.sys，添加自己的代碼到裏面，啓動的時候就會被執行。這種方法的優點是簡單易行，穩定度和兼容性很好。但是最大的缺點就是必須重新啓動以後，才能進入ring0，這是一個產品級別的後門所不能容忍的。而且微軟自己的系統文件保護容易繞過，mcafee和卡巴斯基的文件監控可就不是那麼容易了。
        利用物理內存對象，來寫入自己的代碼到內核，並添加調用門來執行。這個是最早被人提出的不用驅動進入ring0的辦法。因爲出來的時間太長了，所以有以下一些問題：更新的操作系統內核不支持，如2003SP1；很多的主動防禦系統會攔截，例如KIS6。所以這個辦法也不理想。
        利用ZwSystemDebugControl。這個代碼在國外有人放出來過，利用它寫內存，掛鉤NtVdmControl，進入ring0。此法缺陷在於老的windows2000不被支持，最新的windows2003sp1上也取消了這個函數的此能力。不過好處在於，這個方法用的人少，基本上沒有主動防禦會注意到它，並進行攔截。
        利用ZwSetSystemInformation的SystemLoadAndCallImage功能號加載一個模塊進入ring0。這個方法提出來比較久了，但是因爲用的人少，仍未被主動防禦軟件所重視。用得少的原因是，它不好用。它只能加載一個普通的模塊到內核並且調用，卻不是加載一個驅動，因此沒有一個DriverObject。這導致了非常多的麻煩。因爲要想使用這個辦法，必須先用這個辦法安裝一個簡單的內核模塊，再用這個模塊添加調用門等方式，執行代碼清除主動防禦的監視驅動安裝的鉤子，安裝一個正常的驅動，才能最終完成任務。而且這個方法似乎對windows2003sp1以上的系統也無效。
        因此，要想有一個相對完美的進入ring0解決方案，最好是尋找別人不知道或者使用很少的方法，或者將上面的有缺陷的方法做一個綜合，用多種方法通過判斷情況來選擇使用。我在這裏有一個新的思路提供給大家，微軟新公佈了一部分文檔，關於HotPatch的使用。HotPatch可以在執行中修改系統中存在的用戶態公用dll的內容，甚至是修改內核模塊的內容。具體代碼和細節，在這裏我不能多說。
        要想開發一個好的反主動防禦rootkit，繞過監控進入ring0是必不可少的，然而這部分也是使用不成熟技術最多的，最容易出現嚴重問題的部分。作爲一個負責任的實用級產品，一定要對這個部分作做詳細的測試，來保證自己的產品不會在某些特殊的環境，比如64位CPU運行32位系統，多核處理器，HyperThread處理器上面，出現故障或者藍屏。



實用級反主動防禦rootkit的通用性問題
        前文已述，本文的宗旨在於討論一種實用級別rootkit開發的可行性。因此，工程量的大小，需要投入的人力，時間和金錢，也是我們需要考慮的內容。必須要考慮更好的兼容性通用性，和工程上的開發代價和穩定成熟週期不能無限大。因此，對於部分新技術，例如BiosRootkit，VirtualMachine-Rootkit，本文不做討論，因爲那些都屬於如果要想做穩定通用，工程代價非常大，以至於他們只擁有技術上面的討論價值，而不具備作爲一個產品開發的可選解決方案的可能性。至少是目前來看是如此。
        每個主動防禦軟件的原理和構造都是不相同的，因此不可能指望有某一種方法，從工程上可以解決一個主動防禦系統，就可以無需測試的，保證無誤的解決其他系統。因爲這個原因，開發一個成熟穩定的反主動防禦rootkit，必然要在兼容各種主動防禦的系統的通用性上面下大功夫。按照不同的主動防禦系統，在程序裏switch case，應該是非常必要的，儘管絕大多數反主動防禦代碼原理上可以通用。基本上，在測試程序通用型的時候，常用的主動防禦軟件，是每種都要安裝一個並且仔細測試的。
        以下舉例說明，幾個常用主動防禦系統各自需要注意的特點，這都是筆者在實際開發中遇到的比較典型的例子。

Mcafee8.5，該主動防禦軟件在最大化功能時會禁止在系統目錄下創建可執行文件，光這一點就會讓幾乎全部rootkit安裝失敗，若非針對它做了設計。在這個系統下面，也不可能使用感染文件的方法來進入ring0。
KIS6，該系統會自動列舉運行的隱藏進程，並且彈框警告。因此在這系統下，不太可能把自己的進程隱藏。而且它列舉隱藏進程的手段很底層，很難繞過。
ZoneAlarm Pro，該系統下，如果一個其它的進程啓動IE並且訪問網絡，安全報警仍然會以該進程本身訪問網絡爲準執行，另外還會彈框警告，除非將自己的殭屍IE進程的父進程更改，或者不用IE來反彈連接。
國產的瑞星，總體來說這個系統的主動防禦弱於國外產品，但是它特殊在於，會對IE作出非常嚴格的限制，默認不允許IE裝載任何非系統的dll。因此在這個系統下基本不可能利用IE反彈。

        其他的特殊情況還有很多。作爲一個成熟產品開發者，這些都是必須要考慮的。