一種漏洞檢測的方法和系統的製作方法

2023-05-21 01:24:41

專利名稱：：一種漏洞檢測的方法和系統的製作方法
技術領域：
：本申請涉及信息安全的
技術領域：
，特別是涉及ー種漏洞檢測的方法，ー種漏洞檢測的系統，一種用於漏洞檢測的客戶端，以及，一種用於漏洞檢測的雲伺服器。
背景技術：
：公知的是，漏洞帶來的最大問題即是木馬，木馬通常會利用電腦程式漏洞侵入後竊取文件和用戶信息。木馬是ー種具有隱藏性的、自發性的可被用來進行惡意行為的程序。歷史上對計算機木馬的定義是，試圖以有用程序的假面具欺騙用戶允許其運行的ー類滲透。請注意，過去的木馬確實是這樣，但現在它們已無需偽裝自己。它們唯一的目的就是儘可能輕鬆地滲透並完成其惡意目標。「木馬」已成為ー個通用詞，用來形容不屬於任何特定類別的所有滲透。木馬技術發展至今，最為常見的就是網頁木馬，網頁木馬是網頁惡意軟體威脅的罪魁禍首，它表面上偽裝成普通的網頁文件或是將惡意的代碼直接插入到正常的網頁文件中，當有人訪問時，網頁木馬就會利用對方系統或者瀏覽器的漏洞自動將配置好的木馬的服務端下載到訪問者的電腦上來自動執行。網頁木馬的實質是利用漏洞向用戶傳播木馬下載器，準確地說，網頁木馬並不是木馬程序，而應該稱為網頁木馬「種植器」，也即ー種通過攻擊瀏覽器或瀏覽器外掛程序(目標通常是IE瀏覽器和ActiveX程序)的漏洞，向目標用戶機器植入木馬、病毒、密碼盜取等惡意程序的手段。網頁木馬實際上是ー個HTML網頁，與其它網頁不同的是該網頁是黑客精心製作的，用戶一旦訪問了該網頁就會中木馬。為什麼說是黑客精心製作的呢？因為嵌入在這個網頁中的腳本恰如其分地利用了IE瀏覽器的漏洞，讓IE在後臺自動下載黑客放置在網絡上的木馬並運行(安裝)這個木馬，也就是說，這個網頁能下載木馬到本地並運行(安裝)下載到本地電腦上的木馬，整個過程都在後臺運行，用戶一旦打開這個網頁，下載過程和運行(安裝)過程就自動開始。網頁木馬的防範只靠殺毒軟體和防火牆是遠遠不夠的，因為一旦黑客使用了反彈端ロ的個人版木馬(個人反彙編的一些殺毒軟體無法識別的木馬)，那麼殺毒軟體和防火牆就無可奈何，所以，現有技術中，網頁木馬的防範一般採用如下方式進行一、及時安裝安全補丁；這種打補丁的方式顯然受到系統服務商推出補丁的限制，並不能很好的全面防範網頁木馬。ニ、改名或卸載(反註冊)最不安全的ActiveXObject(IE插件)在系統中有些ActiveXObject會運行EXE程序，比如「自動運行程序」代碼中的Shell,application控制項，這些控制項一旦在網頁中獲得了執行權限，那麼它就會變為木馬運行的「溫床」，所以把這些控制項改名或卸載能徹底防範利用這些控制項的網頁木馬。但是ActiveXObject是為了應用而出現的，而不是為了攻擊而出現的，所有的控制項都有它的用處，所以在改名或卸載ー個控制項之前，必須確認這個控制項是不需要的，或者即使卸載了也不關大體的，但實際上用戶對此很難保證。三、提高IE的安全級別，禁用腳本和ActiveX控制項有些網馬只要調高IE的安全級別，或者禁用腳本，該網頁木馬就不起作用了。從木馬的攻擊原理可以看出，網頁木馬是利用IE腳本和ActiveX控制項上的一些漏洞下載和運行木馬的，只要我們禁用了腳本和ActiveX控制項，就可以防止木馬的下載和運行。然而，禁用腳本和ActiveX控制項會使一些網頁的功能和效果失去作用。顯然，上述現有技術受到各種各樣的條件限制，完全無法對網頁木馬進行全面、有效的識別。因此，目前需要本領域技術人員迫切解決的ー個技術問題就是提出一種全新的漏洞檢測的機制，用以對造成網頁木馬等安全問題的漏洞進行全面、有效的識別，提高用戶上網的安全性。
發明內容本申請所要解決的技術問題是提供一種漏洞檢測的方法和系統，用以對造成網頁木馬等安全問題的漏洞進行全面、有效的識別，提高用戶上網的安全性。為了解決上述問題，本申請公開了一種漏洞檢測的方法，包括針對機器碼代碼執行所調用的函數進行鉤掛；獲得所述函數的返回地址；依據所述返回地址檢測所述函數的入口指令是否為正常的調用指令CALL;若否，則判定檢測到漏洞。優選的，所述機器碼代碼為在腳本運行的由漏洞觸發的機器碼代碼Shellcode；所述鉤掛包括內嵌鉤掛InlineHook操作。優選的，所述的方法，還包括判斷所述返回地址是否在正常的系統模塊中，所述正常的系統模塊包括具有合法籤名信息的DLL文件；若否，則判定檢測到漏洞。優選的，所述的方法還包括獲取所述返回地址的內存屬性，判斷所述內存屬性是否包括可執行屬性；若否，則判定檢測到漏洞。優選的，所述包括可執行屬性的內存屬性包括允許執行屬性PAGE_EXECUTE；允許執行和讀取屬性PAGE_EXECUTE_READ；允許讀寫和執行代碼屬性PAGE_EXECUTE_READWRITE；允許讀寫拷貝和執行代碼屬性PAGE_EXECUTE_WRITECOPY。優選的，所述函數包括由調用指令CALL調用的下載進程的系統API函數和/或執行進程的系統API函數。優選的，所述正常的調用指令CALL為滿足標準彙編指令OPCODE格式的調用指令CALL。本申請實施例還公開了ー種漏洞檢測的系統，包括鉤掛模塊，用於針對機器碼代碼執行所調用的函數進行鉤掛；返回地址獲得模塊，用於獲得所述函數的返回地址；第一判斷模塊，用於依據所述返回地址檢測所述函數的入口指令是否為正常的調用指令CALL;若否，則判定檢測到漏洞。優選的，所述機器碼代碼為在腳本運行的由漏洞觸發的機器碼代碼Shellcode；所述鉤掛包括內嵌鉤掛InlineHook操作。優選的，所述的系統還包括第二判斷模塊，用於判斷所述返回地址是否在正常的系統模塊中，所述正常的系統模塊包括具有合法籤名信息的DLL文件；若否，則判定檢測到漏洞。優選的，所述的系統還包括第三判斷模塊，用於獲取所述返回地址的內存屬性，判斷所述內存屬性是否包括可執行屬性，若否，則判定檢測到漏洞。優選的，所述包括可執行屬性的內存屬性包括允許執行屬性PAGE_EXECUTE；允許執行和讀取屬性PAGE_EXECUTE_READ；允許讀寫和執行代碼屬性PAGE_EXECUTE_READWRITE；允許讀寫拷貝和執行代碼屬性PAGE_EXECUTE_WRITECOPY。優選的，所述函數包括由調用指令CALL調用的下載進程的系統API函數和/或執行進程的系統API函數。優選的，所述正常的調用指令CALL為滿足標準彙編指令OPCODE格式的調用指令CALL。本申請實施例還公開了一種用於漏洞檢測的客戶端，包括鉤掛模塊，用於針對機器碼代碼執行所調用的函數進行鉤掛；返回地址獲得模塊，用於獲得所述函數的返回地址；第一判斷模塊，用於依據所述返回地址檢測所述函數的入口指令是否為正常的調用指令CALL;若否，則判定檢測到漏洞。優選的，所述用於漏洞檢測的客戶端，還包括第二判斷模塊，用於判斷所述返回地址是否在正常的系統模塊中，所述正常的系統模塊包括具有合法籤名信息的DLL文件；若否，則判定檢測到漏洞。優選的，所述用於漏洞檢測的客戶端，還包括第三判斷模塊，用於獲取所述返回地址的內存屬性，判斷所述內存屬性是否包括可執行屬性，若否，則判定檢測到漏洞。本申請實施例還公開了一種用於漏洞檢測的雲伺服器，包括鉤掛模塊，用於針對機器碼代碼執行所調用的函數進行鉤掛；返回地址獲得模塊，用於獲得所述函數的返回地址；第一判斷模塊，用於依據所述返回地址檢測所述函數的入口指令是否為正常的調用指令CALL;若否，則判定檢測到漏洞。優選的，所述用於漏洞檢測的雲伺服器，還包括第二判斷模塊，用於判斷所述返回地址是否在正常的系統模塊中，所述正常的系統模塊包括具有合法籤名信息的DLL文件；若否，則判定檢測到漏洞。優選的，所述用於漏洞檢測的雲伺服器，還包括第三判斷模塊，用於獲取所述返回地址的內存屬性，判斷所述內存屬性是否包括可執行屬性，若否，則判定檢測到漏洞。與現有技術相比，本申請包括以下優點本申請實施例根據對漏洞攻擊進行主動防禦的理念，針對漏洞攻擊中Shellcode的執行所必須使用的系統函數進行InlineHook，通過對這些系統函數進行監控和檢測，根據所述函數的返回地址判斷是否有異常的調用行為，若是，則將其識別為利用漏洞發起攻擊的木馬，如網頁木馬，從而實現了對網頁木馬進行全面、有效的識別，提高用戶上網的安全性，並且無需用戶介入操作，提升了用戶體驗。圖I是本申請的ー種漏洞檢測的方法實施例I的步驟流程圖；圖2是本申請的ー種漏洞檢測的方法實施例2的步驟流程圖；圖3是本申請的ー種漏洞檢測的方法實施例3的步驟流程圖；圖4是本申請的ー種漏洞檢測的系統實施例的結構框圖。具體實施例方式為使本申請的上述目的、特徵和優點能夠更加明顯易懂，下面結合附圖和具體實施方式對本申請作進一步詳細的說明。針對安全漏洞的主動防禦是切斷木馬病毒傳播和感染電腦終端的主要途徑之一，通過對安全漏洞攻擊進行主動防禦，可以大大增強終端系統的安全特性，使黑客的攻擊操作變得更加困難。如在windows平臺上的漏洞在執行溢出攻擊時，溢出漏洞的Shellcode在執行時被安全軟體的主動防禦技術阻止攔截，那麼這次攻擊就會徹底失敗。其中，Shellcode實際是一段代碼(也可以是填充數據)，是用來發送到伺服器利用特定漏洞的代碼，一般可以獲取權限。另外，Shellcode—般是作為數據發送給受攻擊服務的。本申請實施例的核心構思之ー在於，基於上述針對漏洞攻擊進行主動防禦的理念，針對漏洞攻擊中Shellcode的執行所必須使用的系統函數進行InlineHook，通過對這些系統函數進行監控和檢測，根據所述函數的返回地址判斷是否有異常的調用行為，若是，則將其識別為利用漏洞發起攻擊的木馬，如網頁木馬。參照圖1，示出了本申請ー種漏洞檢測的方法實施例I的步驟流程圖，具體可以包括如下步驟步驟101、針對機器碼代碼執行所調用的函數進行鉤掛；在具體實現中，所述機器碼代碼為在腳本運行的由漏洞觸發的機器碼代碼Shellcode;所述鉤掛可以為內嵌鉤掛InlineHook操作。在這種情況下,所述步驟101可以為，針對在腳本運行的由漏洞觸發的Shellcode執行所調用的函數進行內嵌鉤掛InlineHook。在實際中，Shellcode可以是一段系統可以執行的代碼，是較底層的CPU執行的機器碼，一般用一段16進位字符串表示，通常用於緩衝區溢出漏洞利用中實現攻擊功能和攻擊行為的代碼。對於所述鉤掛Hook技術，以下以較為通用的windows系統為例進行說明通常，把攔截API(應用程式接ロ)的調用的這個過程稱為是安裝ー個API鉤子(APIHook)0ー個API鉤子至少有兩個模塊組成一個是鉤子伺服器(HookServer)模塊，一般為EXE的形式；一個是鉤子驅動器(HookDriver)模塊，一般為DLL的形式。伺服器主要負責向目標進程注入鉤子驅動器，使得驅動器工作在目標進程的地址空間中，這是關鍵的第一歩。驅動器則負責實際的API攔截工作，便API函數調用的前後能做ー些需要的工作。一個比較常見的API鉤子的例子就是ー些實時翻譯軟體(像金山詞霸)中必備的的功能屏幕抓詞，它主要是對ー些GDI函數進行了攔截，獲取它們的輸入參數中的字符串，然後在自己的窗口中顯示出來。針對上述的兩個部分，有以下兩點需要考慮的ー是選用何種DLL注入技木，ニ是採用何種API攔截機制。具體而言，注入技術的選用由於在Win32系統中各個進程的地址是互相獨立的，因此無法在一個進程中對另ー個進程的代碼進行有效的修改。而要完成API鉤子的工作就必須進行這種操作。因此，需要採取某種獨特的手段，使得API鉤子(準確的說是鉤子驅動器)能夠成為目標進程中的一部分，才有較大的可能來對目標進程數據和代碼進行有控制的修改。通常可以採用以下幾種進程注入方式進程注入方式I:利用註冊表如果準備攔截的進程連接了User32.dll,也就是使用了User32中的API(一般圖形界面的應用程式都符合這個條件)，那麼就可以簡單把鉤子驅動器DLL的名字作為值添加在下面註冊表的鍵下HKEY_L0CAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Windows\AppInit_DLLs,值的形式可以為單個DLL的文件名，或者是ー組DLL的文件名，相鄰的名稱之間用逗號或空格間隔。所有由該值標識的DLL將在符合條件的應用程式啟動的時候裝載。進程注入方式2建立系統範圍的Windows鉤子要向某個進程注入DLL,—個十分普遍也是比較簡單的方法就是建立在標準的Windows鉤子的基礎上。Windows鉤子一般是在DLL中實現的，這是一個全局性的Windows鉤子的基本要求。當成功地調用SetWindowsHookEx函數之後，便在系統中安裝了某種類型的消息鉤子，這個鉤子可以是針對某個進程，也可以是針對系統中的所有進程。一旦某個進程中產生了該類型的消息，作業系統會自動把該鉤子所在的DLL映像到該進程的地址空間中,從而使得消息回調函數(在SetWindowsHookEx的參數中指定)能夠對此消息進行適當的處理，在這裡，並不需要關注對消息進行什麼處理，因此在消息回調函數中只需把消息鉤子向後傳遞就可以了，但是所需的DLL已經成功地注入了目標進程的地址空間，從而可以完成後續工作。不同進程中使用的DLL之間是不能直接共享數據的，因為它們活動在不同的地址空間中。但在Windows鉤子DLL中，有一些數據，例如Windows鉤子句柄HHook,這是由SetWindowsHookEx函數返回值得到的，並且作為參數將在CalINextHookEx函數和UnhookWindoesHookEx函數中使用，顯然使用SetWindowsHookEx函數的進程和使用CallNextHookEx函數的進程一般不會是同一個進程，因此需要能夠使句柄在所有的地址空間中都是有效的有意義的，也就是說，它的值必須在這些鉤子DLL所掛鈎的進程之間是共享的。為了達到這個目的，可以把它存儲在一個共享的數據區域中。進程注入方式3使用CreateRemoteThread函數任何一個進程都可以使用LoadLibrary來動態地加載ー個DLL。但問題是，如何讓目標進程在我們的控制下來加載我們的鉤子DLL(也就是鉤子驅動器)呢？這裡有一個API函數CreateRemoteThread,通過它可在一個進程中可建立並運行ー個遠程的線程。調用該API需要指定一個線程函數指針作為參數，該線程函數的原型如下FunctionThreadProc(IpParamPointer):DWORD;再來看一下LoadLibrary的函數原型FunctionLoadLibrary(IpFileNamePChar):HModule;可以看出，這兩個函數原型實質上是完全相同的(其實返回值是否相同關係不大，因為無法得到遠程線程函數的返回值的)，只是叫法不同而已，這種相同可以直接把LoadLibrary當做線程函數來使用，從而在目標進程中加載鉤子DLL。進程注入方式4:通過BHO來注入DLL:當注入DLL的對象僅僅是InternetExplorer。可以利用BrowserHelperObjects(BHO)一個BHO是一個在DLL中實現的COM對象，它主要實現了ー個IObjectWithSite接ロ，而每當IE運行吋，它會自動加載所有實現了該接ロ的COM對象。攔截機制在鉤子應用的系統級別方面，有兩類API攔截的機制--內核級的攔截和用戶級的攔截。InlineHook主要涉及內核級的攔截。InlineHook是直接在以前的函數體裡面修改指令，用一個跳轉或者其他指令來達到掛鈎的目的。這是相對普通的hook來說，因為普通的hook只是修改函數的調用地址，而不是在原來的函數體裡面做修改。以下提供ー種InlineHook具體實現的示例I、Hook之前的準備工作之一假設在某個軟體中，總共hook了15個nativeAPI函數。分別是ZwOpenKey,ZwClose,ZwQueryValueKey,ZwDeleteKey,ZwSetValueKey,AwureateKey,ZwDeleteValueKey,ZwEnumerateValueKey,ZwRestoreKey,ZwReplaceKey,/,wTermmateProcess,/,WbetSecurityObject,ZwCreateThread,ZwTermmateThread,ZwQuerySystemInformationo這15個函數中，包括2個未公開的函數,ZwCreateThread,ZwTerminateThread,這兩個函數，需要從ntdll.dll的導出表中找到。另外,所有的nativeAPI函數的最終實現都是在ntoskrnl模塊中，所以，使用ZwQuerySystemInformation的OB號功能，找出ntoskrnl模塊的內存加載區間，然後逐個判斷ssdt表中這些要hook的函數地址，是否在這個區間內。2、Hook之前準備工作之ニI)ー個全局函數表，保存這15個要hook的函數的原始地址。這個表起始地址位於.data:00036860,終止於data0003689C共60位元組2)一個hook的函數地址表,分別對應於要hook的15個函數的跳轉。這個表起始地址位於data00034E98.data00034E98off—34E98ddoffsetsub—1EEA8.data00034E9Cddoffsetsub—1EE82.data00034EA0ddoffsetsub—1EF82.data00034EA4ddoffsetsub—1EF4A.data00034EA8ddoffsetsub—1EF6D.data00034EACddoffsetsub—IEECl.data00034EB0ddoffsetsub—1EED2.data00034EB4ddoffsetsub—1EEF5.data00034EB8ddoffsetsub—1EF31.data00034EBCddoffsetsub—1EF18.data00034EC0ddoffsetsub1EF93.data00034EC4ddoffsetsub—1EFA8data:00034EC8ddoffsetsub—IEFBD.data00034ECCddoffsetsub—1EFE6.data00034ED0ddoffsetsub—IEFFF這15個函數，都是在cdnprot.sys中實現的。3)一個用於保存函數開頭字節的ニ維數組數據區，數組形式是array[15][30]；15個函數，每個函數有30個字節可用。這30個字節中，首先保存原hook函數開頭字節，然後寫入0xe9，再寫入數組當前位置跟原hook函數地址偏移已複製出的字節碼後的位置之間的相對偏移值。(具體要保存原hook函數開頭多少字節，代碼中有ー個算法。)這個數組的作用是，當hook住了函數後，執行完hook函數之後，然後，需要恢復執行原API函數，由於原API函數開頭5位元組已經被改寫，由於函數原開頭字節已經保存到相應的數組裡，因此這裡的作法是，執行這個數組中的機器碼，數組機器碼執行到最後，會跳轉到原hook函數某個偏移位置，繼續執行。3、InlinehookI)IoAllocateMdl，分配ー個mdl，將要hook的函數映射進去；2)MmProbeAndLockPages，鎖定頁面；3)去掉防寫；4)保存函數開頭機器碼到對應的ニ維數組區，改寫開頭5個字節，讓其跳轉到起始地址位於.data00034E98的跳轉表中的對應跳轉函數；5)恢復防寫；6)MmUnlockPages；7)IoFreeMdl；4、Inlinehook後的恢復工作參見2步驟3)中的描述。對於本申請實施例而言，InlineHook的操作可以是將函數入口的前五個字節替換成自己的代碼，進入開發者自己的函數代碼中進行監控和檢測，在彙編指令中實際上是修改CALL指令的入口為JMP指令到其他的內存地址。當然，上述InlineHook的處理僅僅用作示例，本領域技術人員釆用任ー種方式對Shellcode執行所調用的函數進行InlineHook都是可行的，本申請實施例對此無需加以限制。在具體實現中，所述函數可以包括由CALL指令調用的下載進程的系統API函數和/或執行進程的系統API函數。其中，所述Call指令是專門用作函數調用的指令，它的作用是將當前的程序指針(EIP寄存器)值保存在棧中，然後轉移到目標操作數所指定的函數繼續執行。本申請實施例不僅可以用於保護瀏覽器程序，還能保護adobereader等支持javascript腳本引擎的第三方軟體，如惡意的PDF文件溢出漏洞。同時可以保護內嵌網頁瀏覽的第三方軟體，如迅雷中內嵌的網頁廣告被網頁木馬攻擊等。步驟102、獲得所述函數的返回地址；具體而言，調用指令CALL的基本功能就是將返回地址(即調用指令的下一條指令的地址)壓入堆棧，並轉向子程序的入口地址處。一般而言，函數入口的彙編指令是PushebpMovebp,esp通過ebp即可以獲得函數的返回地址，步驟103、依據所述返回地址檢測所述函數的入口指令是否為正常的CALL指令；若否，則執行步驟104;在具體實現中，所述正常的調用指令CALL是指滿足標準彙編指令OPCODE格式的調用指令CALL。也就是說，按照英特爾的指令標準文檔，CALL指令有規定的多種寫法，正常的CALL指令即指滿足規定寫法的CALL指令。步驟104、判定檢測到漏洞。本實施例針對漏洞攻擊中Shellcode的執行所需要使用的系統函數進行InlineHook,如針對winexec,shellexecute,createprocess等系統API函數進行監控和檢測，根據所述函數的返回地址回溯檢測函數入口指令是否正常，若不正常，則判定存在異常的調用行為，將其識別為利用漏洞發起攻擊的木馬，如網頁木馬，從而可以主動防禦各類漏洞攻擊，阻斷和攔截已知和未知的各種緩衝區溢出攻擊。在具體實現中，對於識別出的網頁木馬，可以採用任一種攔截技術進行阻斷和攔截，本領域技術人員根據實際情況任意選用相關攔截技術均可，本申請對此不作限制。參考圖2，示出了本申請的ー種漏洞檢測的方法實施例2的步驟流程圖，具體可以包括如下步驟步驟201、針對由漏洞觸發的Shellcode執行所調用的函數進行InlineHook；步驟202、獲得所述函數的返回地址；步驟203、依據所述返回地址檢測所述函數的入口指令是否為正常的CALL指令；若是，則執行步驟204;若否，則執行步驟205；其中，所述正常的系統模塊包括具有合法籤名信息的DLL文件。在實際中，正常的系統模塊一般是ー個DLL文件，文件會有微軟提供的籤名或第三方廠商提供的文件籤名，通過籤名算法可以驗證是否為正常的系統模塊。其中，DLL是DynamicLinkLibrary的縮寫，意為動態連結庫。DLL文件一般被存放在CWindowsSystemM下。DLL是一個包含可由多個程座同時使用的仕遇和數據的庫。步驟204，判斷所述返回地址是否在正常的系統模塊中；若否，則執行步驟205;若是，則執行步驟206；步驟205，判定檢測到漏洞；步驟206,判定為正常調用行為。本實施例相較於圖I所示的實施例而言，增加了判斷所述返回地址是否在正常的系統模塊中的處理步驟，在漏洞攻擊發生時，程序的執行流程會混亂，調用系統模塊中的函數的內存地址一般為不可執行代碼的堆棧地址，因而本實施例實質上是增加了基於函數的返回地址的堆棧檢測，以下對相關處理步驟具體說明。在具體實現中，CALL指令是專門用作函數調用的指令，它的作用是將當前的程序指針(EIP寄存器)值保存在棧中，然後轉移到目標操作數所指定的函數繼續執行。InlineHook一般是將函數入口的前五個字節替換成自己的代碼，進入開發者自己的函數代碼中進行監控和檢測，在彙編指令中實際上是修改CALL指令的入口為JMP指令到其他的內存地址。一般函數入口的彙編指令是PushebpMovebp,esp通過ebp可以找到函數的返回地址，通過對返回地址的內存地址和彙編指令的判定，可以判定返回地址是否在棧中執行，若在棧中執行，即表明所述返回地址在進程正常的系統模塊，若不在棧中執行，則表明所述返回地址未在進程正常的系統模塊內，在這種情況下，則判定存在異常的調用行為，將其識別為利用漏洞發起攻擊的木馬，如網頁木馬。需要說明的是，上述步驟204和步驟203可以同步執行，或者，所述步驟204也可以在步驟203之前執行，本領域技術人員根據實際情況任意設置執行次序均是可行的，本申請對此無需加以限制。本實施例針對漏洞攻擊中Shellcode的執行所需要使用的系統API函數(主要是下載函數，執行函數)進行InlineHook，通過對這些系統API函數進行監控和檢測，根據所述函數的返回地址回溯檢測函數入口指令是否正常，並判斷所述返回地址是否在進程正常的系統模塊中，若否，則判定存在異常的調用行為，將其識別為利用漏洞發起攻擊的木馬，如網頁木馬，從而可以主動防禦各類漏洞攻擊，阻斷和攔截已知和未知的各種緩衝區溢出攻擊。參考圖3，示出了本申請的一種漏洞檢測的方法實施例3的步驟流程圖，具體可以包括如下步驟步驟301、針對由漏洞觸發的Shellcode執行所調用的函數進行InlineHook；步驟302、獲得所述函數的返回地址；步驟303、依據所述返回地址檢測所述函數的入口指令是否為正常的CALL指令；若是，則執行步驟304;若否，則執行步驟306；步驟304，判斷所述返回地址是否在正常的系統模塊中；若否，則執行步驟306;若是，則執行步驟305；步驟305，獲取所述返回地址的內存屬性，判斷所述內存屬性是否包括可執行屬性，若是，則執行步驟307;若否，則執行步驟306；步驟306，判定檢測到漏洞；步驟307,判定為正常調用行為。本實施例相較於圖2所示的實施例而言，增加了判斷所述返回地址的內存屬性是否包括可執行屬性的處理步驟，其實質上是增加了基於函數的返回地址的內存屬性檢測，即在做返回地址檢查的時候檢測返回地址的內存屬性是否有可執行屬性。作為本申請實施例的一種示例，所述包括可執行屬性的內存屬性可以包括允許執行屬性PAGE_EXECUTE；允許執行和讀取屬性PAGE_EXECUTE_READ；允許讀寫和執行代碼屬性PAGE_EXECUTE_READWRITE；允許讀寫拷貝和執行代碼屬性PAGE_EXECUTE_WRITECOPY。需要說明的是，上述步驟303、304和305可以同步執行，或者，所述步驟304可以在步驟303前執行，或者，所述步驟305可以在步驟304前執行，本領域技術人員根據實際情況任意設置執行次序均是可行的，本申請對此無需加以限制。本實施例針對漏洞攻擊中Shellcode的執行所需要使用的系統API函數(主要是下載函數，執行函數)進行InlineHook，通過對這些系統API函數進行監控和檢測，根據所述函數的返回地址回溯檢測函數入口指令是否正常，並判斷所述返回地址是否在進程正常的系統模塊中，同時判斷所述返回地址的內存屬性是否包括可執行屬性，若否，則判定存在異常的調用行為，將其識別為利用漏洞發起攻擊的木馬，如網頁木馬，從而可以主動防禦各類漏洞攻擊，阻斷和攔截已知和未知的各種緩衝區溢出攻擊。為使本領域技術人員更好地理解本申請實施例，以下通過一個具體示例進一步說明。假設黑客針對CALL指令的劫持攻擊方法如下004071608038E8cmpbyteptr[eax],0E8call命令的開頭004071638038E9cmpbyteptr[eax],0E9jmp命令的開頭0040716675OFjnzshort00407177沒有被InlineHook,直接進去004071688178059090909cmpdwordptr[eax+5],90909090已被InlineHook,檢查5位元組後部分是否被nop了0040716F7406jeshort004071770040717155pushebp後面5位元組完好，則直接實現前面5位元組原代碼004071728BECmovebp,esp004071748D4005leaeax,dwordptr[eax+5]跳到5位元組之後執行00407177FFEOjmpeax一、採用本申請提供的CALL指令檢測方法，通過函數返回地址回溯檢測函數入口指令是否正常，具體可以採用以下代碼實現過程創建一個布爾類型的函數，函數名為CheckAfterCalllnstruction,聲明其參數為void類型，該函數功能為檢測函數返回地址是否正常的CALL指令；創建一個constunsignedchar類型的字符串變量；使用或條件使用CheckOpCode函數檢測地址的字節碼是否為標準的CALL指令；檢測機器碼16進位字符串是否為OxFF，0x15,CALL指令彙編代碼為CALLdwordptr[abs32]；檢測機器碼16進位字符串是否為OxFF，0x14,CALL指令彙編代碼為CALLdwordptr[REG*SCALE+BASE]；檢測機器碼16進位字符串是否為OxFF，0x10,CALL指令彙編代碼為CALLdwordptr[EAX]；檢測機器碼16進位字符串是否為OxFF，0x11,CALL指令彙編代碼為CALLdwordptr[ECX]；檢測機器碼16進位字符串是否為OxFF，0x12,CALL指令彙編代碼為CALLdwordptr[EDX]；檢測機器碼16進位字符串是否為OxFF，0x13,CALL指令彙編代碼為CALLdwordptr[EBX]"......校驗完上述N種CALL指令的寫法是否正常。如果檢測地址的指令非CALL指令，函數則返回flase。boolCheckOpCode(constunsignedchar*address,intbytes_before,constunsignedcharopcode,constunsignedcharopcode2,constchar*what)CheckOpCode函數第一個內存地址參數使用無符號字符參數,第二個字節參數使用整形參數，第三個字節碼參數使用無符號字符參數，第四個字節碼參數使用無符號字符參數，第五個參數為字符類型指針if(*(address_bytes_before)==opcode&&(opcode2==0|*(address_bytes_before+l)==opcode2))轉換內存地址指令為16進位度字符串和CALL指令彙編代碼兩個條件分別進行校驗。二、系統模塊返回地址檢測，檢測函數返回地址是否在正常的系統模塊內，具體可以採用以下代碼實現過程boolIsAllAddressInValidModule(void*retaddr[],intcount)創建一個布爾類型函數，第一個參數是無符號數組，第二個參數是整形參數；通過一個循環遍歷第一個參數的返回地址，與系統模塊中的函數地址和內存地址比對；如果匹配上，函數返回布爾真值。如果未匹配上，函數返回布爾假值，即該內存地址未落入系統模塊內存地址範圍。三、內存地址屬性檢測，檢測函數返回地址的內存屬性是否為可執行屬性，具體如以下代碼所示boolIsAddressExecutable(void*address)創建一個布爾類型函數，參數是無類型指針SIZE_Tret=VirtualQuery(address,&mbi,sizeof(mbi))；通過windowsapi函數VirtualQuery查詢地址的內存頁屬性。if((mbi.Protect&PAGE_EXECUTE)==PAGE_EXECUTE|(mbi.Protect&PAGE_EXECUTE_READ)==PAGE_EXECUTE_READ|(mbi.Protect&PAGE_EXECUTE_READWRITE)==PAGE_EXECUTE_READWRITE|(mbi.Protect&PAGE_EXECUTE_WRITEC0PY)==PAGE_EXECUTE_WRITEC0PY)加入頁面屬性等於可執行，等於可執行可讀，等於可執行可讀可寫，等於可執行可寫可拷貝，函數返回布爾真值。如果不屬於四種情況，函數返回布爾假值，即該內存地址存在不可執行代碼的異常地址。需要說明的是，對於方法實施例，為了簡單描述，故將其都表述為一系列的動作組合，但是本領域技術人員應該知悉，本申請並不受所描述的動作順序的限制，因為依據本申請，某些步驟可以採用其他順序或者同時進行。其次，本領域技術人員也應該知悉，說明書中所描述的實施例均屬於優選實施例，所涉及的動作和模塊並不一定是本申請所必須的。參考圖4，示出了本申請的一種漏洞檢測的系統實施例的結構框圖，具體可以包括如下模塊鉤掛模塊401，用於針對機器碼代碼執行所調用的函數進行鉤掛；返回地址獲得模塊402，用於獲得所述函數的返回地址；第一判斷模塊403，用於依據所述返回地址檢測所述函數的入口指令是否為正常的CALL指令；若否，則判定檢測到漏洞。在具體實現中，所述機器碼代碼為在腳本運行的由漏洞觸發的機器碼代碼Shellcode;所述鉤掛包括內嵌鉤掛InlineHook操作。所述函數包括由調用指令CALL調用的下載進程的系統API函數和/或執行進程的系統API函數；所述正常的調用指令CALL為滿足標準彙編指令OPCODE格式的CALL指令。在本申請的一種優選實施例中，所述系統還可以包括如下模塊第二判斷模塊404，用於判斷所述返回地址是否在進程正常的系統模塊中，所述正常的系統模塊包括具有合法籤名信息的DLL文件；若否，則判定檢測到漏洞。和/或，第三判斷模塊405，用於獲取所述返回地址的內存屬性，判斷所述內存屬性是否包括可執行屬性，若否，則判定檢測到漏洞。其中，所述包括可執行屬性的內存屬性可以包括允許執行屬性PAGE_EXECUTE；允許執行和讀取屬性PAGE_EXECUTE_READ；允許讀寫和執行代碼屬性PAGE_EXECUTE_READWRITE；允許讀寫拷貝和執行代碼屬性PAGE_EXECUTE_WRITECOPY。對於系統實施例而言，由於其與方法實施例基本相似，所以描述的比較簡單，相關之處參見方法實施例的部分說明即可。上述系統實施例可以設置在客戶端，即在本申請的一種優選實施例中，還提供了一種用於漏洞檢測的客戶端，具體可以包括如下模塊鉤掛模塊，用於針對機器碼代碼執行所調用的函數進行鉤掛；返回地址獲得模塊，用於獲得所述函數的返回地址；第一判斷模塊，用於依據所述返回地址檢測所述函數的入口指令是否為正常的調用指令CALL;若否，則判定檢測到漏洞。優選的是，所述用於漏洞檢測的客戶端，還可以包括如下模塊第二判斷模塊，用於判斷所述返回地址是否在正常的系統模塊中，所述正常的系統模塊包括具有合法籤名信息的DLL文件；若否，則判定檢測到漏洞。優選的是，所述用於漏洞檢測的客戶端，還可以包括如下模塊第三判斷模塊，用於獲取所述返回地址的內存屬性，判斷所述內存屬性是否包括可執行屬性，若否，則判定檢測到漏洞。應用本實施例，可以有效保護瀏覽器和帶有網頁瀏覽功能的第三方軟體。上述系統實施例可以設置在雲端，即在本申請的一種優選實施例中，還提供了一種用於漏洞檢測的雲伺服器，具體可以包括如下模塊鉤掛模塊，用於針對機器碼代碼執行所調用的函數進行鉤掛；返回地址獲得模塊，用於獲得所述函數的返回地址；第一判斷模塊，用於依據所述返回地址檢測所述函數的入口指令是否為正常的調用指令CALL;若否，則判定檢測到漏洞。優選的是，所述用於漏洞檢測的雲伺服器，還可以包括如下模塊第二判斷模塊，用於判斷所述返回地址是否在正常的系統模塊中，所述正常的系統模塊包括具有合法籤名信息的DLL文件；若否，則判定檢測到漏洞。優選的是，所述用於漏洞檢測的雲伺服器，還可以包括如下模塊第三判斷模塊，用於獲取所述返回地址的內存屬性，判斷所述內存屬性是否包括可執行屬性，若否，則判定檢測到漏洞。應用本實施例，可以採用雲查殺的方式對漏洞進行主動防禦。本說明書中的各個實施例均採用遞進的方式描述，每個實施例重點說明的都是與其他實施例的不同之處，各個實施例之間相同相似的部分互相參見即可。本申請可用於眾多通用或專用的計算系統環境或配置中。例如個人計算機、伺服器計算機、手持設備或可攜式設備、平板型設備、多處理器系統、基於微處理器的系統、置頂盒、可編程的消費電子設備、網絡PC、小型計算機、大型計算機、包括以上任何系統或設備的分布式計算環境等等。本申請可以在由計算機執行的計算機可執行指令的一般上下文中描述，例如程序模塊。一般地，程序模塊包括執行特定任務或實現特定抽象數據類型的例程、程序、對象、組件、數據結構等等。也可以在分布式計算環境中實踐本申請，在這些分布式計算環境中，由通過通信網絡而被連接的遠程處理設備來執行任務。在分布式計算環境中，程序模塊可以位於包括存儲設備在內的本地和遠程計算機存儲介質中。最後，還需要說明的是，在本文中，諸如第一和第二等之類的關係術語僅僅用來將一個實體或者操作與另一個實體或操作區分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關係或者順序。而且，術語「包括」、「包含」或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設備所固有的要素。在沒有更多限制的情況下，由語句「包括一個......」限定的要素，並不排除在包括所述要素的過程、方法、物品或者設備中還存在另外的相同要素。以上對本申請所提供的一種漏洞檢測的方法和一種漏洞檢測的系統進行了詳細介紹，本文中應用了具體個例對本申請的原理及實施方式進行了闡述，以上實施例的說明只是用於幫助理解本申請的方法及其核心思想；同時，對於本領域的一般技術人員，依據本申請的思想，在具體實施方式及應用範圍上均會有改變之處，綜上所述，本說明書內容不應理解為對本申請的限制。權利要求1.一種漏洞檢測的方法，其特徵在於，包括針對機器碼代碼執行所調用的函數進行鉤掛；獲得所述函數的返回地址；依據所述返回地址檢測所述函數的入口指令是否為正常的調用指令CALL;若否，則判定檢測到漏洞。2.根據權利要求I所述的方法，其特徵在於，所述機器碼代碼為在腳本運行的由漏洞觸發的機器碼代碼Shellcode;所述鉤掛包括內嵌鉤掛InlineHook操作。3.根據權利要求I或2所述的方法，其特徵在於，還包括判斷所述返回地址是否在正常的系統模塊中，所述正常的系統模塊包括具有合法籤名信息的DLL文件；若否，則判定檢測到漏洞。4.根據權利要求I或2所述的方法，其特徵在於，還包括獲取所述返回地址的內存屬性，判斷所述內存屬性是否包括可執行屬性；若否，則判定檢測到漏洞。5.根據權利要求4所述的方法，其特徵在於，所述包括可執行屬性的內存屬性包括允許執行屬性PAGE_EXECUTE；允許執行和讀取屬性PAGE_EXECUTE_READ；允許讀寫和執行代碼屬性PAGE_EXECUTE_READWRITE；允許讀寫拷貝和執行代碼屬性PAGE_EXECUTE_WRITECOPY。6.根據權利要求1、2或5所述的方法，其特徵在於，所述函數包括由調用指令CALL調用的下載進程的系統API函數和/或執行進程的系統API函數。7.根據權利要求6所述的方法，其特徵在於，所述正常的調用指令CALL為滿足標準彙編指令OPCODE格式的調用指令CALL。8.ー種漏洞檢測的系統，其特徵在於，包括鉤掛模塊，用於針對機器碼代碼執行所調用的函數進行鉤掛；返回地址獲得模塊，用於獲得所述函數的返回地址；第一判斷模塊，用於依據所述返回地址檢測所述函數的入口指令是否為正常的調用指令CALL;若否，則判定檢測到漏洞。9.根據權利要求8所述的系統，其特徵在於，所述機器碼代碼為在腳本運行的由漏洞觸發的機器碼代碼Shellcode;所述鉤掛包括內嵌鉤掛InlineHook操作。10.根據權利要求8或9所述的系統，其特徵在於，還包括第二判斷模塊，用於判斷所述返回地址是否在正常的系統模塊中，所述正常的系統模塊包括具有合法籤名信息的DLL文件；若否，則判定檢測到漏洞。11.根據權利要求8或9所述的系統，其特徵在於，還包括第三判斷模塊，用於獲取所述返回地址的內存屬性，判斷所述內存屬性是否包括可執行屬性，若否，則判定檢測到漏洞。12.根據權利要求11所述的系統，其特徵在於，所述包括可執行屬性的內存屬性包括允許執行屬性PAGE_EXECUTE；允許執行和讀取屬性PAGE_EXECUTE_READ；允許讀寫和執行代碼屬性PAGE_EXECUTE_READWRITE；允許讀寫拷貝和執行代碼屬性PAGE_EXECUTE_WRITECOPY。13.根據權利要求8、9或12所述的系統，其特徵在於，所述函數包括由調用指令CALL調用的下載進程的系統API函數和/或執行進程的系統API函數。14.根據權利要求13所述的系統，其特徵在於，所述正常的調用指令CALL為滿足標準彙編指令OPCODE格式的調用指令CALL。15.一種用於漏洞檢測的客戶端，其特徵在於，包括鉤掛模塊，用於針對機器碼代碼執行所調用的函數進行鉤桂；返回地址獲得模塊，用於獲得所述函數的返回地址；第一判斷模塊，用於依據所述返回地址檢測所述函數的入口指令是否為正常的調用指令CALL;若否，則判定檢測到漏洞。16.根據權利要求15所述用於漏洞檢測的客戶端，其特徵在於，還包括第二判斷模塊，用於判斷所述返回地址是否在正常的系統模塊中，所述正常的系統模塊包括具有合法籤名信息的DLL文件；若否，則判定檢測到漏洞。17.根據權利要求15或16所述用於漏洞檢測的客戶端，其特徵在於，還包括第三判斷模塊，用於獲取所述返回地址的內存屬性，判斷所述內存屬性是否包括可執行屬性，若否，則判定檢測到漏洞。18.一種用於漏洞檢測的雲伺服器，其特徵在於，包括鉤掛模塊，用於針對機器碼代碼執行所調用的函數進行鉤桂；返回地址獲得模塊，用於獲得所述函數的返回地址；第一判斷模塊，用於依據所述返回地址檢測所述函數的入口指令是否為正常的調用指令CALL;若否，則判定檢測到漏洞。19.根據權利要求18所述用於漏洞檢測的雲伺服器，其特徵在於，還包括第二判斷模塊，用於判斷所述返回地址是否在正常的系統模塊中，所述正常的系統模塊包括具有合法籤名信息的DLL文件；若否，則判定檢測到漏洞。20.根據權利要求18或19所述用於漏洞檢測的雲伺服器，其特徵在於，還包括第三判斷模塊，用於獲取所述返回地址的內存屬性，判斷所述內存屬性是否包括可執行屬性，若否，則判定檢測到漏洞。全文摘要本申請提供了一種漏洞檢測的方法及系統，其中所述方法包括針對機器碼代碼執行所調用的函數進行鉤掛；獲得所述函數的返回地址；依據所述返回地址檢測所述函數的入口指令是否為正常的調用指令CALL；若否，則判定檢測到漏洞。本申請可以對造成網頁木馬等安全問題的漏洞進行全面、有效的識別，提高用戶上網的安全性。文檔編號G06F21/22GK102651060SQ20121009375公開日2012年8月29日申請日期2012年3月31日優先權日2012年3月31日發明者劉起,宋申雷,張聰,肖鵬申請人:北京奇虎科技有限公司