基于模糊测试的ActiveX控件 漏洞挖掘研究——硕士论文

硕硕士士学学位位论论文文 基于模糊测试的基于模糊测试的 ActiveXActiveX 控件控件 漏洞挖掘研究漏洞挖掘研究 专专 业业 名名 称称： 软软 件件 工工 程程 研究生姓名研究生姓名： 导导 师师 姓姓 名名： 校外导师姓名校外导师姓名： 摘要 I 摘要 关键字： ABSTRACT I ABSTRACT Key Words: I 目目 录录 摘要I ABSTRACT II 第一章 绪论.1 1.1 研究背景1 1.2 相关研究现状1 1.2.1 ActiveX 控件技术的发展 1 1.2.2 模糊测试技术的研究现状2 1.2.3 缓冲区溢出漏洞研究现状2 1.3 研究目的和意义3 1.4 主要工作与创新点3 1.5 本文的章节安排4 第二章 ACTIVEX 控件安全性分析与模糊测试技术5 2.1 ACTIVEX 控件原理分析 .5 2.1.1 ActiveX 控件加载原理 5 2.1.2 ActiveX 控件的加载条件 5 2.2 ACTIVEX 控件漏洞形成分析 .6 2.2.1 软件漏洞的定义6 2.2.2 软件漏洞的原理与分类6 2.2.3 ActiveX 控件的漏洞的特点与形成原因 .10 2.3 模糊测试技术.12 2.3.1 传统的漏洞挖掘方法.12 2.3.2 模糊测试的定义.13 2.3.3 模糊测试技术的原理.13 2.3.4 模糊测试的优点和缺点.14 2.3.5 进化模糊测试思想.15 2.4 本章小结.16 第三章 漏洞分析相关技术17 3.1 调试器原理.17 3.2 关键调试技术分析 .18 3.2.1 调试技术基础.18 3.2.2 调试相关的 API .20 3.3 自动化动态分析技术.20 3.4 静态分析技术.22 3.4.1 IDA Pro 及其插件开发 .22 3.4.2 利用 IDA Pro 实现静态代码分析.22 3.5 本章小结.23 第四章 ACTIVEX 控件漏洞挖掘分析系统 24 4.1 系统总体设计.24 II 4.2 漏洞挖掘模块.24 4.2.1 ActiveX 控件分析子模块 .25 4.2.2 启发式静态分析子模块 .28 4.2.3 二进制代码覆盖率分析子模块 .29 4.2.4 测试数据生成子模块.31 4.2.5 模糊测试执行子模块.32 4.3 漏洞分析模块.32 4.3.1 调试器子模块.33 4.3.2 反汇编子模块.35 4.3.3 溢出检测与定位子模块.36 4.3.4 单步跟踪子模块.41 4.3.5 漏洞代码分析子模块.43 4.5 本章小结.43 第五章 ACTIVEX 控件漏洞挖掘分析系统 44 实验验证及结果分析.44 5.1 实验验证.44 5.1.1 实验环境.44 5.1.2 存在漏洞的控件.44 5.2 漏洞分析.44 5.2.1 SetList（栈溢出漏洞）44 5.2.2 SetLogInfo2（堆溢出漏洞）48 5.3 漏洞自动挖掘系统的优缺点.52 5.3.1 系统优点.52 5.3.2 系统缺点 .52 5.4 本章小结 .53 第六章 总结与展望54 6.1 本文工作总结.54 6.2 未来研究展望 .54 致谢.55 参考文献.56 1 第一章 绪论 1.1 研究背景研究背景 自从万维网诞生以来，针对浏览器的攻击就愈演愈烈，一刻也不曾停歇过。 浏览器作为广大网民接触网络的主要工具，是网民踏入互联网世界的主要入口 之一。一旦这个入口受到恶意攻击，将有大量电脑沦为黑客的“肉鸡” ，轻则电 脑运行缓慢、不断弹出广告页面，重则帐号、金钱被盗，重要资料失窃等等。 随着软件工程理论和软件工业的发展，愈来愈多的软件漏洞被发现，软件 安全问题日益严重。由于利益的关系，越来越多的黑客将注意力转移到了浏览 器软件领域，致使不断出现浏览器的安全漏洞。作为 Windows 自带的浏览器， IE 到目前为止依然占有超过 50%的市场份额。这一数字使得大量黑客在不断寻 找 IE 浏览器的漏洞，而随着 IE 的诸多新版本推出，寻找并利用新漏洞的难度 也越来越大。 作为 IE 浏览器唯一支持的插件形式，ActiveX 控件的安全性一直受到很大 的关注。由于 ActiveX 控件一般会带有自身的类型库信息，而类型库中包含了 控件所能提供的所有方法和属性，以及它们的参数信息，因此这些方法和属性 成为了优良的模糊测试的对象。黑客借助于 Comraider、Axman 等工具可以轻 易发现 ActiveX 控件中存在的漏洞，从而利用这些漏洞达到破坏、窃取信息以 及非法牟利的目的。 经历了 2007、2008 年 ActiveX 控件漏洞出现高峰之后，各个厂商都开始注 重 ActvieX 控件的安全问题，由于没有判断输入参数长度而导致的缓冲区溢出 漏洞也大大减少。但是，如 Comraider 这种半自动化工具已越来越难以满足漏 洞挖掘的需要，而且，对于一些隐藏的漏洞也无能为力。 1.2 相关研究现状相关研究现状 1.2.1 ActiveX 控件技术的发展控件技术的发展 ActiveX 是微软公司 1996 年提出的基于 COM 组件和 OLE 技术的一种通用 的开放程序接口，使用该技术开发的 ActiveX 控件可以直接集成到 IE 浏览器或 其它第三方程序中1。 由于 ActiveX 控件可以方便地扩展浏览器功能，因此许多软件厂商都喜欢 开发自己的 ActiveX 控件。例如，各大网银为了保证自己的登录和交易安全， 都会让用户安装自己的 ActiveX 控件登录；一些电子商务网站，如淘宝，也会 建议用户安装登录安全控件。此外，网络视频软件、在线杀毒软件等也都会安 装自己的 ActiveX 控件。 这些控件一旦出现安全问题，黑客便可以构造恶意页面，诱使用户访问， 而用户一旦访问，黑客就可以轻易植入木马和病毒，盗取用户银行账户，对企 业和个人造成重大损失。 2 1.2.2 模糊测试技术的研究现状模糊测试技术的研究现状 模糊测试的思想最早产生于 1989 年美国威斯康星大学的一个研究计划， Barton Miller 教授（被成为模糊测试之父）最初是用来测试 UNIX 应用程序的 健壮性2。 1999 年，芬兰 Oulu 大学开始研发基于 Fuzzing 的网络协议测试工具 PROTOS，并于 2002 年发布了用于 SNMP 测试的版本。PROTOS 综合了黑盒 测试和白盒测试的特点，是模糊测试发展过程中的一个里程碑3。 2002 年，Dave Aitel 发布了一个开放源代码的模糊测试工具 SPIKE5，它使 用了基于块的模糊处理器，用于测试基于网络的应用程序。作为第一个可以实 现自定制的模糊测试器框架，SPIKE 的发布标志着模糊测试一个新的里程碑4。 2004 年，File Fuzzing 开始出现。Mu Dynamics(原 Mu Security)公司开始开 发一种硬件模糊装置，其目的是让网络中传输的协议数据发生变异。这个商业 产品供应商的出现，恰好吻合当前人们关注 Fuzzing 的潮流3。 同年，两个类似 SPIKE 的基于块的 Fuzzer 工具发布：Peach 和 smudge。这 两个工具都是使用 python 开发，从而提供了易于使用的快速开发框架。Peach 是近年来较受外界关注的模糊测试框架，适用于多个平台。Peach 要先对测试 的协议或文件格式进行建模，并用 XML 语言描述出这种数据模型，然后数据 生成引擎通过解析 XML 文件来构造测试数据集5。 2006 年，ActiveX 控件的 Fuzzing 开始流行，David Zimmer 发布了 COMRaider，H.D.Morre 发布了 AxMan16。ActiveX 控件由于其中接口、函数原 型的公开性，是一种优秀的模糊测试目标，允许对其实施自动化的智能测试。 这使得 ActiveX 控件漏洞的挖掘一时间风靡整个黑客界，不断会爆出某些软件 的 0day 漏洞。比如 2007 年底迅雷 5 的 PPLAYER.DLL 控件中溢出漏洞；2008 年初的联众 GLChat.ocx 控件溢出漏洞；2009 年的暴风影音 mps.dll 控件远程栈 溢出漏洞；2011 年的 QQ 旋风中 QQIEHelper.dll 控件的远程栈溢出漏洞；2011 年的淘宝阿里旺旺中 imageMan.dll 控件的远程栈溢出漏洞等等。 国外对模糊测试的研究较早也较深，有多款成熟的模糊测试框架推出，相 对于此，国内对模糊测试的研究起步较晚，尚未出现成熟的测试框架。文献9 介绍了使用模糊测试挖掘 MP3 播放软件中的漏洞，文献10介绍了使用模糊测 试挖掘 Word 软件中的漏洞，文献11介绍了使用模糊测试挖掘 PNG 格式解析 软件的漏洞，以上三种都属于文件 Fuzzing 的范畴，而文献12介绍了使用模糊 测试挖掘 TFTP 中的漏洞，这是种网络协议的模糊测试。 1.2.3 缓冲区溢出漏洞研究现状缓冲区溢出漏洞研究现状 缓冲区溢出攻击起源于 1996 年的一篇文章 “Smashing The Stack For Fun And Profit”14，这篇文章清楚地阐述了缓冲区溢出攻击的原理。这使得缓冲区 3 溢出攻击不断被世人所了解。1998 年来自“Cult of the Dead cow”的 Dildog 详 细介绍了如何利用 Windows 的溢出15，这篇文章的最大贡献在于提出了利用栈 指针的方法来完成跳转，避免了因进程、线程的不同造成的栈位置不固定。 1999 年，Dark Spyrit 提出使用系统核心 DLL 中的 Jmp ESP 指令完成跳转16。 同年，w00w00 安全小组的 Matt Conover 写了基于堆的缓冲区溢出的专著17， 从而使人们意识到堆溢出的危害性。 与此同时，缓冲区溢出保护技术也在不断发展。 2000 年，Arash Baratloo 和 Tzi-cker Chiueh 等实现的 StackShield 原型系统 通过保留返回地址的副本来检测溢出的发生18。同年，Hiroaki Etoh 和 Kunikazu Yoda 提出 Etoh 和 Yoda 技术，使用随机数保护和栈中的数组重定位技 术来防止对局部变量的溢出19。2002 年 12 月，Chew 和 Song 对栈的基地址、 系统调用表和库函数入口指针进行了随机化，并达到了破坏溢出利用可靠性的 目的20。2003 年 5 月，Xu,Kalbarczyk 和 lyer 提出了透明实时随机化技术，对 Linux 的栈基址、堆基址以及 GOT 进行了随机化21。 Windows 也从 XP SP2 开始引入随机化 PEB 基址、SEH 保护、堆栈 Cookie 保护等技术。这些技术的引进会增大缓冲区溢出攻击利用的难度，但是并不能 从本质上消除缓冲区溢出的出现。正如黑客技术与反黑客技术一样，溢出研究 与溢出保护研究也在对抗之中不断发展与前进。 1.3 研究目的和意义研究目的和意义 本文的研究目的主要有以下三点： 1、寻找到一种智能、高效的基于模糊测试的漏洞挖掘方法，能够挖掘出 ActiveX 控件中的缓冲区溢出漏洞 2、研究出一种动态分析与静态分析相结合的漏洞分析方法，对漏洞进行高 效、准确的分析，获取到漏洞形成的相关信息 3、实现一套基于模糊测试的自动化 ActiveX 控件的漏洞挖掘分析系统，以 完成从控件接口分析到漏洞挖掘到漏洞分析的自动化过程 本文的研究意义主要有： 1、通过对 ActiveX 控件进行自动化漏洞挖掘和分析，以帮助软件开发者或 安全人员尽早地发现、定位和分析漏洞，减少已发布软件中漏洞的数量及生存 期，从而避免漏洞对企业和个人造成重大的损失。 2、通过对 ActiveX 控件的漏洞挖掘研究，掌握漏洞挖掘过程的技巧和方法， 以应用到其它类型的软件安全漏洞挖掘中去。 1.4 主要工作与创新点主要工作与创新点 4 本文的主要工作与创新点主要有以下三点： 1、使用本人独立开发的调试器，研究并实现了一套高效的自动化单步跟踪 算法，大大减少了普通单步调式造成的性能影响，并在此基础上实现了计算二 进制代码覆盖率的方法。 2、研究了基于遗传算法的智能模糊测试技术，并使用二进制代码覆盖率作 为适应度函数，来指导测试数据的生成。 3、研究并提出了一种基于逆向工程的，动态分析为主、静态分析为辅的缓 冲区溢出漏洞自动检测、定位、分析技术。 1.5 本文的章节安排本文的章节安排 本文的组织结构如下： 第 1 章绪论，概述了选题的背景和意义，选题相关内容的研究现状，概述 了本文的研究内容、研究意义以及主要工作，最后介绍了论文的章节安排。 第 2 章 ActiveX 控件安全性分析与模糊测试技术，介绍了 ActiveX 控件的原 理技术，常见软件漏洞的分类以及 ActiveX 控件漏洞自身的特点，然后介绍了 传统的漏洞挖掘方法和模糊测试技术的定义、原理以及优缺点，最后提出了使 用进化算法改进模糊测试。 第 3 章漏洞分析相关技术，介绍了漏洞分析相关的技术，包括基于调试技 术的动态分析方法，在此基础上研究出一套高效、可控的动态分析方法用于计 算二进制文件的代码覆盖率，最后介绍了基于 IDA Pro 的静态分析方法。 第 4 章 ActiveX 控件漏洞挖掘分析系统实现，介绍了漏洞自动挖掘系统的 模块组成以及模块间的关系，还有系统运行的流程图，最后分析了该系统现在 的优缺点。 第 5 章 ActiveX 控件漏洞挖掘分析系统实现验证及结果分析，使用了一款 用户量很大的网络电视软件作为案例，使用漏洞自动挖掘系统对该软件进行测 试分析，最后发现了 6 个缓冲区溢出漏洞。 第 6 章总结与展望，总结了本文的工作，并分析了本文工作的不足和需要 改进的地方。 5 第二章 ActiveX 控件安全性分析与模糊测试技术 作为 IE 浏览器唯一支持的控件形式，ActiveX 控件的安全性问题一直深受 关注。本章将重点分析 ActiveX 控件的加载原理及其漏洞的类型和形成原因， 并对模糊测试技术做相应的介绍。 2.1 ActiveX 控件原理分析控件原理分析 2.1.1 ActiveX 控件加载原理控件加载原理 ActiveX 是以微软 COM（组件对象模型 Commponent Object Model）技术为 基础建立起来的，通过创建带有接口的对象，使其能够被脚本程序（如 javascript）跨进程、甚至跨机器远程调用，降低了软件之间的耦合性，为二进 制重用提供了一种途径，代表着新的软件开发技术。 常见的 ActiveX 控件会被编译成 exe、dll 或 ocx 格式的 PE 文件，在控件内 部需要实现一些必须实现的接口，其中实现控件主要功能的接口必须继承自 IDispatch 接口（派发接口） 。该接口共定义了 GetTypeInfoCount（是否支持类型 信息） 、GetTypeInfo（获取类型信息接口指针） 、GetIDsOfNames（获取接口函 数的索引） 、Invoke（根据索引调用相应函数）四个方法，其中最重要的是 GetIDsOfNames 和 Invoke 方法。这两个方法使得程序可以使用函数名来调用函 数，从而实现“晚绑定” （运行期间实现函数绑定） 。因此，IDispatch 接口成为 自动化（Automation，用编程语言控制软件运行）的核心技术。 而创建为双重接口类型的 ActiveX 控件可以同时支持“早绑定” （通过虚函 数表实现）和晚绑定，这样在编译型程序中可以使用早绑定，而在脚本程序中 使用晚绑定。 此外，ActiveX 控件也跟普通 COM 组件一样，拥有一个类标识（CLSID） 和多个接口标识（IID） ，CLSID 与 IID 都是 128 位的标识符，每个类标识有一 个相应的易于识别的字符串型的 ProgID。 ActiveX 控件由三个要素组成：属性、方法、事件。 属性：描述控件的特征信息 方法：控件暴露给外界的接口，使用者通过调用这些方法来完成特定的操 作。 事件：用户执行特定操作（如鼠标单击、双击、按键等）后产生的消息通 知，程序收到事件通知后可以执行相应的操作。 ActiveX 控件需要嵌入在容器中才可以正常工作，否则对象会创建失败。IE 浏览器就是一种很好的控件容器，通过编写一定格式的 html 代码（使用标 签，并且指定 clsid 属性） ，就可以在 IE 中加载指定的 ActiveX 控件6。 2.1.2 ActiveX 控件的加载条件控件的加载条件 由于 ActiveX 控件一旦执行后就拥有和浏览器等同的系统权限，因此需要 6 一些机制来避免恶意控件的加载。主要有以下几种机制： 1、数字签名 ActiveX 控件在发布前需要打上公司的数字签名证书，证明控件的合法身份。 IE 浏览器在加载控件前会检查控件的数字签名信息是否完整，检查失败则不会 加载控件。 2、标记为安全 ActiveX 控件需要在注册表中标记为“脚本安全”和“初始化安全” 。具体 来说就是在注册表项“HKEY_CLASSES_ROOTCLSID控件的 CLSID Implemented Categories”下面存在“7DD95801-9882-11CF-9FA9- 00AA006C42C4”和“7DD95802-9882-11CF-9FA9-00AA006C42C4”这两个 子项。 除此之外，ActiveX 控件还可以通过实现 IObjectSafety 接口来在 IE 浏览器 中将自身标记为安全。 3、KillBit 机制 微软还提供了一种临时禁止控件加载的机制，即 KillBit 机制。如果注册表 值“HKEY_LOCAL_MACHINESOFTWAREMicrosoftInternet ExplorerActiveX Compatibility控件的 CLSIDCompatibility Flags”为 32 位长整型的 0x400，IE 就认为该控件已被禁用，从而拒绝加载该控件。该方法可以作为控件出现漏洞 时的临时补救措施7。 2.2 ActiveX 控件漏洞形成分析控件漏洞形成分析 2.2.1 软件漏洞的定义软件漏洞的定义 漏洞（Vulnerability）是指计算机系统在硬件、软件、协议的具体实现或系 统安全策略上存在的安全型缺陷，主要包括输入验证错误、设计错误、整数溢 出、缓冲区溢出、格式化字符串错误、意外情况处理错误、环境错误等8。 漏洞与功能性缺陷（bug）之间的区别是：漏洞会使攻击者通过恶意的输入 获得系统的一定权限，从而对系统造成破坏，或窃取机密信息。 2.2.2 软件漏洞的原理与分类软件漏洞的原理与分类 从本质上讲，漏洞的形成都是程序员的疏忽造成的。由于没有对所有可能 的输入进行正确的处理，这使得程序在正常的输入情况下没有问题，而一旦用 户有意或无意输入了错误甚至恶意的数据，就会使程序执行攻击者指定的恶意 代码，获得系统权限。 根据漏洞的类型主要可以分为以下几种： 1、 缓冲区溢出 这是迄今为止危害最大，也是覆盖面最广的漏洞类型。 所谓缓冲区溢出，是指向一个缓冲区内拷贝的字符数组的长度超过了缓冲 7 区的实际长度，从而致使其它合法数据被破坏，之后执行的指令在读取修改后 的数据后通常会导致程序崩溃。而精心处理的数据可以使程序跳转到攻击者制 造的指令上来，这也是该漏洞的危害所在。 缓冲区溢出分为栈溢出和堆溢出。 （1）栈溢出 栈（Stack）是程序存储局部变量和调用函数所必不可少的连续的内存区域。 在 Windows 中，程序默认的栈大小为 1M 到 2M，如果要在栈中分配超过栈允 许长度的内存，就会发生栈溢出。可以在程序链接时通过开关修改默认的栈大 小。 操作系统在创建线程时，会为每个线程分配单独的栈空间并初始化相关的 数据结构和寄存器。例如，在 x86 系统中，会使用 SS（Stack Segment）寄存器 （堆栈段寄存器）来记录堆栈段的段值，使用 EBP 寄存器作为栈帧基址寄存器， ESP 寄存器作为栈顶指针。程序在进行函数调用的时候，一般会通过“call xxx” （xxx 为函数地址）指令去调用函数，实际上该指令做了以下两个操作： PUSHEIP JMP xxx （注： 汇编中是不可以直接操作 EIP 的，这里只是为了便于理解，下同） 所以“call”指令在执行时会自动保存函数的返回地址，以便函数在返回时 可以回到“call”指令的下一条指令。这是通过“ret n” （n 为参数所占的字节数） 指令实现的， “ret n”指令做了以下两个操作： POPEIP ADDn 因此，栈中保存的函数返回地址决定了程序的执行路径，改变了返回地址， 也就改变了程序的执行流程。 在函数的一开始一般会有以下创建标准栈帧的操作（优化后的代码会没有） ： PUSHEBP MOVEBP, ESP 通过这种方式，就可以将上一次函数调用时的栈帧基址保存起来，并将 EBP 设为新的栈帧基址，因此通过 EBP 值可以在栈中找到一条函数调用链。如 图 2-1 所示，根据红框中 EBP 的值可以依次得到每次函数调用的栈帧，再根据 函数的返回地址就得到了函数的调用堆栈，这就是堆栈回溯，在程序调试的过 程中会经常用到它。 8 图 2-1 函数调用堆栈图 函数在栈中可以分配的内存大小一般是在编译时决定的，编译器会在函数 开始的地方生成类似“SUBESP, 100”这样的指令。也就是说，该函数只 有 0x100 个字节的栈空间可以使用，如果函数中做了内存拷贝的操作，而且拷 贝的字节数超过了 0x100，那么后面的栈空间就会被非法修改。这就是栈溢出 发生的原因。最常见的情况就是由于函数的返回地址被修改而出现访问违规， 如果是精心构造的数据，返回地址会指向攻击者的代码，从而使攻击者得到了 远程代码执行权限。 （2）堆溢出 堆（Heap）是组织内存的另一种重要方法，是程序在运行期动态申请内存 空间的主要途径。 堆和栈的区别主要有以下几点： 1） 栈空间的分配是固定的，是编译时决定的，而堆空间是动态分配的， 是运行时决定的。 2） 栈空间是有限的，一般用于存储局部变量，而堆空间相对来说是比较 大的，允许分配大块的内存，而且可以显式地控制对象的生存期，在其不需要 时将其释放。 3） 在 Windows 中，栈是由高地址往低地址分配，堆由低地址往高地址 分配；堆空间的管理要远远比栈空间复杂。 由于 Windows 保护模式机制的存在，每个进程空间是一个线性的平面结构。 在 32 位系统上，进程可见的内存空间范围均为 00xFFFFFFFF，即虚拟地址空 间。这其中高 2G 空间为内核空间，低 2G 为用户空间，而且用户空间前后的 64K 大小均为隔离带，不能够访问。因此，用户态程序真正能访问的地址空间 范围是 0x00010000 0x7FFEFFFF。Windows 通过 VirtualAlloc（分配虚拟内存） 、 9 VirtualFree（释放虚拟内存）等 API 直接操作虚拟内存，但是 Win32 子系统为 了提高内存分配的效率，实现了一套堆管理机制来满足应用程序对内存的需求。 即用户应当通过 HeapCreate（创建堆） 、HeapAlloc（从堆中分配内存） 、 HeapFree（释放内存） 、HeapDestroy（销毁堆）等 API 来创建和销毁堆，这几 个 API 实际上调用的是 ntdll.dll 中的 RtlCreateHeap（创建堆） 、 RtlAllocateHeap（从堆中分配内存） 、RtlFreeHeap（释放内存）和 RtlDestroyHeap（销毁堆） 。 事实上，实际编程中人们很少直接去调用这些堆管理函数，而是使用 crt 库 封装的 new（分配内存） 、delete（释放内存）或 malloc（分配内存） 、free（释 放内存） 。 在 Debug 版本下，它们会包含一些调试代码，可以方便编程人员发 现存在的内存问题。 如前所述，堆的内部结构是非常复杂的，系统需要多个数据结构来维护堆 的管理。每个堆由一到多个内存段（Segment）组成，第一个段（0 号段）的开 始处存放着一个 HEAP 结构的堆头信息；每个段会有一个 HEAP_SEGMENT 结 构来描述自身；一个段由若干个堆块组成，每个堆块会以一个 8 字节的 HEAP_ENTRY 结构开始。这些只是维护堆结构的最基本信息。 堆溢出与栈溢出类似，也是由于内存拷贝操作超出了堆分配的长度，不同 的是堆溢出会修改堆管理结构中的数据，造成堆管理器无法正常工作。较常见 的情况是堆被破坏后，在下一次分配堆（HeapAlloc）的时候发生访问违规。但 有时堆溢出很久之后才出现异常，这时再来寻找原因就已经错过了“第一现场” ， 难度会加大很多。因此，对堆的操作要格外小心。 一般来说，栈溢出会覆盖函数返回地址或异常处理链，攻击者使用堆喷射 （Heap Spray）技术便可以执行 Shellcode，因此利用的难度会低一些。 相对于栈溢出，堆溢出的利用会麻烦一些，因为无法直接改变指令的执行 流程。通常的思路是利用对指针的操作间接改变关键数据从而获得代码执行权 限。 随着 Windows 加大对缓冲区溢出攻击的防范力度，例如从 XP SP2 开始引 入随机化 PEB 机制、SHE 保护、堆栈 Cookie 保护等技术，这些技术的引进增 加了对缓冲区溢出利用的难度，但是并没有从根本上消除缓冲区溢出的发生。 因此只有在软件开发的过程中杜绝危险的代码，才能从本质上消除缓冲区溢出 的出现。 2、 整数溢出 整型变量在申明时一般会确定好类型，包括占用的字节数和是否是 unsigned 类型。因此，整型变量在申明时其可以表示的整数范围就已经确定了。如果对 其赋予一个不在其表示范围内的整数就会发生整数溢出。整数溢出可以分为以 下几种： 10 （1）算数运算产生的进位 例如两个大正数相加或相乘，产生进位的时候就会出现溢出，导致结果不 正确。 （2）无符号类型的上溢与下溢 无符号数是没有负数的，因此对一个接近于零的正数做减法操作时，不小 心就会下溢变成一个超大的正数。 （3）有符号类型与无符号类型的转换或比较 由于这两种类型表示的范围不同，强制转换或比较就容易出现问题。例如： int i = -1; unsinged int j = 0xFFFFFFF0; bool b = i j; 虽然 i 为负数，但结果却会大于 j。 整数溢出本身并没有太大的危害，一般情况只会影响计算的结果。但有时 整数溢出会间接导致缓冲区溢出，因此也不容小视。 3、 格式化字符串 成因一般是在使用包含格式化字符串操作的 C 语言函数时，如 fprintf、sprintf、snprintf、vprintf、vfprintf、vsprintf 和 vsnprintf 等，允许用户输 入格式化字符串导致的。因此，使用这些函数时必须正确地指定格式。 4、意外条件错误 对意外情况没有做容错处理，致使程序直接抛出异常而崩溃。 2.2.3 ActiveX 控件的漏洞的特点与形成原因控件的漏洞的特点与形成原因 1、ActiveX 控件常见的输入参数类型 ActiveX 控件是基于 IDispatch 接口实现的，使用的数据类型是 VARIANT 类型。具体使用的数据类型与 javascript 语言中的数据类型的对应关系如表 2-1 所示。 表 2-1 ActiveX 控件中使用的数据类型 VARIANT 类型javascript 类型 VT_I4整型 VT_BSTR字符串型 VT_R8浮点型 VT_BOOL真/假 VT_ARRAY数组 11 2、ActiveX 控件的漏洞的特点 ActiveX 控件除了会存在上述一般软件存在的漏洞外，还具有以下一些特点。 （1）控件实现的接口主要通过脚本来调用，比如 Javascript、VBScript 等， 因此传入的参数需要符合相应脚本语言的语法规则。 （2）控件中有可能会存在一些逻辑漏洞，主要是设计时没有对控件安全足 够重视造成的。例如控件中存在操作注册表、操作文件、下载文件之类的接口， 攻击者可以直接使用这些接口获得一定的权限。 MS06-014 漏洞就是一个典型的逻辑漏洞，由于系统对使用者的权限控制不 足，导致它允许网页脚本使用控件 Microsoft.XMLHTTP、Adodb.Stream 和 Shell.Application 去下载并运行一个远程文件。 （3）程序缺陷（bug）导致拒绝服务攻击 普通的 bug 最多导致程序崩溃（Crash） ，但是 ActiveX 控件由于其远程执行 性，攻击者只需要将恶意代码上传到 web 服务器上，用户访问后浏览器就会发 生异常而退出。这种漏洞虽然不会对系统造成大的危害，却会影响用户正常使 用浏览器的功能。 （4）环境错误导致问题 操作系统或浏览器版本不兼容，从而致使控件无法正常工作或者程序崩溃。 3、ActiveX 控件的漏洞的形成原因 ActiveX 控件的漏洞形成原因主要有以下几种： （1）设计错误 大部分的逻辑漏洞都是软件在设计时没有充分考虑到安全性，从而给攻击 者留下了“后门” 。 （2）没有判断输入参数的长度 某些场景下，有些开发人员认为传入的参数（比如一个文件名）长度不会 超过某个上限，因此使用栈来分配空间，又没有判断参数的长度，结果就导致 了栈溢出。 （3）处理逻辑未考虑特殊情况 这里主要是对输入字符串的处理上，例如，要对一个 url 做分析，取出其中 的参数，但是输入的 url 是这样的“/index?a=1/通过参数传入 0041160E mov dword ptr i,64h if(i = 200) 00411615 cmp dword ptr i,0C8h 0041161C jne wmain+39h (411629h) i += 10; 0041161E mov eax,dword ptr i 00411621 add eax,0Ah 00411624 mov dword ptr i,eax else 00411627 jmp wmain+3Dh (41162Dh) return 0; 在代码中当 i 等于 200 时才会执行相应的代码，否则会直接退出。也就是说， 当传入的参数 i 不为 200 时，都是无效数据。启发式规则可以去分析反汇编代 码中的这些关键数据，主要是通过扫描 cmp 等指令来获取。通常这些数据是整 型或字符串，如果是整型，一般是立即数形式，可以直接获取；如果是字符串， 一般是编译时保存在只读数据区，指令中保存的只是一个地址，此时要根据指 令获取字符串的内存。目前这种方法的缺陷是还不能去理解程序中的特定逻辑， 如果比较的是进行运算后的数据，那么启发式方法很有可能就起不到作用。 由于在程序中存在着大量这种数据，全部分析的代价很大，而且大部分数 据只是些无关数据。因此，在本模块中，采用了如下的分析算法： 1、 获取要测试的接口函数地址，从此地址开始反汇编，直至该函数结束 2、 扫描反汇编代码，获取其中的启发式数据，并记录到列表中；扫描反汇 编代码中的函数调用（call 指令） ，获取调用的目的地址。这里只考虑静态调用 29 的函数，动态调用的函数由于目的地址只有在运行时才能获取，因此暂未考虑。 3、 分析函数调用的目的地址，如果是要测试的模块中的函数，则跳到第 2 步，递归执行；如果不是，则分析下一个函数调用。如果没有可分析的函数调 用，则退出分析过程。 分析获得的数据将被用于在遗传算法中生成初始种群。 4.2.3 二进制代码覆盖率分析子模块二进制代码覆盖率分析子模块 本模块的目的是计算某组测试数据的二进制代码覆盖率，以作为评价测试 数据质量的指标。 常见的代码覆盖率测试属于白盒测试，是基于源码基础之上的。原理是使 用插桩技术在所有的关键位置插入代码，然后重新编译、链接，并让程序打开 指定的测试数据，等程序运行到插桩代码后便可以捕获到程序的执行，程序执 行结束后会生成覆盖率统计数据。常见的覆盖方式有语句覆盖、判定覆盖、条 件覆盖、路径覆盖等。测试数据覆盖得越多，表明测试质量越高。在实际使用 中，主要使用的是语句覆盖和判定覆盖。 对于二进制文件，由于无法获得程序源码，因此就不能使用源码插桩的方 法。这里使用的是 3.3 节介绍的基于调试的自动化动态分析方法。其基本原理 是：在调试过程中，将每次路过的指令地址加入到一个列表中。当程序退出时， 列表中保存的就是覆盖到的所有指令。由于并不是要获取最终的覆盖率百分比， 而且百分比的分母即程序中的总指令数是固定的，因此可以以覆盖到的指令数 作为覆盖率结果。 由于反汇编代码在语义上的复杂性，这使得对分支、循环等代码段的分析 难度很大，因此只是使用了语句覆盖，也就是指令级的覆盖。 在计算覆盖率过程中，为了尽可能地缩短运行的时间，如果发现当前指令 已经在已覆盖列表中，就不再设置为单步调试。但这样需要保证程序每一个可 能运行到的分支都是可控的。举例来说，条件跳转指令会产生两种可能的运行 路径，第一次路过时会使用单步调试走过其中一条路径，而第二次路过时程序 是直接走过去，如果另外一条路径上没有设置断点，并且又执行到了那条路径 上就会失去对这部分代码的覆盖率统计。因此，这里也可以看出，3.3 节中对条 件跳转指令设置两处断点的处理是很有必要的。 由于对 call 指令和 ret 类指令使用了常断点，因此可以记录到程序的函数调 用序列，此序列也可以作为覆盖率的辅助参考指标。 简单来说，当两个测试数据获得的代码覆盖率较为接近，无法区分优劣时， 就比较它们的函数调用序列是否相同，如果不同则认为它们属于不同的等价类， 均为有效测试数据；如果相同基本可以认为它们中有一个是可以舍弃的。 为了防止使用遗传算法时出现局部最优的情形，在取舍测试数据时，并不是挑 30 选出覆盖率高的测试数据，而是抛弃掉一小部分覆盖率低的测试数据，再对整 个种群进行杂交、变异，以生成新的测试数据。从以上过程可以看出，种群繁 殖变异的速度不是很快，因此达到最优所需要的代数也会多一些。 由于覆盖率测试是基于动态调试原理，花费的时间也会多于基于插桩技术的覆 盖率测试，而且每个测试数据都要计算一次覆盖率数据，总的时间开销也是很 大的。因此，采取以下策略以减少无效测试数据数量和提高测试速率： 1、如果对于任意测试数据，都会有很高的覆盖率，那么会停止对该接口函 数的测试 2、测试前会使用静态分析方法搜索危险函数的调用，在生成测试数据时尽 量将程序执行路径指引到危险函数的调用上来。 以下是计算二进制代码覆盖率的伪代码算法： List lstAddr = ; /存放路过的指令 List callList = ; /存放调用序列 int startAddr = 获取接口函数起始地址; OpenDebugger(“iexplore.exe”); /打开调试器 SetBreakPoint(startAddr); /在接口函数处设置断点 if(StopOnBreakPoint(startAddr) /在 startAddr 断下后 lstAddr.push_back(addr); /放入指令列表中 String strAsm = DeAsm(addr); /获取 addr 地址处的反汇编指令 int nAsm = GetAsmLen(addr); /获取该指令的长度 if(strAsm.startWith(“call”) /如果是 call 指令 SetLongBreakPoint(addr); /将该地址设为常断点 dstAddr = GetDstAddr(strAsm); /获取 call 指令的目的地址 AddrCallList(addr, dstAddr); /添加调用到调用序列列表中 if(dstAddr 不在本模块地址范围内) SetBreakPoint(addr + nAsm); /在下一条指令处设置断点 else if(dstAddr not in lstAddr) /如果调用的目的地址不在指令列表中 SetSingleStep(); /设置为单步调试 else if(strAsm.startWith(“ret”) /是 ret 指令 retAddr = GetRetAddr(strAsm); /获取返回地址 if(retAddr 不在当前模块地址范围内) /出现错误（由回调函数引起） ，需要 回到正确的调用位置 callStack = GetCallStack(addr); /获取调用堆栈 realRetAddr = GetRealRetAddr(callStack); /根据调用堆栈获取正确的返回地 址 31 SetBreakPoint(realRetAddr); else SetLongBreakPoint(addr); /ret 指令也需要设为长断点 else if(strAsm.startWith(“j”) /获取跳转的目的地址 SetBreakPoint(addr+nAsm); SetBreakPoint(dstAddr); /目的地址和下条指令处都要设置断点 else if(strAsm.startWith(“rep”) /rep 类指令 SetBreakPoint(addr+nAsm); /防止该指令不断重复执行 if(addr not in lstAddr) /尚未路过 SetSingleStep(); /设置单步调试 从以上代码可以看出，计算二进制代码覆盖率的关键就在于，既要能捕获 路过的每条指令，又不能影响性能。因此，该算法通过在条件跳转指令的关键 位置处设置断点，并记录每次路过的指令地址，以保证不在执行过的指令上使 用单步调试。而对 call 指令和 ret 指令使用常断点，可以保证每次函数调用都能 被正确捕获到。 4.2.4 测试数据生成子模块测试数据生成子模块 该模块的功能是生成测试数据，并将测试数据写入到一个 HTML 文件中， 以便直接用 IE 浏览器打开。 1、测试数据生成子模块的特点 该模块是模糊测试的数据引擎，负责生成所有的测试数据，使用了启发式 思想和遗传算法。针对 ActiveX 控件的一些特性，该模块具有以下一些特点： （1）对于没有参数的接口函数或是不包含字符串型变量的接口函数不做测 试。对于可利用的漏洞，需要攻击者能够指定要执行的恶意代码，这就需要一 个类似于缓冲区的参数，所以攻击者一般都是使用字符串型变量来存储恶意代 码。 （2）由于控件接口函数参数的类型主要为整型和字符串型，因此数据引擎 主要是生成整型和字符串型的变量，并不像文件或协议的模糊测试那样具有严 格的格式限制，可以认为这是种弱格式的模糊测试。 （3）由于大多数 ActiveX 控件的漏洞形成原因都是在对超长字符串的处理 上，因此数据生成引擎会分为两个阶段，第一阶段是按照长度倍增的方式，不 断传入字符串参数，直到控件发生异常或是字符串长度达到 20000。这是个人 32 为指定的长度极限，如果这一长度的字符串也没有造成异常，就认为更长的字 符串也不会造成异常。第二阶段使用启发式规则和遗传算法来产生测试数据。 2、测试数据生成步骤 生成测试数据的步骤如下： （1）使用启发式静态分析模块获取启发式数据列表，根据这些数据以及其 它随机值生成一定数量的初始种群，种群数量不能太大也不能太小，太大会使 种群臃肿，影响测试性能；太小会使测试不充分，影响测试质量。测试数据以 组为单位，每组测试数据都能构成一次完整的接口函数调用，例如一个接口函 数有三个参数，那么每组测试数据都是由这三个参数组成的三元组。 （2）使用二进制代码覆盖率分析模块计算每组测试数据的覆盖率以及函数 调用序列。 （3）抛弃掉覆盖率较低的测试数据和重复的测试数据（具有相同的函数调 用序列） ，但需要保留一定量的重复测试数据，覆盖率越高保留得越多。 （4）对剩下种群内的测试数据按照一定的概率做杂交和变异，生成新一代 的测试数据种群。 （5）重复执行 2 4 步，直至覆盖率数据无明显提高或超过一定的繁殖代数。 每组新生成的测试数据都会被送入模糊测试执行模块，如果发现会导致异常也 会终止测试数据的生成。 4.2.5 模糊测试执行子模块模糊测试执行子模块 本模块是整个漏洞挖掘模块的调度模块，负责调用不同的功能子模块完成 相应的操作，然后执行测试数据生成子模块生成的测试数据，并监控和捕获可 能产生的异常。 本模块内部包含了一个简易的调试器，用于以调试方式带参数（测试数据 所在网页的 url）打开 IE 浏览器，从而可以检测到 IE 进程是否发生异常。使用 调试器检测异常的准确性很高，而普通的检测方式是看 IE 进程是否自己退出或 弹出异常对话框。 如果在指定的时间内（例如 10 秒）没有发生异常，则执行下一组测试数据。 如果发生异常，本模块会记录异常发生时的寄存器、堆栈信息，并将内存 dump 下来。然后会停止当前接口函数的测试，并转向漏洞分析模块。 在测试执行过程中，不能使用同一个 IE 进程打开多个测试页面，否则会出 现误报，将随机出现的异常认为是漏洞。 由于一些控件会弹出对话框（如 MessageBox） ，这些对话框都是模态的， 会阻塞程序的继续运行，需要将其关闭。这里是建了一个线程，不断查找弹出 的对话框，并点击“确定”按钮。 为了提高执行的效率，此处使用多线程方式，每个线程测试一个 IE 进程。 33 4.3 漏洞分析模块漏洞分析模块 本模块负责在发现会导致异常的测试数据后，对该异常做进一步的分析， 先判断是否是缓冲区溢出漏洞，然后再定位漏洞的位置、分析漏洞的成因。这 部分内容由于自动化分析难度较大，故常用的是手工分析方法，手工分析一般 费时费力，遇到特殊情况很难定位到正确的位置；而自动化分析可以减轻手工 分析的负担，将溢出过程中的关键地址、数据记录下来，以帮助分析人员做进 一步的分析，对于简单的漏洞也可以直接分析出原因。因此，本文提出了一种 可以用于自动化定位、分析漏洞的方法。 从功能上划分，漏洞分析模块可以分为：调试器子模块、反汇编子模块、 溢出检测与定位子模块、单步跟踪子模块、漏洞代码分析子模块等。其中，调 试器子模块属于基础模块，提供了进程调试所需要的功能；溢出检测与定位子 模块和单步跟踪子模块继承自调试器子模块，并根据自身不同的算法使用调试 器功能；反汇编子模块是个服务模块，为其它几个子模块提供了将二进制代码 反汇编为汇编代码的功能；漏洞代码分析子模块负责对反汇编代码或单步跟踪 子模块获得的指令执行序列进行静态分析。图 4-4 是漏洞分析模块主要的执行 流程。 图 4-4 漏洞分析模块主要执行流程 该模块采用了动态分析为主，静态分析为辅