實用級反主動防御rootkit設計思路
作者：白遠方 (ID: baiyuanfan, baiyuanfan@163.com, baiyuanfan@hotmail.com)
June 18, 2007
關鍵字：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反彈。
其他的特殊情況還有很多。作為一個成熟產品開發者，這些都是必須要考慮的。
感謝：VXK（郭宏碩）， xyzreg（張翼）。
附錄：提供幾個錄像，對本文的內容做一個展示錄像，Rootkit穿越各種流行的主動防御系統。