【资料图】

随着社会越来越发达，大家都选择在网络上汲取相关知识内容，比如ActiveX控件中不安全方法漏洞的检测技术，为了更好的解答大家的问题，小编也是翻阅整理了相应内容，下面就一起来看一下吧！

当今软件开发中，面向组件的编程技术应用越来越广泛。但是，组件的使用使编程人员在软件开发过程中提高效率的同时，一并出现的安全性问题也不可忽视。根据NVD(National Vulnerability Database)发布的信息，在2008年1月1日至2009年8月20日之间，共发布了227条描述为在ActiveX控件中引发的漏洞[1]。伴随着网络的普及与基于网络的应用的快速发展，ActiveX控件在应用的数量上非常巨大，而被收入到NVD数据库的只是现存的众多数量的ActiveX漏洞中的极少数部分，还有大量的ActiveX控件的漏洞由于其软件或控件流行范围的局限而不被NVD所关注。 另一方面，伴随着Windows 2003和SP2在操作系统安全机制上的提升，很多漏洞的利用方式被成功遏制。如今要想在Windows系统中找到能够利用的漏洞已经是一件很困难的事情，因此更多的黑客与安全人员把目光转向了第三方软件。近几年，一些知名的软件公司都曾被发现其注册的ActiveX控件中存在严重的漏洞，鉴于控件的特点，可以说这些漏洞跟IE自身的漏洞没有多大的区别。所以在漏洞挖掘中尽早发现这类漏洞并及时地通知相关厂商，以便做出及时的应对措施显得尤为重要。1 ActiveX控件1.1 什么是ActiveX ActiveX是微软公司在1996年引进的，它是在组件对象模型(COM)、对象链接和嵌入(OLE)技术的基础上发展而来[2]。COM规范是ActiveX技术的基础，而COM的目的是创建对象和提供接口来实现代码片段的简单复用，而这些接口又能被其他的COM对象或者程序调用，ActiveX就是这项规范与IE的结合。这种结合提供了IE浏览器与第三方软件的接口，使用ActiveX控件可以对IE浏览器进行功能扩展，可建立应用程序与网站之间的联系，而这种联系通过浏览器来实现。比如登录一个在线视频网站的时候，网站正是通过浏览器调用ActiveX控件打开本地的视频资源。 每一个ActiveX控件通常使用CLSID(Class Identifier)来区别于其他的控件。CLSID是标识一个COM类对象的全球唯一的标识符，它是一个128位的随机数。可以从注册表中的HKEY_CLASSES_ROOTCLSID来读出本机已经注册的CLSID。 ActiveX控件并不能直接使用，它首先需要在目标机器中进行注册，有很多种方法可以注册控件，除了所有的属于IE和操作系统的控件以外，新安装控件可以通过应用程序的安装注册一些控件；还可以通过网页中OBJECT>标签中的CODEBASE属性，从指定位置下载并注册控件；另外通过DOS命令regsvr32也能手动注册一个控件。1.2 脚本安全 一个ActiveX控件可以被标注为脚本安全SFS(Safe For Scripting)，这意味着IE可以通过脚本语言如JavaScript或VBScript调用控件，并设置或获得它的属性。 有两种方法可以描述一个控件是脚本安全的，第一种方法是使用组件目录管理(Component Categories Manager)来在系统注册表中创建合适的项目。可以通过在这册表编辑器中查看“HKEY_CLASSES_ROOTCLSIDcontrol clsid>Implemented Categories”是否拥有子键7DD95801-9882-11CF-9FA9-00AA06C42C4。第二种方法是通过实现IObjectSafety接口，通过调用IObjectSafety::SetInterfaceSafetyOptions方法来确定控件是否为脚本安全[3]。1.3 KillBit KillBit是注册表中的一项，用来标识控件使得在IE浏览器或者脚本环境运行时不加载控件。当发现有漏洞的控件时，可以先通过设置KillBit来使IE在使用默认设置时永不调用ActiveX控件。KillBit是ActiveX控件的兼容性标志DWORD值在注册表中的特定值0x00000400。针对IE与操作系统的不同，KillBit在注册表中的位置略有不同[4]，可分别表示为： (1)32位IE/32位Windows：HKEY_LOCAL_MACHINESOFTWAREMicrosoftInternetExplorerActiveX Compatibility (2)64位IE/64位Windows：HKEY_LOCAL_MACHINESOFTWAREMicrosoftInternetExplorerActiveX Compatibility (3)32位IE/64位Windows：HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftInternet ExplorerActiveX Compatibility1.4 控件函数枚举 由于ActiveX遵循COM规范，因此它也像其他的COM控件一样使用相同的方式实现了COM接口，COM接口中很好地定义了一个COM组件中所实现的方法和属性。如果控件实现了IDispatch或者IDispatchEx接口，那么可以通过获得IDispatch接口来枚举出控件的方法、参数以及属性等信息。2 不安全方法漏洞及检测2.1不安全方法漏洞 通过分析NVD以及US-CERT(US-Computer Emer-gency Readiness Team)中关于ActiveX漏洞的描述信息，ActiveX漏洞与其他的漏洞在类型上大致相同，占据漏洞比例绝大部份的是由于缺乏必要输入验证而带来的缓冲区溢出漏洞。另外还包括由于IE加载恶意网页而引发的在控件实例化过程中造成的崩溃[5]。本文要提到的不安全方法漏洞，也是在ActiveX控件中频频出现的一种漏洞。 如果一个方法被设计是由IE调用，那么它应该就被标记为脚本安全，微软在MSDN中提供了编写一个安全的控件时对于哪些应该被标为安全提供了指导。但是由于编程人员在安全性上的疏忽，或者根本就不熟悉ActiveX的调用机制，一些标记为脚本安全的方法能够轻易地被远程调用者不加任何限制地调用，或者一些本不应该被IE所使用的方法错误地被标注上了脚本安全，这些方法给系统带来很大的安全隐患。这类漏洞往往表现为任意的注册表读写、本地文件系统的读写、网络端口的开放，执行文件、敏感信息的泄漏等。由于这类漏洞的利用一般非常简单，因此这类漏洞利用门槛很低，危害性极大。2.2 ActiveX控件的检测2.2.1 威胁建模 威胁建模(Threat modeling)是一个过程，软件开发人员可以使用它来评估，从而减少控件所面临的潜在的威胁[6]。威胁建模来自于软件测试领域，威胁建模的一般步骤是先分解应用程序，建立数据流图，然后识别所面临的威胁，根据威胁识别潜在的漏洞。对于识别潜在的威胁，可以利用Howard和Leblanc提到的STRIDE威胁目录[7]。 但是由于威胁建模一般是建立在拥有软件设计细节的基础上。作为漏洞挖掘工作，常常面临的只是软件的二进制文件形式，很难得到软件设计的源代码，构建完整的数据流图。因此，基于威胁建模的漏洞挖掘工作，很难建立起准确的威胁模型。