CN102651060A - 一种漏洞检测的方法和系统 - Google Patents

Abstract

本申请提供了一种漏洞检测的方法及系统，其中所述方法包括：针对机器码代码执行所调用的函数进行钩挂；获得所述函数的返回地址；依据所述返回地址检测所述函数的入口指令是否为正常的调用指令CALL；若否，则判定检测到漏洞。本申请可以对造成网页木马等安全问题的漏洞进行全面、有效的识别，提高用户上网的安全性。

Description

一种漏洞检测的方法和系统

技术领域

本申请涉及信息安全的技术领域，特别是涉及一种漏洞检测的方法，一种漏洞检测的系统，一种用于漏洞检测的客户端，以及，一种用于漏洞检测的云服务器。

背景技术

公知的是，漏洞带来的最大问题即是木马，木马通常会利用计算机程序漏洞侵入后窃取文件和用户信息。木马是一种具有隐藏性的、自发性的可被用来进行恶意行为的程序。历史上对计算机木马的定义是，试图以有用程序的假面具欺骗用户允许其运行的一类渗透。请注意，过去的木马确实是这样，但现在它们已无需伪装自己。它们唯一的目的就是尽可能轻松地渗透并完成其恶意目标。“木马”已成为一个通用词，用来形容不属于任何特定类别的所有渗透。

木马技术发展至今，最为常见的就是网页木马，网页木马是网页恶意软件威胁的罪魁祸首，它表面上伪装成普通的网页文件或是将恶意的代码直接插入到正常的网页文件中，当有人访问时，网页木马就会利用对方系统或者浏览器的漏洞自动将配置好的木马的服务端下载到访问者的电脑上来自动执行。网页木马的实质是利用漏洞向用户传播木马下载器，准确地说，网页木马并不是木马程序，而应该称为网页木马“种植器”，也即一种通过攻击浏览器或浏览器外挂程序(目标通常是IE浏览器和ActiveX程序)的漏洞，向目标用户机器植入木马、病毒、密码盗取等恶意程序的手段。

网页木马实际上是一个HTML网页，与其它网页不同的是该网页是黑客精心制作的，用户一旦访问了该网页就会中木马。为什么说是黑客精心制作的呢？因为嵌入在这个网页中的脚本恰如其分地利用了IE浏览器的漏洞，让IE在后台自动下载黑客放置在网络上的木马并运行(安装)这个木马，也就是说，这个网页能下载木马到本地并运行(安装)下载到本地电脑上的木马，整个过程都在后台运行，用户一旦打开这个网页，下载过程和运行(安装)过程就自动开始。

网页木马的防范只靠杀毒软件和防火墙是远远不够的，因为一旦黑客使用了反弹端口的个人版木马(个人反汇编的一些杀毒软件无法识别的木马)，那么杀毒软件和防火墙就无可奈何，所以，现有技术中，网页木马的防范一般采用如下方式进行：

一、及时安装安全补丁；

这种打补丁的方式显然受到系统服务商推出补丁的限制，并不能很好的全面防范网页木马。

二、改名或卸载(反注册)最不安全的ActiveXObject(IE插件)：

在系统中有些ActiveXObject会运行EXE程序，比如“自动运行程序”代码中的Shell.application控件，这些控件一旦在网页中获得了执行权限，那么它就会变为木马运行的“温床”，所以把这些控件改名或卸载能彻底防范利用这些控件的网页木马。但是ActiveXObject是为了应用而出现的，而不是为了攻击而出现的，所有的控件都有它的用处，所以在改名或卸载一个控件之前，必须确认这个控件是不需要的，或者即使卸载了也不关大体的，但实际上用户对此很难保证。

三、提高IE的安全级别，禁用脚本和ActiveX控件：

有些网马只要调高IE的安全级别，或者禁用脚本，该网页木马就不起作用了。从木马的攻击原理可以看出，网页木马是利用IE脚本和ActiveX控件上的一些漏洞下载和运行木马的，只要我们禁用了脚本和ActiveX控件，就可以防止木马的下载和运行。然而，禁用脚本和ActiveX控件会使一些网页的功能和效果失去作用。

显然，上述现有技术受到各种各样的条件限制，完全无法对网页木马进行全面、有效的识别。

因此，目前需要本领域技术人员迫切解决的一个技术问题就是：提出一种全新的漏洞检测的机制，用以对造成网页木马等安全问题的漏洞进行全面、有效的识别，提高用户上网的安全性。

发明内容

本申请所要解决的技术问题是提供一种漏洞检测的方法和系统，用以对造成网页木马等安全问题的漏洞进行全面、有效的识别，提高用户上网的安全性。

为了解决上述问题，本申请公开了一种漏洞检测的方法，包括：

针对机器码代码执行所调用的函数进行钩挂；

获得所述函数的返回地址；

依据所述返回地址检测所述函数的入口指令是否为正常的调用指令CALL；若否，则判定检测到漏洞。

优选的，所述机器码代码为在脚本运行的由漏洞触发的机器码代码Shellcode；所述钩挂包括内嵌钩挂Inline Hook操作。

优选的，所述的方法，还包括：

判断所述返回地址是否在正常的系统模块中，所述正常的系统模块包括具有合法签名信息的DLL文件；

若否，则判定检测到漏洞。

优选的，所述的方法还包括：

获取所述返回地址的内存属性，判断所述内存属性是否包括可执行属性；

若否，则判定检测到漏洞。

优选的，所述包括可执行属性的内存属性包括：

允许执行属性PAGE_EXECUTE；

允许执行和读取属性PAGE_EXECUTE_READ；

允许读写和执行代码属性PAGE_EXECUTE_READWRITE；

允许读写拷贝和执行代码属性PAGE_EXECUTE_WRITECOPY。

优选的，所述函数包括由调用指令CALL调用的下载进程的系统API函数和/或执行进程的系统API函数。

优选的，所述正常的调用指令CALL为满足标准汇编指令OPCODE格式的调用指令CALL。

本申请实施例还公开了一种漏洞检测的系统，包括：

钩挂模块，用于针对机器码代码执行所调用的函数进行钩挂；

返回地址获得模块，用于获得所述函数的返回地址；

第一判断模块，用于依据所述返回地址检测所述函数的入口指令是否为正常的调用指令CALL；若否，则判定检测到漏洞。

优选的，所述机器码代码为在脚本运行的由漏洞触发的机器码代码Shellcode；所述钩挂包括内嵌钩挂Inline Hook操作。

优选的，所述的系统还包括：

第二判断模块，用于判断所述返回地址是否在正常的系统模块中，所述正常的系统模块包括具有合法签名信息的DLL文件；若否，则判定检测到漏洞。

优选的，所述的系统还包括：

第三判断模块，用于获取所述返回地址的内存属性，判断所述内存属性是否包括可执行属性，若否，则判定检测到漏洞。

优选的，所述包括可执行属性的内存属性包括：

允许执行属性PAGE_EXECUTE；

允许执行和读取属性PAGE_EXECUTE_READ；

允许读写和执行代码属性PAGE_EXECUTE_READWRITE；

允许读写拷贝和执行代码属性PAGE_EXECUTE_WRITECOPY。

优选的，所述函数包括由调用指令CALL调用的下载进程的系统API函数和/或执行进程的系统API函数。

优选的，所述正常的调用指令CALL为满足标准汇编指令OPCODE格式的调用指令CALL。

本申请实施例还公开了一种用于漏洞检测的客户端，包括：

钩挂模块，用于针对机器码代码执行所调用的函数进行钩挂；

返回地址获得模块，用于获得所述函数的返回地址；

第一判断模块，用于依据所述返回地址检测所述函数的入口指令是否为正常的调用指令CALL；若否，则判定检测到漏洞。

优选的，所述用于漏洞检测的客户端，还包括：

第二判断模块，用于判断所述返回地址是否在正常的系统模块中，所述正常的系统模块包括具有合法签名信息的DLL文件；若否，则判定检测到漏洞。

优选的，所述用于漏洞检测的客户端，还包括：

第三判断模块，用于获取所述返回地址的内存属性，判断所述内存属性是否包括可执行属性，若否，则判定检测到漏洞。

本申请实施例还公开了一种用于漏洞检测的云服务器，包括：

钩挂模块，用于针对机器码代码执行所调用的函数进行钩挂；

返回地址获得模块，用于获得所述函数的返回地址；

第一判断模块，用于依据所述返回地址检测所述函数的入口指令是否为正常的调用指令CALL；若否，则判定检测到漏洞。

优选的，所述用于漏洞检测的云服务器，还包括：

第二判断模块，用于判断所述返回地址是否在正常的系统模块中，所述正常的系统模块包括具有合法签名信息的DLL文件；若否，则判定检测到漏洞。

优选的，所述用于漏洞检测的云服务器，还包括：

第三判断模块，用于获取所述返回地址的内存属性，判断所述内存属性是否包括可执行属性，若否，则判定检测到漏洞。

与现有技术相比，本申请包括以下优点：

本申请实施例根据对漏洞攻击进行主动防御的理念，针对漏洞攻击中Shellcode的执行所必须使用的系统函数进行Inline Hook，通过对这些系统函数进行监控和检测，根据所述函数的返回地址判断是否有异常的调用行为，若是，则将其识别为利用漏洞发起攻击的木马，如网页木马，从而实现了对网页木马进行全面、有效的识别，提高用户上网的安全性，并且无需用户介入操作，提升了用户体验。

附图说明

图1是本申请的一种漏洞检测的方法实施例1的步骤流程图；

图2是本申请的一种漏洞检测的方法实施例2的步骤流程图；

图3是本申请的一种漏洞检测的方法实施例3的步骤流程图；

图4是本申请的一种漏洞检测的系统实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

针对安全漏洞的主动防御是切断木马病毒传播和感染电脑终端的主要途径之一，通过对安全漏洞攻击进行主动防御，可以大大增强终端系统的安全特性，使黑客的攻击操作变得更加困难。如在windows平台上的漏洞在执行溢出攻击时，溢出漏洞的Shellcode在执行时被安全软件的主动防御技术阻止拦截，那么这次攻击就会彻底失败。

其中，Shellcode实际是一段代码(也可以是填充数据)，是用来发送到服务器利用特定漏洞的代码，一般可以获取权限。另外，Shellcode一般是作为数据发送给受攻击服务的。

本申请实施例的核心构思之一在于，基于上述针对漏洞攻击进行主动防御的理念，针对漏洞攻击中Shellcode的执行所必须使用的系统函数进行Inline Hook，通过对这些系统函数进行监控和检测，根据所述函数的返回地址判断是否有异常的调用行为，若是，则将其识别为利用漏洞发起攻击的木马，如网页木马。

参照图1，示出了本申请一种漏洞检测的方法实施例1的步骤流程图，具体可以包括如下步骤：

步骤101、针对机器码代码执行所调用的函数进行钩挂；

在具体实现中，所述机器码代码为在脚本运行的由漏洞触发的机器码代码Shellcode；所述钩挂可以为内嵌钩挂Inline Hook操作。在这种情况下，所述步骤101可以为，针对在脚本运行的由漏洞触发的Shellcode执行所调用的函数进行内嵌钩挂Inline Hook。

在实际中，Shellcode可以是一段系统可以执行的代码，是较底层的CPU执行的机器码，一般用一段16进制字符串表示，通常用于缓冲区溢出漏洞利用中实现攻击功能和攻击行为的代码。

对于所述钩挂Hook技术，以下以较为通用的windows系统为例进行说明：

通常，把拦截API(应用程序接口)的调用的这个过程称为是安装一个API钩子(API Hook)。一个API钩子至少有两个模块组成：一个是钩子服务器(Hook Server)模块，一般为EXE的形式；一个是钩子驱动器(Hook Driver)模块，一般为DLL的形式。

服务器主要负责向目标进程注入钩子驱动器，使得驱动器工作在目标进程的地址空间中，这是关键的第一步。驱动器则负责实际的API拦截工作，便API函数调用的前后能做一些需要的工作。一个比较常见的API钩子的例子就是一些实时翻译软件(像金山词霸)中必备的的功能：屏幕抓词，它主要是对一些GDI函数进行了拦截，获取它们的输入参数中的字符串，然后在自己的窗口中显示出来。针对上述的两个部分，有以下两点需要考虑的：一是选用何种DLL注入技术，二是采用何种API拦截机制。

具体而言，注入技术的选用由于在Win32系统中各个进程的地址是互相独立的，因此无法在一个进程中对另一个进程的代码进行有效的修改。而要完成API钩子的工作就必须进行这种操作。因此，需要采取某种独特的手段，使得API钩子(准确的说是钩子驱动器)能够成为目标进程中的一部分，才有较大的可能来对目标进程数据和代码进行有控制的修改。

通常可以采用以下几种进程注入方式：

进程注入方式1：

利用注册表：如果准备拦截的进程连接了User32.dll，也就是使用了User32中的API(一般图形界面的应用程序都符合这个条件)，那么就可以简单把钩子驱动器DLL的名字作为值添加在下面注册表的键下：HKEY_LOCAL_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函数返回值得到的，并且作为参数将在CallNextHookEx函数和UnhookWindoesHookEx函数中使用，显然使用SetWindowsHookEx函数的进程和使用CallNextHookEx函数的进程一般不会是同一个进程，因此需要能够使句柄在所有的地址空间中都是有效的有意义的，也就是说，它的值必须在这些钩子DLL所挂钩的进程之间是共享的。为了达到这个目的，可以把它存储在一个共享的数据区域中。

进程注入方式3：

使用CreateRemoteThread函数：任何一个进程都可以使用LoadLibrary来动态地加载一个DLL。但问题是，如何让目标进程在我们的控制下来加载我们的钩子DLL(也就是钩子驱动器)呢？这里有一个API函数CreateRemoteThread，通过它可在一个进程中可建立并运行一个远程的线程。调用该API需要指定一个线程函数指针作为参数，该线程函数的原型如下：Function ThreadProc(lpParam：Pointer)：DWORD；再来看一下LoadLibrary的函数原型：Function LoadLibrary(lpFileName：PChar)：HModule；可以看出，这两个函数原型实质上是完全相同的(其实返回值是否相同关系不大，因为无法得到远程线程函数的返回值的)，只是叫法不同而已，这种相同可以直接把LoadLibrary当做线程函数来使用，从而在目标进程中加载钩子DLL。

进程注入方式4：

通过BHO来注入DLL：当注入DLL的对象仅仅是Internet Explorer。可以利用Browser Helper Objects(BHO)。一个BHO是一个在DLL中实现的COM对象，它主要实现了一个IObjectWithSite接口，而每当IE运行时，它会自动加载所有实现了该接口的COM对象。

拦截机制在钩子应用的系统级别方面，有两类API拦截的机制--内核级的拦截和用户级的拦截。Inline Hook主要涉及内核级的拦截。InlineHook  是直接在以前的函数体里面修改指令，用一个跳转或者其他指令来达到挂钩的目的。这是相对普通的hook来说，因为普通的hook只是修改函数的调用地址，而不是在原来的函数体里面做修改。以下提供一种Inline Hook具体实现的示例：

1、Hook之前的准备工作之一：

假设在某个软件中，总共hook了15个native API函数。分别是：

ZwOpenKey，ZwClose，ZwQueryValueKey，ZwDeleteKey，ZwSetValueKey，ZwCreateKey，ZwDeleteValueKey，ZwEnumerateValueKey，ZwRestoreKey，ZwReplaceKey，ZwTerminateProcess，ZwSetSecurityObject，ZwCreateThread，ZwTerminateThread，ZwQuerySystemInformation。

这15个函数中，包括2个未公开的函数，ZwCreateThread，ZwTerminateThread，这两个函数，需要从ntdll.dll的导出表中找到。另外，所有的native API函数的最终实现都是在ntoskrnl模块中，所以，使用ZwQuerySystemInformation的0B号功能，找出ntoskrnl模块的内存加载区间，然后逐个判断ssdt表中这些要hook的函数地址，是否在这个区间内。

2、Hook之前准备工作之二：

1)一个全局函数表，保存这15个要hook的函数的原始地址。

这个表起始地址位于：.data：00036860，终止于：data：0003689C共60字节

2)一个hook的函数地址表，分别对应于要hook的15个函数的跳转。

这个表起始地址位于：.data：00034E98

.data：00034E98 off_34E98     dd offset sub_1EEA8

.data：00034E9C               dd offset sub_1EE82

.data：00034EA0               dd offset sub_1EF82

.data：00034EA4               dd offset sub_1EF4A

.data：00034EA8               dd offset sub_1EF6D

.data：00034EAC               dd offset sub_1EECl

.data：00034EB0               dd offset sub_1EED2

.data：00034EB4               dd offset sub_1EEF5

.data：00034EB8               dd offset sub_1EF31

.data：00034EBC               dd offset sub_1EF18

.data：00034EC0        dd offset sub 1EF93

.data：00034EC4        dd offset sub_1EFA8

.data：00034EC8        dd offset sub_1EFBD

.data：00034ECC        dd offset sub_1EFE6

.data：00034ED0        dd offset sub_1EFFF

这15个函数，都是在cdnprot.sys中实现的。

3)一个用于保存函数开头字节的二维数组数据区，数组形式是array[15][30]；

15个函数，每个函数有30个字节可用。这30个字节中，首先保存原hook函数开头字节，然后写入0xe9，再写入数组当前位置跟原hook函数地址偏移已复制出的字节码后的位置之间的相对偏移值。(具体要保存原hook函数开头多少字节，代码中有一个算法。)

这个数组的作用是，当hook住了函数后，执行完hook函数之后，然后，需要恢复执行原API函数，由于原API函数开头5字节已经被改写，由于函数原开头字节已经保存到相应的数组里，因此这里的作法是，执行这个数组中的机器码，数组机器码执行到最后，会跳转到原hook函数某个偏移位置，继续执行。

3、Inline hook：

1)IoAllocateMdl，分配一个mdl，将要hook的函数映射进去；

2)MmProbeAndLockPages，锁定页面；

3)去掉写保护；

4)保存函数开头机器码到对应的二维数组区，改写开头5个字节，让其跳转到起始地址位于.data：00034E98的跳转表中的对应跳转函数；

5)恢复写保护；

6)MmUnlockPages；

7)IoFreeMdl；

4、Inline hook后的恢复工作：

参见2步骤3)中的描述。

对于本申请实施例而言，Inline Hook的操作可以是将函数入口的前五个字节替换成自己的代码，进入开发者自己的函数代码中进行监控和检测，在汇编指令中实际上是修改CALL指令的入口为JMP指令到其他的内存地址。

当然，上述Inline Hook的处理仅仅用作示例，本领域技术人员采用任一种方式对Shellcode执行所调用的函数进行Inline Hook都是可行的，本申请实施例对此无需加以限制。

在具体实现中，所述函数可以包括由CALL指令调用的下载进程的系统API函数和/或执行进程的系统API函数。其中，所述Call指令是专门用作函数调用的指令，它的作用是将当前的程序指针(EIP寄存器)值保存在栈中，然后转移到目标操作数所指定的函数继续执行。

本申请实施例不仅可以用于保护浏览器程序，还能保护adobe reader等支持javascript脚本引擎的第三方软件，如恶意的PDF文件溢出漏洞。同时可以保护内嵌网页浏览的第三方软件，如迅雷中内嵌的网页广告被网页木马攻击等。

步骤102、获得所述函数的返回地址；

具体而言，调用指令CALL的基本功能就是将返回地址(即调用指令的下一条指令的地址)压入堆栈，并转向子程序的入口地址处。

一般而言，函数入口的汇编指令是：

Push ebp

Mov ebp，esp

通过ebp即可以获得函数的返回地址，

步骤103、依据所述返回地址检测所述函数的入口指令是否为正常的CALL指令；若否，则执行步骤104；

在具体实现中，所述正常的调用指令CALL是指满足标准汇编指令OPCODE格式的调用指令CALL。也就是说，按照英特尔的指令标准文档，CALL指令有规定的多种写法，正常的CALL指令即指满足规定写法的CALL指令。

步骤104、判定检测到漏洞。

本实施例针对漏洞攻击中Shellcode的执行所需要使用的系统函数进行Inline Hook，如针对winexec，shellexecute，createprocess等系统API函数进行监控和检测，根据所述函数的返回地址回溯检测函数入口指令是否正常，若不正常，则判定存在异常的调用行为，将其识别为利用漏洞发起攻击的木马，如网页木马，从而可以主动防御各类漏洞攻击，阻断和拦截已知和未知的各种缓冲区溢出攻击。

在具体实现中，对于识别出的网页木马，可以采用任一种拦截技术进行阻断和拦截，本领域技术人员根据实际情况任意选用相关拦截技术均可，本申请对此不作限制。

参考图2，示出了本申请的一种漏洞检测的方法实施例2的步骤流程图，具体可以包括如下步骤：

步骤201、针对由漏洞触发的Shellcode执行所调用的函数进行InlineHook；

步骤202、获得所述函数的返回地址；

步骤203、依据所述返回地址检测所述函数的入口指令是否为正常的CALL指令；若是，则执行步骤204；若否，则执行步骤205；

其中，所述正常的系统模块包括具有合法签名信息的DLL文件。

在实际中，正常的系统模块一般是一个DLL文件，文件会有微软提供的签名或第三方厂商提供的文件签名，通过签名算法可以验证是否为正常的系统模块。其中，DLL是Dynamic Link Library的缩写，意为动态链接库。DLL文件一般被存放在C：WindowsSystem目录下。DLL是一个包含可由多个程序同时使用的代码和数据的库。

步骤204，判断所述返回地址是否在正常的系统模块中；若否，则执行步骤205；若是，则执行步骤206；

步骤205，判定检测到漏洞；

步骤206，判定为正常调用行为。

本实施例相较于图1所示的实施例而言，增加了判断所述返回地址是否在正常的系统模块中的处理步骤，在漏洞攻击发生时，程序的执行流程会混乱，调用系统模块中的函数的内存地址一般为不可执行代码的堆栈地址，因而本实施例实质上是增加了基于函数的返回地址的堆栈检测，以下对相关处理步骤具体说明。

在具体实现中，CALL指令是专门用作函数调用的指令，它的作用是将当前的程序指针(EIP寄存器)值保存在栈中，然后转移到目标操作数所指定的函数继续执行。Inline Hook一般是将函数入口的前五个字节替换成自己的代码，进入开发者自己的函数代码中进行监控和检测，在汇编指令中实际上是修改CALL指令的入口为JMP指令到其他的内存地址。

一般函数入口的汇编指令是：

Push ebp

Mov ebp，esp

通过ebp可以找到函数的返回地址，通过对返回地址的内存地址和汇编指令的判定，可以判定返回地址是否在栈中执行，若在栈中执行，即表明所述返回地址在进程正常的系统模块，若不在栈中执行，则表明所述返回地址未在进程正常的系统模块内，在这种情况下，则判定存在异常的调用行为，将其识别为利用漏洞发起攻击的木马，如网页木马。

需要说明的是，上述步骤204和步骤203可以同步执行，或者，所述步骤204也可以在步骤203之前执行，本领域技术人员根据实际情况任意设置执行次序均是可行的，本申请对此无需加以限制。

本实施例针对漏洞攻击中Shellcode的执行所需要使用的系统API函数(主要是下载函数，执行函数)进行Inline Hook，通过对这些系统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函数(主要是下载函数，执行函数)进行Inline Hook，通过对这些系统API函数进行监控和检测，根据所述函数的返回地址回溯检测函数入口指令是否正常，并判断所述返回地址是否在进程正常的系统模块中，同时判断所述返回地址的内存属性是否包括可执行属性，若否，则判定存在异常的调用行为，将其识别为利用漏洞发起攻击的木马，如网页木马，从而可以主动防御各类漏洞攻击，阻断和拦截已知和未知的各种缓冲区溢出攻击。

为使本领域技术人员更好地理解本申请实施例，以下通过一个具体示例进一步说明。

假设黑客针对CALL指令的劫持攻击方法如下：

00407160   8038 E8      cmp   byte ptr[eax]，0E8

call命令的开头

00407163   8038 E9      cmp   byte ptr[eax]，0E9

jmp命令的开头

00407166   75   0F      jnz   short 00407177

没有被InlineHook，直接进去

00407168   8178 05 9090909 cmp    dword ptr[eax+5]，90909090已被InlineHook，检查5字节后部分是否被nop了

0040716F    74 06        je      short 00407177

00407171    55           push    ebp

后面5字节完好，则直接实现前面5字节原代码

00407172   8BEC        mov    ebp，esp

00407174   8D40 05     lea    eax，dword ptr[eax+5]

跳到5字节之后执行

00407177   FFE0        jmp    eax

一、采用本申请提供的CALL指令检测方法，通过函数返回地址回溯检测函数入口指令是否正常，具体可以采用以下代码实现过程：

创建一个布尔类型的函数，函数名为CheckAfterCallInstruction，声明其参数为void类型，该函数功能为检测函数返回地址是否正常的CALL指令；

创建一个const unsigned char类型的字符串变量；

使用或条件使用CheckOpCode函数检测地址的字节码是否为标准的CALL指令；

检测机器码16进制字符串是否为0xFF，0x15，CALL指令汇编代码为CALL dword ptr[abs32]；

检测机器码16进制字符串是否为0xFF，0x14，CALL指令汇编代码为CALL dword ptr[REG*SCALE+BASE]；

检测机器码16进制字符串是否为0xFF，0x10，CALL指令汇编代码为CALL dword ptr[EAX]；

检测机器码16进制字符串是否为0xFF，0x11，CALL指令汇编代码为CALL dword ptr[ECX]；

检测机器码16进制字符串是否为0xFF，0x12，CALL指令汇编代码为CALL dword ptr[EDX]；

检测机器码16进制字符串是否为0xFF，0x13，CALL指令汇编代码为CALL dword ptr[EBX]″

......

校验完上述N种CALL指令的写法是否正常。

如果检测地址的指令非CALL指令，函数则返回flase。

bool CheckOpCode(const unsigned char*address，int bytes_before，const unsigned char opcode，const unsigned char opcode2，const char*what)

CheckOpCode函数第一个内存地址参数使用无符号字符参数，第二个字节参数使用整形参数，第三个字节码参数使用无符号字符参数，第四个字节码参数使用无符号字符参数，第五个参数为字符类型指针

if(*(address-bytes_before)＝＝opcode&&

(opcode2＝＝0||*(address-bytes_before+1)＝＝opcode2))

转换内存地址指令为16进制度字符串和CALL指令汇编代码两个条件分别进行校验。

二、系统模块返回地址检测，检测函数返回地址是否在正常的系统模块内，具体可以采用以下代码实现过程：

bool IsAllAddressInValidModule(void*retaddr[]，int count)

创建一个布尔类型函数，第一个参数是无符号数组，第二个参数是整形参数；

通过一个循环遍历第一个参数的返回地址，与系统模块中的函数地址和内存地址比对；

如果匹配上，函数返回布尔真值。

如果未匹配上，函数返回布尔假值，即该内存地址未落入系统模块内存地址范围。

三、内存地址属性检测，检测函数返回地址的内存属性是否为可执行属性，具体如以下代码所示：

bool IsAddressExecutable(void*address)

创建一个布尔类型函数，参数是无类型指针

SIZE_T ret＝VirtualQuery(address，&mbi，sizeof(mbi))；

通过windows api函数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_WRITECOPY)＝＝PAGE_EXECUTE_WRITECOPY)

加入页面属性等于可执行，等于可执行可读，等于可执行可读可写，等于可执行可写可拷贝，函数返回布尔真值。

如果不属于四种情况，函数返回布尔假值，即该内存地址存在不可执行代码的异常地址。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

参考图4，示出了本申请的一种漏洞检测的系统实施例的结构框图，具体可以包括如下模块：

钩挂模块401，用于针对机器码代码执行所调用的函数进行钩挂；返回地址获得模块402，用于获得所述函数的返回地址；

第一判断模块403，用于依据所述返回地址检测所述函数的入口指令是否为正常的CALL指令；若否，则判定检测到漏洞。

在具体实现中，所述机器码代码为在脚本运行的由漏洞触发的机器码代码Shellcode；所述钩挂包括内嵌钩挂Inline Hook操作。所述函数包括由调用指令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、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个......”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本申请所提供的一种漏洞检测的方法和一种漏洞检测的系统进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (20)

1.一种漏洞检测的方法，其特征在于，包括：

针对机器码代码执行所调用的函数进行钩挂；

获得所述函数的返回地址；

依据所述返回地址检测所述函数的入口指令是否为正常的调用指令CALL；若否，则判定检测到漏洞。

2.根据权利要求1所述的方法，其特征在于，所述机器码代码为在脚本运行的由漏洞触发的机器码代码Shellcode；所述钩挂包括内嵌钩挂Inline Hook操作。

3.根据权利要求1或2所述的方法，其特征在于，还包括：

判断所述返回地址是否在正常的系统模块中，所述正常的系统模块包括具有合法签名信息的DLL文件；

若否，则判定检测到漏洞。

4.根据权利要求1或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；所述钩挂包括内嵌钩挂Inline Hook操作。

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所述用于漏洞检测的云服务器，其特征在于，还包括：

第三判断模块，用于获取所述返回地址的内存属性，判断所述内存属性是否包括可执行属性，若否，则判定检测到漏洞。

Images