2. 西北大学 爱迪德信息安全联合实验室, 西安 710127
2. NWU-Irdeto Network-Information Security Joint Laboratory(NISL), Northwest University, Xi'an Shaanxi 710127, China
软件是研发人员智慧与汗水的结晶。每款软件都包含了许多重要信息,如核心算法和机密数据等。为了确保软件处在一个相对安全的开发、维护过程中,微软提出了软件安全开发周期(Security Development Lifecycle,SDL)[1]这一模型。该模型将软件的生命周期分为三个主要阶段:发布前-发布-维护期。在发布前和维护期,软件的控制权是由软件研发者所有。而一旦发布后,控制权将转交给用户。目前,软件大多以二进制可执行代码的形式发布。随着软件逆向工程技术的不断发展,各种逆向分析工具,比如:反汇编器、调试器、反编译器等层出不穷,这使得软件盗版、破解等恶意行为越来越多。这些恶意行为让软件处于危机四伏的“白盒攻击环境”(White-Box Attack Environment)[2]中。最终,将导致软件研发者不能获取到预期的收益,从而降低了开发人员的工作积极性,破坏了软件行业的平衡和有序发展。
Collberg[3]于2012年提出,需要确保软件处在一个安全的环境中执行。这里的安全环境一方面是指运行该软件的计算机中没有安装逆向分析工具,如调试器、模拟器和类似VMWare的虚拟环境等;另一方面指建立黑白名单威胁库,在软件运行时对这些威胁进行监控。同年,Collberg以软件防篡改为例,提出了“条件-触发”模型,在保护过程中为软件体内部署若干个用于检测篡改行为的代码片段和相应的处理篡改行为的代码片段。当软件执行后,一旦满足预先设置的篡改条件,就会触发对应的响应措施。加拿大爱迪德公司首席架构师Gu[2]提出了软件白盒攻击环境下的14种安全模式,文中将满足这14种安全条件的软件定义为安全的软件,反之则认为其是存在安全风险的产品。这14类安全模式可以初步作为安全威胁的白名单库。由此得出,对执行中的软件进行威胁检测,能够在一定程度上降低攻击成功率,提高软件的安全性。然而,目前在软件中处理的攻击威胁类型比较单一,且威胁处理片段易被去除,同时对可以被逆向分析利用的软件可用信息缺乏理论上的分析与较深入的研究案例。
本文提出基于攻击威胁监控的软件保护方法,目的是在软件中部署威胁监控节点网,即时检测响应处理执行过程中的威胁;同时,通过实时校验节点自身的完整性,防止监测节点被攻击者破坏;最终,达到阻碍逆向分析、保护软件的目的。主要贡献在于:
1) 提出了威胁描述的三元组表示方式,可用于对威胁进行分类;
2) 提出了在软件中部署威胁监控网监测威胁的方式,以便软件执行过程中实时处理攻击威胁。
1 相关工作目前,针对软件攻击威胁监控的研究如下:2012年黄山[4]提出一种采用动态二进制程序切片的方式检测程序的易攻击点。2013年张璇等[5]从正向分析的角度出发,提出一种基于信息熵和攻击面的软件安全度量方法;通过计算软件攻击面中各项资源的信息熵来评估每一种资源的安全威胁程度,实现对软件安全开发、使用的有效指导。同年,诸葛建伟等[6]对主动性的安全威胁监测与防御方案——蜜罐作了系统地阐述,该方案通过部署额外的安全资源,诱骗攻击者使用,进而对攻击行为进行捕捉处理;虽然,目前这样思想主要用于僵尸网络追踪和恶意代码样本捕获,但是在软件安全领域中仍有借鉴意义。文献[7]提出一种在软件中部署多个安全哨兵的方式来监测软件是否遭受到篡改。在此基础上,为了安全哨兵自身安全性,防止它们被攻击者绕过或去除,在文献[8]中采用了三线程和安全哨兵结合的方式。
如今,国内外各大软件安全论坛:看雪、一蓑烟雨、debugman等都对检测攻击威胁(如:调试行为检测、完整性检测等)提供了相关的技术方案;同时大多数商用软件保护工具Themida[9]、SafeEngine[10]、DT Protect[11]、TenProtect[12]等都在一定程度上应用了这些技术方案。因而,不论是从理论基础研究,或者是技术实践应用,深入挖掘对威胁监控的解决方案都具有重大价值与意义。
2 基于攻击威胁监控的软件保护方法 2.1 方法概述基于威胁攻击的软件保护系统(Software Protection based on Monitoring attack Threats,MTSP)通过确定软件执行过程中潜在的攻击威胁集合,构造ring3级和ring0级结合的威胁监控节点。既利用ring3代码稳定性高、容易实现的特点;又利用ring 0级代码权限高、安全性高,不易被ring3级攻击工具调试发现的特点。在此基础上,合理部署各节点,在被保护软件中形成攻击威胁监控网,使节点可以对软件运行环境和执行过程中的攻击威胁进行实时监控,同时ring3和ring0相互协作,提高威胁检测的准确率。在详细描述该保护方法之前,先给出相关定义。
2.2 相关定义定义1 节点地址表。用于存放节点库中每个节点起始地址的四字节型数组。按照所存储节点类型的不同,分为检测节点地址表、响应节点地址表和安全性节点地址表。
定义2 节点调度函数。负责维护程序代码片执行环境、选择节点、恢复代码片执行环境的功能单元。
定义3 节点插入位置信息记录链表。记录了结构体〈节点插入地址,该地址处指令,下一条指令地址〉的链表。
定义4 节点Context。指在程序中申请的一段用于保存节点辅助信息(比如:用于解析节点符号的核心动态链接库基址、关键应用程序编程接口(Application Programming Interface,API)的入口地址)、检测结果、中间变量等内容的内存空间。
定义5 发送器。用于获取当前进程id并将其发送给守护模块的功能单元。
定义6 接收器。用于保存守护模块发送过来的检测结果,并根据检测结果设置节点Context对应字段的功能单元。
定义7 守护模块选择器。用于读取当前系统版本并选择对应版本守护模块的功能单元。
2.3 攻击威胁描述文献[13]对如何描述软件攻击过程中使用到的攻击方法进行了详细的描述,提出了用〈输入状态,攻击目的,攻击技术,攻击对象,输出,难易程度〉六个因子来表示一种攻击方法。借鉴这种思想,本文对攻击威胁也采用了类似的描述方法,其三元组形式为:〈威胁目的,实施方式,作用对象〉。具体含义是为了造成某种攻击威胁,可以使用某种方式作用于某个对象上。表 1以客户端游戏软件中某些非法加速和注入为例,具体说明这种描述方式的使用。
表 1中第一项威胁可以描述成为了达到非法加速游戏的目的,对timeGetTime()函数采用内联Hook的方式。这样描述攻击威胁的好处在于对威胁类型划分得更细致,有利于分类,对后文提取攻击威胁特征,设计威胁检测节点时会更方便,节点的代码量会更精小,原子性更强。
2.4 监控节点设计这里需要考虑到三个问题,首先由于ring3层节点最终是插入到待保护软件中,故节点的执行不能破坏程序自身的执行环境,这样就要求在设计节点时,要严格保护程序的执行现场;其次是为了提高代码复用率,节点要尽量设计得简短,一种威胁可以用多个节点检测且一个节点可以被用于多种威胁的检测中;最后ring0层节点是以独立的驱动守护模块的形式出现,不会插入到待保护程序体内,故该守护模块不能轻易被发现去除且稳定。
按照功能将节点库中的节点分为四类,下面具体阐述这4类节点的设计情况。
1) 威胁检测节点。
在大量攻击实验的基础上,分析总结了软件在执行过程中经常面临的威胁有:虚拟执行环境威胁(比如:VMWare或沙箱等)、调试威胁、加速威胁、注入威胁、动态链接库(Dynamic Link Library,DLL)劫持威胁、Hook威胁、篡改威胁这7种。对同一种威胁目的,有多种不同的实现方式。设计按照3个步骤进行:首先,使用〈威胁目的,实施方式,作用对象〉的描述方式对这7种威胁进行细致划分和形式化表示。其次,提取威胁特征,考虑时可以结合三个因素:①威胁的实施方式;②威胁的作用对象;③威胁造成的影响,即威胁产生的痕迹。最后,根据特征构造检测此威胁的代码片,即检测节点。
以远线程注入威胁为例,说明上述过程的具体含义:
第1歩 形式化描述为〈注入,远程线程,目标进程〉。
第2歩 提取特征。通常装载器给目标进程所创建的远线程函数为LoadLibraryA()且该函数参数为待注入的第三方模块名字(实施方式),若注入成功目标进程空间内会出现注入模块(痕迹),所以特征为:LoadLibraryA()和已注入到内存中的可疑模块。
第3步 节点功能为监控LoadLibraryA()函数调用及其参数是否异常,扫描进程内是否有可疑模块。
威胁检测节点会将检测情况写入节点Context的对应字段,若检测到,则该字段设为1;否则设为0。
2) 检测结果判断节点。
这类节点是检测节点和响应节点之间的桥梁,它通过读取节点Context对应字段的值来确定是否调用响应节点。设计相对简单,故在这里不作详细介绍。
3) 响应节点。
响应相较于检测来说更简单些,本文提供了3种响应方式: ①直接退出进程;②提示检测结果;③诱导程序进入预先设置的错误分支。
4) 安全性节点。
安全性节点是为了防止节点库中节点被篡改,因此此类节点主要是对节点库、节点地址表等进行完整性校验。
如上方法,最终得到的节点库组成如图 1所示。
考虑到ring0层驱动实现起来相对复杂,一方面要考虑驱动在多平台之间的稳定性和兼容性;另一方面还需要考虑内核驱动设计时的限制问题,比如多线程;最后还需要考虑不能让守护驱动被攻击者轻易发现并去除。故这里将在守护驱动中实现的ring0检测节点单独提出来介绍(后面提到的检测节点若非特别说明都是指ring3级上的)。
ring0节点主要是为了检测调试威胁,分为基于父进程检测的调试检测和基于调试端口检测的调试检测。这两种调试威胁检测方法分别是读取目标进程EPROCESS结构中的父进程id字段和debugport字段,然后查看该父进程id对应的进程是否为调试器进程、debugport是否被设置,若是,则说明目标进程正在被调试。被保护程序和守护模块之间的通信方式如图 2所示。
不同于一般的软件保护方法,保护方案引入的代码会嵌入到被保护程序中,两者融合构成保护后的软件。而守护模块是以ring0层驱动文件的形式独立出现,为了防止该模块被去除,这里使用了“加载时释放安装”的隐藏策略。该策略的主要思想为:在软件保护过程中,将不同系统下的守护模块加密存储在被保护软件预先开辟的缓冲区中;当程序加载后,守护模块选择器依次读取当前系统版本并选择对应版本的守护模块,将其解密并释放到系统驱动目录内,然后,程序加载安装该驱动。当程序执行结束时,会卸载驱动并删除本次生成的驱动文件。图 3中以守护模块2为当前系统对应的模块为例,说明该策略的具体实施过程。由此看出,这种策略的好处在于当软件未执行时,系统内并不会出现驱动文件;驱动文件的生命周期只为本次程序运行期间,且该驱动被存于系统驱动目录的路径下,不易被发现。
节点布局是指将守护模块和ring3级节点安插到软件的不同位置中,确保软件既能正确执行自身的代码,也能够正确执行插入到的节点。此处就两种布局方案的保护效果进行讨论:
1) 程序执行前完成所有检测。
其执行效果如图 4(a)。首先在程序加载后获取代码的执行控制权,待执行完所有的节点,再将控制权传给程序入口点。在这种情况下,程序自身的执行过程依旧是按照保护之前的流程来进行的。该方式的优点是:①实现简单;②由于节点和程序之间只有一次环境切换,故因环境切换带来的性能损耗较小。但不足之处在于:①威胁监控和程序自身分隔明显,易被攻击者发现并去除;②有很多攻击威胁是发生在软件执行过程中的,此类布局方式将不能检测到这些威胁。因此这种布局方式适用于那些环境切换代价高的节点类型。由于守护模块在运行前需要进行版本识别、解密释放、加载安装等一系列工作,耗费的性能较大。故可以将守护模块用这种方式布局,用于先验判断软件是否处于一个安全的操作环境中。
2) 程序执行过程中监控。
这种方式需要监控节点和程序自身交替执行,执行效果如图 4(b)所示。其优点是:①节点和程序自身分片交替出现,隐蔽性高;②可以更全面地对软件运行过程中的威胁进行监控。缺点是:①实现起来相对复杂;②需要多次切换执行环境。因此,该布局方式适用于那些环境切换代价低的节点类型。ring3级节点和被保护软件都是运行在用户层,在切换环境时只需做好现场保存和恢复工作即可,代码量较少。故采用这种方案来部署ring3节点,以便实时监测软件执行情况。2.6节将专门介绍如何将ring3节点插入到程序体内。
2.6 ring3节点插入规则从2.5节可知,本文采用节点代码和程序代码交替执行的方案来部署ring3节点。因此,需要考虑3个问题:1) 划分程序代码片的基本单元如何确定;2) 基于什么样的选择方式从节点库中选取待插入节点;3) 节点应怎样插入到程序体内。下面将逐一回答这3个问题。
问题1 为了保护过程中提取方便,直接将程序控制流图中的每个基本块作为一个代码片。
问题2 从2.4节可知,节点分为四类:检测、判断、响应、安全性节点。除判断节点外,其余三类节点的个数均超过一个。这里将采用随机选择的方式,从这三类节点中选取执行。最终节点的执行顺序为:检测节点→安全性节点→判断节点→响应节点。
问题3 在一个代码片中插入节点的具体步骤如下。
步骤1 在代码片中按照指令地址递增的顺序,找出首个指令长度超过5 B的指令,作为待插入位置;
步骤2 记录〈节点插入地址,该地址处指令,下一条指令地址〉,并将其添加到节点插入位置信息记录链表中;
步骤3 替换该处的指令为“CALL 节点调度函数”。
此时,完成了节点插入操作。可知,每个程序代码片最多插入一个调用节点调度函数的指令。其中,节点插入处程序的执行过程如图 5所示。
由于各节点在设计时是相互独立的,那么如何使检测结果正确传递给判断节点,响应节点又怎样准确地对判断结果做出合理的回应,以及节点执行过程中的中间变量如何保存都是本文需要解决的问题,因而引出了节点Context的概念。该结构是一段节点公共访问区,节点可以从该结构里获取自身执行所需的辅助信息,检测节点可以设置该结构的检测结果标志,判断节点读取检测结果标志,节点执行的中间结果也可以存放在该结构里,从而实现了节点网的有序执行和通信。Context的具体组成,将在3.1节详细介绍。
3 MTSP中的关键技术 3.1 关键数据结构 3.1.1 节点Context如图 6所示,节点Context以4 B为基本单位,共60 B。其具体含义如下。
偏移00h:检测节点地址表的偏移;
偏移04h:判断节点起始地址;
偏移08h:响应节点地址表偏移;
偏移0Ch:安全性节点地址表偏移;
以上内容是供节点调度函数选取节点时使用的。
偏移10h:检测结果标志。用于指示是否发现威胁:1表示检测到,0表示没有检测到;
偏移14h:GetModuleHandlA入口地址;
偏移18h:LoadLibraryA入口地址;
偏移1Ch:GetProcAddress入口地址;
这三个数据用于解析节点所需API的地址。
偏移20h~2Bh:存储节点中频繁调用到的API入口点,避免多次解析,减少性能消耗。
偏移2Ch~33h:存储节点中频繁查询(或加载)的DLL内存基址,避免多次加载,减少性能消耗。
34h和38h:预留的两个单元,以供节点执行过程中存储中间结果。
3.1.2 节点插入位置信息typedef struct Insert_Info
{
struct
{
DWORD dwInsertAddr;//插入位置地址
Byte bIns[];//该处指令
DWORD dwNextInsAddr; //下一条指令地址
} insert_data;
Insert_Info* pNext;
}INSERT_INFO;
依次对程序各个代码片进行节点插入条件判断,利用链表尾插法将符合条件的插入位置以INSERT_INFO形式记录下来,得到节点插入位置信息记录链表。
3.2 节点调度函数设计节点调度函数是负责维护程序代码片执行环境、选择节点、恢复代码片执行环境的函数,其具体实现步骤为:
步骤1 保存各寄存器的当前内容;
步骤2 从栈区获取当前节点插入位置的下一条指令地址next_addr;
步骤3 从节点插入位置信息记录链表中找到dwNextInsAddr等于next_addr的单元,并取其bIns;
步骤4 执行插入位置处的原始指令bIns;
步骤5 分别用伪随机数生成器产生索引并从检测节点地址表、安全性节点地址表、响应节点地址表中选取待执行的节点起始地址;
步骤6 按照检测节点→安全性节点→判断节点→响应节点的顺序,依次转入被选中的节点代码中执行;
步骤7 恢复寄存器内容;
步骤8 执行ret指令返回。
其流程如图 7所示。
步骤1 保存各寄存器当前数据;
步骤2 解析节点所需符号地址;
步骤3 执行核心逻辑;
步骤4 恢复各寄存器内容。图 8为节点实现过程流程。
以用FindWindowA()检测调试器窗口的节点代码为例,说明节点实现的具体情况:
void __declspec(naked) debug_FindWindow
{
_asm
{
//保存执行环境
PUSHFD
PUSHAD
//解析符号地址
PUSH DWORD PTR 0x0041776F//"FindWindowA"
PUSH DWORD PTR 0x646E6957
PUSH DWORD PTR 0x646E6946
LEA EAX,DWORD PTR SS:[ESP]
PUSH EAX
PUSH DWORD PTR DS:[EDI+30h]
//节点Context中User32.dll基址
MOV EAX,DWORD PTR DS:[EDI+1Ch]//GetProcAddress入口地址
CALL EAX //GetProcAddress(User32.dll基址,"FindWindowA")
MOV DWORD PTR DS:[EDI+34h],EAX//FindWindow入口地址存于预留空间1中
OR EAX,EAX
JNE store_ret
JE remain
store_ret: MOV DWORD PTRDS:[EDI+10H],1
//设置检测结果
//恢复执行环境
remain:
ADD ESP,20
POPAD
POPFD
}
}
4 实验分析与评价 4.1 实验环境为了方便表述,这里先介绍两个概念:
文件大小增长率:
$Rat{e_{{\rm{size}}}}\,{\rm{ = }}\,\,{\rm{\Delta }}size{\rm{ / }}size$ | (1) |
指令条数增长率
$Rate{\,_{ins}}\,{\rm{ = }}\,\,{\rm{\Delta }}ins{\rm{ / }}ins$ | (2) |
其中:Δsize和Δins分别表示保护后软件增加的空间大小和执行指令条数;size和ins表示保护前的文件空间大小和执行指令条数。
实验环境:Windows XP SP2操作系统,3.3 GHz CPU,3.4 GB内存,Microsoft Visual Studio2008开发环境,OllyDbg软件分析工具。
本次实验目的是从性能损耗和安全性影响两方面对MTSP系统进行保护效果分析和有效性评价。实验主要分为两部分:1) 选取一系列具有代表性的PE(Portable Executable)文件作为测试用例,用本系统分别对其进行保护,统计保护前后文件大小增长率和所执行的指令条数增长率,对比分析数据变化原因,并对本系统带来的性能消耗作出评价;2) 结合理论分析和抗攻击实验,评价MTSP系统对被保护软件的带来的安全性提升。
4.2 性能评价 4.2.1 测试用例本文选取的测试用例为5个常见的应用程序:计算器Calc.exe、贪吃蛇游戏CSnake.exe、
汉诺塔问题Hanoi.exe(4个盘子)、冒泡排序BubbleSort.exe (2000个随机数)和八皇后问题Queen.exe。
4.2.2 实验过程本次实验将按照如下步骤有序进行:
步骤1 用MTSP系统分别保护上述5个测试用例;
步骤2 分别运行保护后的程序,判断保护前后程序的功能是否发生改变;
步骤3 分别统计保护前、后的文件大小增长率Ratesize和指令条数增长率Rateins;
步骤4 针对不同的威胁类型,设计相应的攻击实例,观察软件是否按照预期的措施来响应处理。
4.2.3 实验数据统计表 2是保护以后文件大小变化的统计结果;表 3是程序执行指令条数变化的统计结果。
1) 空间损耗(文件大小)。
由表 2可知:①保护后的程序文件比保护前会增大;②不同测试用例的文件大小变化是不同的,但是相差基本不太大;③文件大小增长率Ratesize变化不是特别大,这里最大为0.2274。
从整个保护过程来看,文件大小的增加是在重构PE时,在原PE文件中添加了一个存放各基础模块的新节而造成的。该新节的大小主要与3个因素有关:节点库、守护模块、各相关记录结构。由于每个测试用例都嵌入了所有节点,所以节点库不是造成它们Δsize不同的原因;守护模块是固定大小,故也不会导致各个Δsize的差异;因此各相关记录结构主要与被保护程序自身有关,如节点位置插入信息与程序中符合插入条件的基本块数目。从上述典型的测试用例中可以看出保护后程序执行的指令条数变化不是特别大,故MTSP保护对空间的消耗在可接受范围内。
2) 执行时间损耗(指令条数)。
从表 3可知:①保护后程序执行的指令条数比保护前会增大;②不同测试用例的指令条数变化是不同的,且差异较大;③文件大小增长率Rateins变化不是特别大,这里最大为0.3431。
威胁监控造成指令条数增加的原因是在程序代码段中部署了若干个节点以及“加载时释放安装”驱动守护模块。由于处理驱动守护模块所执行的代码量是一样的,故这块不会引起Δins的不同;而因节点引起的指令条数变化主要与:符合节点插入条件的基本块个数、所插入基本块自身的循环次数、随机选中节点自身的指令条数这三个因素有关。其中,前两个因素和程序自身结构有关,而节点自身规模虽然略有不同但几乎都在50条指令数的范围左右,对Δins影响不是很大。所以,符合节点插入条件的基本块个数和所插入基本块自身的循环次数这两个因素是导致Δins不同的主要原因。
4.3 安全性分析为了验证MTSP系统能达到预期的保护效果,本节通过对MTSP保护前后的程序做相关的逆向攻击实验来评价该方案的有效性。本文所提供的攻击实例分为两类:第一,由于API安全属性与程序自身的安全性息息相关,因此有必要对API安全属性隐藏的安全性进行分析,实验中分别用Dependency Walker、API Monitor提取监视API 安全属性,观察所得结果;第二,基于外部攻击威胁的安全性分析,分别使用调试和篡改攻击实例的实验结果来阐释系统的保护效果。
4.3.1 API安全属性隐藏的安全性分析使用PE文件导入符号查看工具Dependency Walker查看经过MTSP保护前后的CSnake.exe导入信息,对比结果如图 9所示。
从对比中可以看出MTSP能够很好地隐藏PE文件的导入信息。
API Monitor 能够对用户指定的API进行监视。图 10是监视CSnake.exe中GetVersion()和MessageBoxA()保护前后的结果的对比。
从对比中可以看出,对于保护前的程序,API Monitor可以截获到API名字、参数、返回值这些属性,而保护后的软件无法提出任何属性。
综上所述,由于安全属性的隐藏,上述的工具不能从保护的程序中提取出API函数名称、参数、返回值以及API执行流等内容,因此很难达到攻击的目的。也就是说MTSP能够在一定程度防止软件遭受恶意逆向分析从而提升软件自身安全性。
4.3.2 威胁监控节点的安全性分析1) 调试威胁。
用OllyDbg载入CSnake.exe保护后的程序,记录节点Context的初始内容,如图 11所示。
①号框标注的数据为检测结果标志,初值为0;而②号标注的三个数据依次为GetModuleHandleA()、LoadLibraryA()、GetProcAddress()的IAT地址。
当驱动守护模块安装好后,程序发送器将目标进程id传递给驱动,这时守护模块就开始扫描目标进程是否处于调试环境中,待检测结束后,驱动会将检测结果传回给接收器,接收器根据收到的检测结果设置节点Context里的检测结果标志。效果如图 12所示。
图 12中:标注的①号框中检测结果标志被设置为1;②号标注变为对应三个函数的入口地址;③号为三个常用的API入口地址;④号的两个标注为常用的两个DLL(kernel32.dll与user32.dll)基址。这时判断节点发现标志被设置了,并立即选取一种响应节点执行。
2) 篡改威胁。
通常,攻击者为了优先获取程序执行权,会将程序入口指令替换为一条转入到恶意模块的跳转指令。因此,MTSP系统将程序入口处代码作为完整性校验对象之一。CSnake.exe(不选加载守护模块Protect.sys保护选项)入口代码如图 13所示。
OllyDbg载入程序后,手动修改426C0F处的指令,如图 14所示。
程序继续向下执行,篡改行为将会被检测到,节点Context的检测结果标志被置为1,本次选取的响应方式为调用ExitProcess()直接退出程序,如图 15所示。
综上所述,该方案能够在一定程度上对软件执行过程中受到的攻击威胁进行实时监测,确保软件处于在一个安全的执行环境中运行,提高逆向分析的难度。
5 结语本文提出了一种基于攻击威胁监控的软件保护方法MTSP。通过对软件执行过程中潜在的攻击威胁进行分析描述,设计威胁监控节点,部署威胁监控网,从而达到对软件执行环境实时监测的目的。通过实例实验,表明本文方法能够在一定程度上提高软件的安全性,抵御软件的逆向分析并且其性能开销在可接受范围。
总体上,本文提出的方法用于监控软件执行过程中的攻击威胁很有意义,但仍然存在一些需要进一步思考和完善的问题:1) 该方案自身的安全性,即对该方案自身要进行适度的保护,避免因该方案的引入给软件造成新的攻击威胁,产生新的攻击点。虽然本文已对此问题有了一些解决方案,如通过“加载时释放安装”策略防止驱动守护模块被发现去除,设计安全性节点校验节点自身完整性防止其被破坏。但是对方案自身整体的安全性依然分析得不够,因此,在后面的研究过程中,需要深入分析MTSP功能模块的局限性和薄弱点,并提出合理的方法来提升该保护方案自身的安全性。2) 平台的兼容性。文中驱动守护模块与平台类型有关,因此需要对MTSP原型系统中的这两部分内容不断完善更新,确保原型系统能够在多个Windows平台上使用。
[1] | Microsoft official website of SDL. Microsoft security development lifecycle[EB/OL].[2016-05-02] . http://www.microsoft.com/security/sdl/default.aspx. |
[2] | GU Y X. Software security patterns:white-box attack analysis and software protection technology[C]//Proceedings of the 1st International ACM Summer School on Information Security and Protection Theme on Software Security and Protection. New York:ACM, 2010:7. |
[3] | COLLBERG C. Surreptitious Software:Obfuscation, Watermarking, and Tamper Proofing for Software Protection[M]. 3rd ed. Beijing: Posts & Telecom Press, 2012 : 43 -44. |
[4] | 黄山.基于动态二进制程序切片技术的软件攻击诊断[D].上海:上海交通大学,2012:25-39. ( HUANG S. Attack diagnosis on binary executables using dynamic program slicing[D]. Shanghai:Shanghai Jiao Tong University, 2012:25-39. ) |
[5] | 张璇, 廖鸿志. 基于信息熵和攻击面的软件安全度量[J]. 计算机应用, 2013, 33 (1) : 19-22. ( ZHANG X, LIAO H Z. Software security measurement based on information entropy and attack surface[J]. Journal of Computer Applications, 2013, 33 (1) : 19-22. doi: 10.3724/SP.J.1087.2013.00019 ) |
[6] | 诸葛建伟, 唐勇. 蜜罐技术研究与应用进展[J]. 软件学报, 2013, 24 (4) : 825-842. ( ZHUGE J W, TANG Y. Honeypot technology research and application[J]. Journal of Software, 2013, 24 (4) : 825-842. ) |
[7] | 武少杰, 鹤荣育. 软件哨兵安全动态检测模型的研究与实现[J]. 计算机应用研究, 2012, 29 (8) : 3008-3011. ( WU S J, HE R Y. Study and implementation of software guards' security dynamic testing model[J]. Application Research of Computers, 2012, 29 (8) : 3008-3011. ) |
[8] | 余艳玮, 赵亚鑫. 基于三线程保护和软件哨兵的防篡改技术[J]. 计算机应用, 2013, 33 (1) : 1-3. ( YU Y W, ZHAO Y X. Tamper proofing technique based on three-thread protection and software guard[J]. Journal of Computer Applications, 2013, 33 (1) : 1-3. doi: 10.3724/SP.J.1087.2013.00001 ) |
[9] | The official website of Themida. Oreans technology:software security defined[EB/OL].[2016-01-20] . http://www.oreans.com/themida.php. |
[10] | The official website of SafeEngine. Safengine[EB/OL].[2015-12-14] . http://www.safengine.com/downloads/get-demo. |
[11] | DT Protect官方网站.动态变形壳DTProtect V1.018免费版[EB/OL].[2015-10-21] . http://www.dtdishui.com/a/chanpinzhanshi/3/2014/0423/42.html. ( The official website of DT Protect. Dynamic deformation shell:DTProtect V1.018 for free[EB/OL].[2015-10-21] . http://www.dtdishui.com/a/chanpinzhanshi/3/2014/0423/42.html. ) |
[12] | TenProtect.腾讯的TenProtect系统-网络安全-中国红客联盟-Powered by HUC[EB/OL].[2015-08-01] . http://www.cnhonkerarmy.com/thread-175642-1-1.html. ( TenProtect. TenProtect system-network security-Chinese hacker union-Powered by HUC[EB/OL].[2015-08-01] . http://www.cnhonkerarmy.com/thread-175642-1-1.html. ) |
[13] | 王瑾榕.基于攻击知识库的软件攻击自动化建模研究与实现[D].西安:西北大学,2014:33-35. ( WANG J R. Research and implementation of software attack automated modeling based on attack knowledge base[D]. Xi'an:Northwest University, 2014:33-35. ) |