一种多通道件加载漏洞检测方法_第1页
一种多通道件加载漏洞检测方法_第2页
一种多通道件加载漏洞检测方法_第3页
一种多通道件加载漏洞检测方法_第4页
一种多通道件加载漏洞检测方法_第5页
已阅读5页,还剩3页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

一种多通道件加载漏洞检测方法

dll(组件)是一组包含公共代码和数据的函数。其他程序使用组件所需的接口调用所需的函数。在Windows操作系统中,除核心模块外,应用程序可调用相对独立的组件模块,不仅便于程序功能的扩展、更新、排错,而且能实现代码重用以及功能模块的按需加载,减少物理内存的占用量。因此,应用程序自身往往带有许多特定的DLL组件,自身没有组件的应用程序也会加载操作系统预设的系统组件。一旦应用程序需要加载一个DLL组件,操作系统必须知道该组件所在的存储位置。Windows提供了2种方式说明待加载DLL组件的位置:组件完整路径(带文件名的绝对路径)和组件文件名(相对路径)。前者按照指定路径寻找该加载的DLL,而后者没有指定该DLL所在位置。为此,操作系统提供了预设的搜索目录列表,按序逐一搜索给定的DLL文件名,一旦搜索成功就加载该位置的DLL。如果攻击者把伪造的DLL放入该位置前的任意目录(位于搜索目录列表)中,则产生DLL劫持攻击。Windows开启了安全搜索模式(standardsearchorder,SSO)和备用搜索模式(LOAD_WITH_ALTERED_SEARCH_PATH),以减少被劫持的概率,微软和应用软件厂商也通过补丁技术给DLL添加完整路径。同时,编程人员杜绝使用相对路径的组件加载也可以减少被劫持的概率。但是,组件劫持漏洞不断被发现,如MS11-071、MS11-076、MS11-085、MS12-012、MS12-014等。除操作系统本身存在DLL劫持漏洞外,第三方应用软件自身携带的DLL同样存在该漏洞,如AutoCAD2007、GoogleEarth、Winamp、Skype等。这种漏洞从本地利用延伸到可以远程利用,如MS12-014。同时,利用该漏洞的劫持攻击能够绕过现有对堆栈保护的安全机制,如DEP,StackGuard以及地址随机化等,其威胁程度日趋严重。而且操作系统软件和应用软件还存在许多未知DLL加载漏洞,挖掘这些漏洞可以达到防范于未然,提早预备防护措施。利用可信计算平台作为可信计算基,可以完成实体信任的传递和组件完整性验证。虚拟化技术也为二进制代码的完整性验证提供了支持,可以检测出隐秘的组件。Dymo提供了内存代码的度量,防止外部代码在合法代码中的执行。如果伪造的DLL是未知的组件,该技术可以阻止该组件的加载。但未知组件的信任识别依然是一个难题。因此,研究DLL组件动态加载漏洞的检测具有重要的实际应用价值。Kwon等提出了程序动态分析和程序静态分析挖掘DLL加载漏洞的方法。动态分析采用Pin的动态代码插桩技术(dynamicbinaryinstrument,DBI)截获9个函数获取程序的加载信息,然后离线检测漏洞。该方法属于动态程序分析,在用户态截获的函数较多,导致性能开销过高,同时受限于程序执行的单一行为迹。静态分析采用IDA和逆向切片技术分析可能存在的程序漏洞,检出的漏洞数明显高于动态分析。该方法解决了动态分析代码覆盖不足的问题,检测结果更准确,但参数解析失败、反汇编失败等因素会产生漏报。DLLHijackAuditKit提供了利用ProcMon工具动态检测组件加载漏洞的工具集,需要手工操作。程序分析方法的分析时间比较长,难以在主机系统在线部署和动态检测。同时,一旦主机系统的程序更新,需要对更新后的代码进行分析,才能检测新的漏洞。根据动态链接库加载时的路径搜索行为,本文提出一种在线检测动态链接库加载漏洞的方法,以实现离线检测DLL劫持攻击,从而缓解程序分析方法中的单一行为迹问题。同时,结合组件加载的上下文,该方法实现监测点的最小化,以减少对系统干扰,缓解系统部署难的问题。1对该组件的攻击进行检测DLL加载分为隐式加载和显式加载。应用程序在初始化阶段,会根据导入表(IAT)加载所需的DLL以及这些DLL导入的其他DLL,这属于隐式加载。显式加载是指应用程序内部代码显式调用LoadLibrary或LoadLibraryEx加载一个指定的DLL。隐式加载时,DLL一般都通过文件名来搜索并加载;显式加载时,既可以指定DLL的完整路径,也可以只指定DLL文件名来加载。然而,不管是隐式加载还是显式加载,其实质都是调用LoadLibrary实现,LoadLibraryEx在LoadLibrary内部被调用。通过逆向分析LoadLibrary函数,发现其DLL加载过程可以分为3个阶段:搜索、映射和初始化。LoadLibrary根据传入的DLL完整路径或DLL文件名来搜索待加载DLL,将其映射到进程的内存空间,再调用DLL入口函数完成对DLL初始化。操作系统根据传入的DLL文件名或文件完整路径来查找DLL的物理位置,从而获得DLL文件句柄。搜索阶段,先查找该DLL是否已加载,如果已加载则直接返回已经加载的组件的句柄,并将其引用计数加1,以避免重复加载。如果没有加载,接着查找注册表键HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\KnownDLLs,判断该组件是否为KnownDLL。如果该组件属于KnownDLL,则根据注册表中设定的路径加载该组件DLL。如果该组件既没有已经加载,也不是系统已知DLL,操作系统会根据LoadLibrary传入的组件参数进行组件的位置搜索。组件参数为完整路径,则直接搜索该组件。如果搜索成功,则直接加载。如果组件参数为文件名,操作系统会按照事先设定的搜索目录列表对DLL文件进行搜索,直到DLL找到或者目录搜索完毕。如果搜索成功,则根据搜索阶段得到的DLL完整路径打开DLL文件并获取文件句柄。接着分配内存区域,然后将DLL文件内容映射到内存,把获得DLL的入口地址保存到数据表中,并将DLL入口加入到加载模块列表中。最后,操作系统载入该组件引用的其他DLL组件,修改IAT表项,更新DLL引用计数,并调用DLL入口函数对DLL进行初始化。对于以文件名方式传入的组件,操作系统采用一套搜索机制确定组件所在的物理存储位置。操作系统默认的搜索目录列表为:{应用程序所在目录、当前目录、系统目录、16位系统目录、Windows目录、环境变量目录}。该列表也称为标准搜索模式(StandardSearchMode)。操作系统从列表的第一个路径开始搜索给定的组件名称,直到找到该组件所在的位置或者搜索失败。该过程也称为DLL组件的解析,找到了DLL组件称为组件解析成功,搜索失败称为组件解析失败。对于解析成功,如果组件所在的路径不是搜索目录列表的第一个,则搜索目录中解析失败过的路径存在被劫持的风险。而DLL解析失败意味着搜索目录的全部路径都存在被劫持的风险。因此,在DLL组件解析过程中,只要存在解析失败的路径,就存在该路径被劫持的风险。在WindowsXPSP2及以后的版本中,Windows默认开启安全搜索选项,将当前目录移至Windows目录之后,搜索目录列表改为{应用程序所在目录、系统目录、16位系统目录、Windows目录、当前目录、环境变量目录}。该搜索模式简称安全搜索模式(SafeDllSearchMode)。该模式可以减少当前目录被劫持的风险。另外,搜索目录和顺序也可以通过参数设置或调用特定函数来改变。应用程序目录可以通过LoadLibraryEx传入的LOAD_WITH_ALTERED_SEARCH_PATH标志,修改应用程序所在的完整路径。从WindowsXPSP1起,微软提供SetDllDirectory函数,在调用LoadLibrary前动态修改当前目录为该函数传入的路径值,该搜索模式可以减少当前目录被劫持的攻击面。当采用这种方式时,安全搜索模式将无效。操作系统还提供SetCurrentDirectory函数来在程序中动态修改某进程的当前目录,将存储进程当前目录的变量值设置为传入的绝对路径,并且这种方式可以与安全搜索模式结合使用。上述的搜索安全增强方法归纳为移动搜索目录列表中路径项的位置和修改对应的路径项。它们的本质都是减少路径被劫持的攻击面,从而减少搜索失败的概率,达到安全增强的目的。但对于组件解析失败而言,这些技术都失去防护作用。2基于白盒的系统行为监控为了检测组件加载漏洞和劫持攻击,需要监测组件的加载行为。监控系统运行必须要在被监控对象中部署探针以获取系统运行的状态数据,然后根据这些数据分析或者检测可能的异常。观察系统运行的方法有黑盒和白盒2种。黑盒方法是把系统看作是不透明的盒子,无需源代码,通过外部观察系统的资源访问(文件、进程等)或者资源消耗(CPU、内存、网络带宽等)。黑盒的好处是对系统干扰小,但获取的信息可能不够精准。白盒方法借助设计文档或者程序员的帮助,往程序代码中定向地植入探针。其优点是监测的针对性强、信息准确,但对系统的干扰比较多,且后期维护难度加大。Kwon等Hooking了用户态的9个函数,实现了组件加载漏洞的检测,其监控方法可以归于白盒方法。傅建明等通过在核心态Hooking应用程序的系统调用构建软件行为模型,其监控方法可以归于黑盒。源于该内核态监控思路,利用系统调用的上下文,给出一种基于灰盒的系统行为监控方法。因此,灰盒方法的难点在于如何获取行为的上下文信息,提高监控的准确性。2.1定向和按需监控从内核态选择监控点实现组件加载行为监控,需要明确组件加载的过程,第一节描述了组件加载分为3个阶段:搜索、内存分配和映射、初始化。组件加载漏洞源于第一个阶段,操作系统对组件的遍历搜索。Kwon等放置探针的9个函数只有LdrpResoveDllName函数负责组件的搜索。通过逆向分析,LdrpResoveDllName会通过KiFastSystemCall进入内核态,调用ZwQueryAttributesFile检测组件是否存在。因此,ZwQueryAttributesFile作为组件加载漏洞检测的监控点,也是唯一的监控点。该监控点位于核心态,任何调用该函数的信息都会记录。就是说,LdrpResoveDllName会调用该函数外,GetFileAttributesW和SearchPathW等函数也会调用ZwQueryAttributesFile查询资源是否存在。因此,必须做到按需监控,即只监控组件加载时的路径搜索行为。一种直观的方法是从输入参数中可以提取路径信息,利用DLL组件的后缀名过滤非DLL路径查询的调用,从而部分减少监控的范围。同时,采用栈回溯技术定位该调用是否为组件搜索,从而剔除不属于组件加载搜索的ZwQueryAttributesFile调用,实现定向和按需监控。程序的函数在调用过程中,会将调用的上下文信息,如栈的基址、局部存储空间、调用参数和返回地址等,保存到内存的栈中,栈中保存上下文信息的结构称为栈帧,这些信息用于被调用函数结束后能顺利地返回调用点。函数可以嵌套调用,调用一次压入相应的调用上下文到栈中,从而形成栈帧链。因此,当前函数中的EBP寄存器保存当前栈帧的基址,该(EBP+4)保存的则是此次调用结束后返回的地址。通过解析栈的结构,可以通过一个个栈帧回溯到应用程序最初引发系统调用的代码地址。采用逆向分析方法,获得了从ZwQueryAttributesFile到LdrpResolveDllName的返回地址,如图1所示。从图1可以看出,栈帧回逆到LdrpResolveDllName++0x12d的位置,对应的内存地址为0x7C93CE16。LdrpResolveDllName位于ntdll.dll中,其返回地址0x7C93CE16可以作为LdrpResolveDllName发出调用的判据。但是,操作系统的地址空间分布随机化技术会随机化PE格式映像的加载基址,返回地址会变化。不过,地址空间随机化并不会对地址的后2个字节造成影响。采用LdrpResolveDllName返回地址的末尾2个字节0XCE16,以及该地址中连续的8个字节0xE3840F944589C33B,作为判据,确定ZwQueryAttributesFile调用是组件加载搜索路径时发出的。因此,通过获取ZwQueryAttributesFile的调用参数和调用栈帧的上下文信息,实现监控行为的准确定位。2.2对组件加载的检测在进行DLL组件搜索时,系统会根据当前设置的搜索选项,生成DLL搜索目录字符串,里面包含了待搜索的所有目录项。系统依次获取每个目录项,与DLL名称字符串拼接,形成一个完整的文件路径,然后判断该路径是否真实存在于磁盘中。如果找到了待加载DLL,打开获取文件句柄后进入映射阶段;否则,继续搜索下一个目录项,直到文件存在或所有目录项均被搜索完。在拼接形成一个完整路径后,系统最终会调用内核函数ZwQueryAttributesFile来完成判断路径是否对应真实存在的磁盘文件的操作,并根据该函数的返回结果进行下一步的操作。因此,通过内核态SSDTHOOKING技术,挂钩ZwQueryAttributesFile,截获DLL加载时的搜索信息。该函数的输入参数包含了DLL路径信息,输出参数会在DLL搜索成功时得到设置。函数的返回状态为STATUS_SUCCESS时,表示文件真实存在,否则,表示文件不存在或文件信息不符合。因此,可以通过解析输入参数和判断函数返回值,检测DLL搜索是否成功。会话(session)可以描述一个组件加载的搜索结果。该Session包含每一次搜索的全路径和搜索结果。每次搜索用2元组描述,形如{State,FullPath}。例如,{0C:\ProgramFiles\InternetExplorer\LPK.DLL}表示搜索C:\ProgramFiles\InternetExplorer\LPK.DLL失败,而{1C:\WINDOWS\system32\LPK.DLL}表示搜索LPK.DLL成功。会话的构建过程就是组件加载漏洞的检测过程。如果会话含有状态为0记录,则检测出组件加载漏洞。Windows操作系统采用线程调度任务,因此,可以采用PID-TID-DLL标记一个会话,如0000-5e4-00000df4-MSISIP.DLL。任何时候,一个线程只有一个会话。当获取一个组件搜索的调用时,解析其参数和上下文,得到一组信息{State,FullPath,DLL,PID,TID}。如果该PID和TID没有会话-则新建一个会话,用PID-TID-DLL标记该新会话,同时插入记录{State,FullPath}。如果该PID和TID有会话,但其会话的DLL名称与该调用的不同,则把旧会话写入日志,同时清空该会话,插入新的记录{State,FullPath}。如果该DLL属于原有会话,则直接在会话尾部插入新的记录。因此,当线程检索不同名组件或者超时时,把该旧的会话写入日志。Algorithm1描述了组件搜索的会话构建过程,其中WriteSession函数负责把会话写入日志,写入时把PID解析为进程名,便于人们直观理解。组件劫持检测依赖于日志文件SLOG和FLOG。如果某进程同一个组件的不同搜索会话存在前后不一致,可能是组件劫持。组件劫持检测算法如Algorithm2所示。该算法输入为日志文件SLOG和FLOG,每次检测出可疑的攻击DLL被保存到FakeDLLList中。如果ReadSession的第二个参数为NULL,则表示从日志文件中取第一个会话;否则,表示获取与第二个参数具有相同进程标识和组件标识的会话。RemoveSession是删除日志文件中相同的会话;FindDllHiJacked寻找Session中搜索失败的路径是否在SLOG中,如果找到攻击,则写入攻击列表中;IntersectSession从进程名和组件名都相同的两个会话中寻找攻击,如果找到攻击,则写入攻击列表中。图3描述了组件加载漏洞的检测框架,该框架描述了用户态的组件加载函数调用过程和调用关系。该检测器D2HAT(dynamicDLLhijackaudittool)实现了堆栈回逆、参数解析、会话构建以及日志写磁盘等基本功能。SLOG存放搜索成功的会话,FLOG存放含有搜索失败的会话。漏洞检测的结果直接放在FLOG中。劫持检测按照Algorithm2,采用python实现。该编程语言在处理文本和大数据时,具有灵活、高效的特性。脚本程序读取文件SLOG和FlOG作为输入,将处理结果输出到FakeDLLList中,完成离线检测。3系统已下载的应用软件实验环境为VMWare环境下的WindowsXPSP3,虚拟机配置均为512M内存、40G硬盘。应用软件直接从互联网上下载,DLL劫持的样本部分来自于exploit-db。下面从组件加载漏洞检测、组件劫持检测以及系统开销分别介绍。3.1恶意4.2攻击过程一个正常的程序启动时,根据导入表加载DLL,可以将其加载的DLL分为3类:LoadedDLL、KnownDLL和需要搜索的DLL。存在加载漏洞的是后面2类。KnownDLL为操作系统自带的系统DLL,注册表中保存了该类DLL的加载路径,系统会尝试用该绝对路径来加载DLL,劫持很难发生,除非该DLL缺失。需要搜索的DLL,系统会按照前面讲到的搜索机制来进行搜索,可能会使得DLL劫持有机可乘。为了更加细致的分析哪些DLL的加载会导致劫持,本文将需要搜索的Dll组件分为部分搜索的DLL(PartialSearch)和搜索全部失败的DLL(SearchFailure)。PartialSearch的DLL位于搜索目录列表的中间路径,操作系统经过至少一次的搜索失败才能成功找到该组件。如果将同名的、伪造的DLL组件放置于搜索失败的路径上,则可以成功实施恶意DLL的加载。SearchFailure的DLL是指该DLL不存在搜索目录列表的任何路径中,该类DLL面临本地劫持和远程劫持的威胁。在测试环境中加载检测工具-D2HAT,然后加载相应的测试软件,模仿正常用户的操作使用该软件,操作过程若3~5min左右,卸载该测试软件。根据日志文件FLOG,整理出DLL加载漏洞信息如表1所示。表1中PartialSearch所列的数据表示这些组件都能在搜索目录列表的路径中找到,但至少在第一个路径上搜索失败,攻击者在任何失败路径上放置伪造组件,该伪造组件都可以被加载。PartialSearch型漏洞会造成组件被本地或者远程劫持,安全风险较高。该列数据分为本文检测的漏洞和文中提到的漏洞,本文的检测方法明显优于文的动态插桩的分析方法。究其原因,可能是文的分析时间较短,或者没有模仿用户操作软件,使得需要用户触发的漏洞都没有被检测到。另外,按照搜索成功的路径统计PartialSearch的数据,结果如表2所示,大部分被劫持的组件都是系统组件,也是产生风险的主要源泉。因此,应用软件在加载系统组件时,应采用完整路径,以避免被劫持。SearchFailure所列的数据表示该组件无法在给定的路径上找到。如果全路径的组件没有找到,则该组件可以被定向劫持,该类型漏洞还比较多,其安全风险一般。例如QQ.exe在点击“开始视频会话”或“开始音频会话时”,会以绝对路径C:\ProgramFiles\Tencent\QQ\Plugin\Com.Tencent.NetDisk\Bin\Disk.dll尝试加载Disk.dll,但由于该DLL不存在于该目录,会出现加载失败。第二种是组件在所有搜索路径上都不存在,此类漏洞较少,但安全风险最高,可以容易地被用于远程劫持。例如OfficePowerPoint2007运行时,点击菜单栏“审阅”,powerpnt.exe会尝试加载msdrm.dll,由于该DLL不存在,所以powerpnt.exe会对搜索路径上的所有目录进行搜索,并都出现搜索失败。如果将恶意DLL放置于任何一条搜索目录中,劫持都会成功。3.2f机构计算机病毒动态如果FLOG对同一个进程和组件而言,存在2个不同的会话,则利用Algorithm2可以检测出攻击组件。采用2个实例说明该检测过程,一个是在部分搜索(PartialSearch)的会话中的劫持;另一个是搜索失败(SearchFailure)的会话中的劫持。第三节中的图2描述了应用程序InternetExplorer6加载组件LPK.DLL时的搜索会话,D2HAT会记录该会话到FLOG中。如果攻击者把伪造的LPK.DLL放置在IE的程序目录,则其搜索会话变为图4,该会话记录在SLOG中。根据图2和图4的会话,利用Algorithm2中FindDllHiJacked可以得到攻击者的组件为C:\ProgramFiles\InternetExplorer\LPK.DLL。应用程序OfficePowerPoint2007打开pptx文档时,点击菜单栏“审阅”,会尝试加载msdrm.dll,但搜寻失败,其会话如图5所示,被记录在FLOG中。如果攻击者把伪造组件放置在当前目录,则可以实现远程劫持,其会话如图6所示,被记录在FLOG中。利用Algorithm2中IntersectSession可以得到攻击者的组件为msdrm.dll。3.3其他加载实验数据微软提供了一套工具集监测系统的运行,如注册表、文件、网络、进程/

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论