特殊注冊表鍵值AppInit_Dlls

如果你對計算機安全有所了解，那麼各種各樣的注冊表啟動項應該會有所了解，今天我會細述一個很著名的啟動項：AppInit_Dlls鍵值。

AppInit_Dlls鍵值位於注冊表 HKLM\Microsoft\Windows NT\CurrentVersion\Windows下面，相對於其他的注冊表啟動項來說，這個鍵值的特殊之處在於任何使用到User32.dll 的EXE、DLL、OCX等類型的PE文件都會讀取這個地方，並且根據約定的規范將這個鍵值下指向的DLL文件進行加載，加載的方式是調用 LoadLibrary。

驗證方法有很多，最容易想到的就是使用調試器，在LoadLibrary調用的時候下斷點，你會發現User32.DLL讀取了這個鍵值並且使用了LoadLibrary去調用這個鍵值指向的DLL文件。一個更好的方法就是看看 KB197571 的介紹了。

AppInit_Dlls的鍵值是一個非常危險的鍵值，從某種程度上來說，這是一個Windows最容易被人利用的漏洞，因為只要有任何的惡意軟件在這裡進行了修改，那麼就意味著任何使用到User32.DLL的進程都會被AppInit_DLLs指向的DLL所注入。因為進程內部的DLL是共享整個進程空間的，因此意味著進程裡面的DLL是可以控制整個進程的行為的。由於User32.DLL是一個非常非常通用的DLL，它提供了大多數Win32用戶界面、消息相關的功能，只有極少數的程序不會使用User32.DLL，因此一旦有惡意軟件修改了AppInit_Dlls鍵值，那麼整個系統都有可能處於非常危險的狀態。

眾所周知，Windows服務程序的啟動時機是可以非常早的，往往在用戶登錄之前就完成啟動了，而這個時候最常見的Run鍵值還不一定被處理完，而且Windows服務程序擁有相當高的權限（默認是Local System，可以對系統裡面所有的資源進行操作），因此如果一個惡意軟件被加載到Windows服務裡面，那麼是會非常危險的。前文提到，任何進程使用了User32.DLL，都會對AppInit_Dlls鍵值指向的DLL進行加載，如果是一個Windows服務程序，也不例外！

由於AppInit_Dlls是一種系統全局性的Hook（system-wide hook），要規避此類的Hook的確很困難，雖然使用驅動程序進行保護能夠規避此類問題，但也不是非要使用驅動程序進行處理的。前文說過，只有當使用到User32.DLL這個模塊的時候才會觸發讀取AppInit_Dlls指向的DLL，如果不使用User32.DLL，那麼AppInit_Dlls是不會被使用到的。但是要讓一個程序不使用User32.DLL會變得非常困難（命令行窗口沒有使用User32.DLL），因為任何的窗口、消息都和這個模塊有關，為了保證有良好的用戶體驗，100%的窗口程序都和這個模塊有關。從開發角度來說，最好的一種解決辦法就是將程序功能邏輯和界面邏輯完全分離，功能邏輯模塊負責功能，界面邏輯模塊負責界面顯示，2者之間采用IPC機制進行交互，功能邏輯模塊不依靠User32.DLL,，而且作為獨立進程進行處理，這樣就可以規避AppInit_Dlls造成的Hook了。

類似的Windows安全相關的缺陷點其實還有很多的，這些缺陷點的來源是為了保證向下的兼容性。相信MIcrosoft已經發現並正在修補這些地方，從Windows Vista上可以看到，AppInit_Dlls的鍵值在Windows Vista上是不起作用的，因此在Windows Vista裡面，這個鍵值已經被拋棄了（改用另外一個鍵值執行類似的功能，但是增加了基於UAC的安全防護）。