基于行为的IE浏览器的恶意代码自动检测及分析系统.doc
- 文档编号:18783668
- 上传时间:2023-11-12
- 格式:DOC
- 页数:15
- 大小:724KB
基于行为的IE浏览器的恶意代码自动检测及分析系统.doc
《基于行为的IE浏览器的恶意代码自动检测及分析系统.doc》由会员分享,可在线阅读,更多相关《基于行为的IE浏览器的恶意代码自动检测及分析系统.doc(15页珍藏版)》请在冰点文库上搜索。
2008年全国大学生电子设计竞赛信息安全技术专题邀请赛
作品设计报告
作品题目
基于行为的IE浏览器的恶意代码自动检测及分析系统
参赛学校
北京邮电大学
参赛队员
马哲
范翔宇
朱殊
指导教师
崔宝江
注:
作品设计报告的内容主要包括:
系统方案、功能与指标、实现原理、硬件框图、软件流程;系统测试方案、测试设备、测试数据、结果分析、实现功能、特色;应用资料与参考文献目录;附录部分,含源代码和程序清单,扩展应用系统电路图等。
目录(一级)
系统方案3
功能与指标3
实现原理4
1.监控模块4
2.数据库存储模块8
3.分析模块9
软件流程11
系统测试方案12
测试设备12
测试数据12
结果分析13
实现功能13
软件特色13
附录14
参考资料14
源代码及程序清单14
系统方案
随着网络的发展,每年近些年来,恶意代码依赖一些特殊的NativeAPI函数和内核系统函数进行感染、传播、隐藏的这种趋势愈加明显,并大量的使用了多重加密壳、驱动关联壳、变形壳等代码保护机制和多态、变形等新的技术,给恶意代码的检测带来更大的困难;目前主流的恶意软件检测技术依然是以基于特征码的检测法为主的,这种方法在速度上确实有优势,但是其缺点也是非常明显的:
新病毒特征码的提取速度要落后于病毒的传播,而且无法检测到那些在运行过程中能够进行多态变形的恶意代码。
有些软件可以检测出恶意代码并报警,但如果想要知道恶意代码具体的行为,还要依靠手工分析恶意代码,工作量是很大的。
本软件针对Windows平台下的Web浏览器(IE),旨在应用更有效的网页恶意代码检测方法,实现对浏览器的保护,并生成详细的行为分析报告。
本软件通过监视浏览器调用的系统API函数的相应参数,将其存入数据库,并与规定好的行为知识库进行匹配,判断代码的性质和行为,如果有恶意倾向,就阻止该API函数的调用,从而保护宿主,保护PC机的安全,同时生成较直观的恶意代码行为分析报告,包括恶意代码对本地文件、网络、注册表及插件加载等的操作。
功能与指标
功能概述:
本软件是一款基于行为的网页恶意代码监控和分析系统;主要应用于监视并检测网页中的恶意代码,保护Windows平台下的Web浏览器(IE)。
用户如果需要浏览网页,先开启本产品,选择需要监视的浏览器(目前实现的产品版本针对于IE和Firefox),并选择需要的安全级别,就可以进行正常的网页浏览了,当所浏览的网页有恶意行为时,本产品会提示并阻止对恶意网页的继续访问或自动关闭浏览器,实现对PC的保护。
同时,软件还可以生成相应的行为分析报告,以供用户进一步分析。
由于采用基于行为的检测方法,并将监测数据录入数据库,在数据库中与事先制定的行为库进行查询匹配,本产品在监控网页恶意代码方面,具有误报率低、使用方便、查询速度快等优点,并且可以生成直观的分析报告,便于查看,同时随着恶意代码样本的积累,可以随时对行为库进行更新和扩大,使本产品的应用范围得到更好的拓展。
具体指标:
本软件可对本地文件、网络活动、注册表和插件加载等方面进行监控,并记载监控数据,也可生成直观的分析报告。
具体指标如下:
1.对本地文件的监控:
包括访问的文件名称、文件路径、对文件的操作、开始时间和具体操作等。
2.对网路活动的监控:
记录此次访问的本地IP地址、利用的本地端口、目标IP地址、目的端口、状态、开始时间、使用协议、数据等。
3.对注册表的监控:
包括键值名、键值类型、键值内容和操作类型等。
4.对插件加载的监控:
记录进程名称、进程ID、进程路径、状态、开始时间和进程所占用的内存空间。
实现原理
该产品主要分为监控模块,数据库存储模块,分析模块三个大部分。
产品的工作原理和各模块间关系如图一所示:
监控
规则
分析
结果
监控
命令
分析
结果
软
件
界
面
待监控软件-InterenetExplore
软件行为
存
储
模
块
监控
数据
监控
模块
监控
规则
用
户
分析
模块
结果
报表
quotefromthedocumentorthesummaryofaninterestingpoint.Youcanpositionthetextboxanywhereinthedocument.UsetheTextBoxToolstabtochangetheformattingofthepullquotetextbox.]
监控数据
匹配规则
图一
1.监控模块
在监控模块中,我们要分别实现对进程加载、注册表、本地文件和网络方面的监控。
下面一一介绍各个方面的监控原理。
1.1监控机制
1.对进程信息的控制
windows操作系统给我们提供了两套公开的API函数来获得进程信息:
一套是PSAPI,通过EnumProcesses()函数来枚举进程,另一套是ToolHelp32,通过Process32First()和Process32Next()函数来获得整个进程列表.现在运行在用户层的恶意代码一般都会让自己在系统进程列表中消失,原理是HOOK上述进程相关API函数,将自身进程从最后的进程列表中去除,但这样做一般很容易发现。
如图2所示,PSAPI和ToolHelp32都是通过调用位于ntdll.dll中的一个nativeAPI函数NtQuerySystemInformation()获取进程信息,而函数NtQuerySystemInformation()是依靠内核函数ExpGetProcessInformation()遍历ActiveProcessLinks,通过EPROCESS结构(其中包含ActiveProcessLinks项,类型为LIST_ENTRY)获得真实进程列表信息。
整个环节中,内核态的恶意代码可以试图通过HOOK函数NtQuerySystemInformation()和函数ExpGetProcessInformation(),将自己的相关进程从返回结果中去除或者直接从ActiveProcessLinks摘除自身相关进程信息,即要把要隐藏的进程的EPROCESS从LIST_ENTRY中摘除。
2.对文件和注册表信息的控制
内核恶意代码往往要对自身宿主文件和所在目录进行隐藏,达到保护自身的目地。
在NT内核操作系统中,与文件和目录相关的API函数基本上都是调用ntdll.dll中的几个NativeAPI函数NtQueryVolumeInformationFile、NtQueryDirectoryFile、NtCreateFile、NtVdmControl(对应内核态下为ZwQueryVolumeInformationFile、ZwQueryDirectoryFile、ZwCreateFile、ZwVdmControl),因此许多内核级的恶意代码基本上都会HOOK上面的这些函数。
我们以HOOK函数ZwQueryDirectoryFile为例来阐明实现的基本原理:
自己定义一个HookZwQueryDirectoryFile函数来处理一个名为alice的文件名,调用老的ZwQueryDirectoryFile获取真实文件和目录信息列表,然后在这个文件和目录信息列表中删除我们要隐藏的“alice”相关信息,最后将加工后的结果返回。
对注册表的信息的控制也是采用同样的方法,对ntdll.dll中的NtEnumerateKey、NtEnumerateValueKey或者它们的内核版本ZwEnumerateKey、ZwEnumerateValueKey进行HOOK实现隐藏注册表。
//示例程序:
自定义HOOK函数
ZWQUERYDIRECTORYFILEpOldZwQueryDirectoryFile;//定义指向ZwQueryDirectoryFile函数的指针
NTSTATUSNTAPIHookZwQueryDirectoryFile(
INHANDLEFileHandle,
INHANDLEEventOPTIONAL,
INPIO_APC_ROUTINEApcRoutineOPTIONAL,
INPVOIDApcContextOPTIONAL,
OUTPIO_STATUS_BLOCKIoStatusBlock,
OUTPVOIDFileInformation,
INULONGFileInformationLength,
INFILE_INFORMATION_CLASSFileInformationClass,
INBOOLEANReturnSingleEntry,
INPUNICODE_STRINGFileNameOPTIONAL,
INBOOLEANRestartScan)
{
NTSTATUSdwStAtus;//返回状态
PFILE_BOTH_DIRECTORY_INFORMATIONlpInfo;//定义一个文件目录信息结构
//调用老的ZwQueryDirectoryFile获取文件和目录信息列表
dwStAtus=pOldZwQueryDirectoryFile(FileHandle,
Event,
ApcRoutine,ApcContext,IoStatusBlock,FileInformation,FileInformationLength,FileInformationClass,ReturnSingleEntry,FileName,RestartScan);
//以下在文件和目录信息列表中“过滤”我们要隐藏的“alice”,将加工后的结果返回
if(FileInformationClass==FileBothDirectoryInformation)
{
if(dwStAtus==STATUS_SUCCESS)
{
lpInfo=(PFILE_BOTH_DIRECTORY_INFORMATION)FileInformation;//文件信息存在lpInfo结构
if(RtlCompareMemory(lpInfo->FileName,L"alice",10)==10)
{
if((ULONG)(lpInfo->NextEntryOffset)!
=0)
{
FileInformationLength-=(ULONG)(lpInfo->NextEntryOffset);
RtlCopyMemory(lpInfo,
(PFILE_BOTH_DIRECTORY_INFORMATION)((ULONG)lpInfo+(ULONG)(lpInfo->NextEntryOffset)),
FileInformationLength-(((ULONG)lpInfo+(ULONG)(lpInfo->NextEntryOffset))-(ULONG)FileInformation));}
Else
{
FileInformationLength-=(ULONG)(lpInfo->NextEntryOffset);
returndwStAtus;
}
//此时返回状态码STATUS_NO_SUCH_FILE;
}
do{
if(RtlCompareMemory(lpInfo->FileName,L"alice",10)==10)
{
if((ULONG)(lpInfo->NextEntryOffset)!
=0)
{FileInformationLength-=(ULONG)(lpInfo->NextEntryOffset);
RtlCopyMemory(lpInfo,(PFILE_BOTH_DIRECTORY_INFORMATION)((ULONG)lpInfo+(ULONG)(lpInfo-NextEntryOffset)),FileInformationLength-
(((ULONG)lpInfo+(ULONG)(lpInfo->NextEntryOffset))-(ULONG)FileInformation));}
Else
{FileInformationLength-=(ULONG)(lpInfo->NextEntryOffset);
break;}
continue;
//此时返回状态码STATUS_NO_SUCH_FILE;
}
if(lpInfo->NextEntryOffset!
=0)
{lpInfo=(PFILE_BOTH_DIRECTORY_INFORMATION)((ULONG)lpInfo+(ULONG)(lpInfo->NextEntryOffset));}
}while(lpInfo->NextEntryOffset!
=0);
}
}
returndwStAtus;
}
对应的在恶意代码驱动程序入口DriverEntry()也要做相应的处理,通过修改系统服务信息表将系统对ZwQueryDirectoryFile的调用指向对HookZwQueryDirectoryFile的调用,完成HOOK过程.
…
//利用pOldZwQueryDirectoryFile指向原有函数ZwQueryDirectoryFile
pOldZwQueryDirectoryFile=(ZWQUERYDIRECTORYFILE)(
KeServiceDescriptorTable->ntoskrnl.ServiceTable[*(PULONG)((PUCHAR)ZwQueryDirectoryFile+1)]);
_asm//嵌入汇编模式,取消写保护
{
PUSHEAX
CLI//禁止中断
MOVEAX,CR0//将CR0中写到EAX寄存器
ANDEAX,NOT10000H//禁止WP标志位
MOVCR0,EAX//写回CRO
POPEAX
}
KeServiceDescriptorTable->ntoskrnl.ServiceTable[*(PULONG)((PUCHAR)ZwQueryDirectoryFile+1)]=(ULONG)HookZwQueryDirectoryFile;//将原来的ZwQueryDirectoryFile调用指向我们自定义的函数.
_asm//恢复写保护
{
PUSHEAX
MOVEAX,CR0//将CR0中写到EAX寄存器
OREAX,10000H//恢复WP标志位
MOVCR0,EAX//写回CRO
STI//允许中断
POPEAX
}
3.对系统服务和网络信息的控制
对系统服务的控制主要是针对advapi32.dll的四个系统函数EnumServiceGroupW、EnumServicesStatusExW、EnumServicesStatusExA、EnumServicesStatusA进行HOOK,过滤掉返回结果中的恶意代码启动的服务信息,原理和前面的文件信息控制几乎是一样的。
对网络信息的控制方法更多,比如在TDI层次上进行拦截,TDI导出了两个设备“\\Device\\Tcp”与“\\Device\\Udp”,内核恶意代码用设备过滤驱动的方法把这两个设备的所有IRP包接管过来进行处理后再传给下层驱动,这样可以达到以达到隐藏任意端口的目的。
在NDIS驱动层上进行拦截,恶意代码自己处理自身远程控制用的封包。
最后,基于以上各部分的监控原理,我们API监控原理可总结如下。
在Windows中,系统功能一般都是通过DLL里的API提供,因此只要挂接进程的API(尽量挂接RING0层的API,如果挂接RING3层的API将有可能被绕过),就可以知道一个进程将有什么动作。
其通过静态分析确定软件中产生系统调用的位置(虚拟地址),然后再监视软件运行并验证所有观察到的系统调用都是从静态分析时获得的地址处产生的。
我们通过使用Detours包[1]中提供的直接修改的方法,即在载入期间改造包含调用Win32 API的DLL的方法来实现对API函数的监控。
通过直接修改每个Win32 API调用的入口点,所有的Win32 API调用都可以监视到。
载入期间修改DLL文件我们能够有选择的监视可执行文件。
具体的说,使用Detours修改了API后,当 进程产生一个对API函数的调用时,该API函数地址的第一条指令已经是一个指向Detours外壳的条件跳转。
外壳可能会先执行一段初步处理代码,然后再将控制权交给Win32 API函数体。
Win32 API函数执行完毕后会再次返回Detour,这时可以再执行一段后处理代码,然后再将控制权交还给调用者。
初步处理代码处,监控模块就可以验证Win32 API函数调用信息是否与初步处理的信息相同。
Malanalyser通过分析恶意代码的行为,确定调用Win32 API的指令。
这些指令的地址和API函数名会被记录下来。
我们还要记录Win32 API调用后面的那句指令的地址,也就是Win32 API调用的返回地址,当调用要返回时,这些地址应该出现在堆栈的最顶端。
通过这样的识别机制,我们就区分出了运行期间正常的Win32 API调用和恶意代码的Win32 API调用。
即这种识别机制应该能够找到正常编译器生成的代码产生的Win32 API调用,忽略那些有意隐藏自身的调用。
设计这样一种识别机制是比较易行的,因为正常代码对Win32 API的调用方式与有意混淆自己代码对Win32 API的调用方式有着明显的不同。
1.2保护机制
在软件运行期间监视软件对Win32 API的调用,当一个Win32 API被调用的时候,确定产生调用的指令和该指令在文件中的地址. 然后,验证这个指令的地址和所调用的API函数名称时候是否与初步处理过程中得到的地址一致. 如果发现不一致,则发出警告,这时,系统就可以通过阻挡该API调用保护宿主。
2.数据库存储模块
本模块用于数据存储,具体的存储内容包括以下三部分:
1).监控模块所返回的API函数及相关的网络和本地活动的参数;
2).行为库,即恶意行为的判定规则;
3).注释表,注明各表间的联系及对各表的注释,使系统更具可读性及可扩展性。
数据库系统通过数据库管理系统(DataBaseManagementSystem,简称DBMS)对数据进行管理,它是数据库系统的核心组成部分,我们对数据库系统的一切操作,包括定义、查询、更新以及各种控制,都是通过数据库管理系统进行的。
DBMS的工作模式如下:
接受应用程序的数据请求和处理请求。
将用户的数据请求(高级指令)转换成复杂的机器代码(低层指令)。
实现对数据库的操作。
从对数据库的操作中接受查询结果。
对查询结果进行处理(格式转换)。
处理结果返回给用户。
建立数据库系统离不开数据模型。
模型是对现实世界的抽象,在数据库技术中,我们用模型的概念描述数据库的结构与语义,对现实世界进行抽象。
能表示实体类型及实体间联系的模型称为“数据模型”。
数据模型的种类很多,目前被广泛使用的可分为两种类型。
一种是独立于计算机系统的数据模型,完全不涉及信息在计算机中的表示,只是用来描述某个特定组织所关心的信息结构,这种模型称为“概念数据模型”。
概念模型是按用户的观点对数据建模,强调其语义表达能力,概念应该简单、清晰、易于用户理解,它是对现实世界的第一层抽象,是用户和数据库设计人员之间进行交流的工具。
其典型代表就是著名的“实体-关系模型”;另一种数据模型是直接面向数据库的逻辑结构,它是对现实世界的第二层抽象。
这种模型直接与数据库管理系统有关,称为“逻辑数据模型”,包括层次模型、网状模型、关系模型和面向对象模型。
逻辑数据模型应该包含数据结构、数据操作和数据完整性约束三个部分,通常有一组严格定义的无二义性语法和语义的数据库语言,人们可以用这种语言来定义、操作数据库中的数据。
在本软件的数据模块中,我们采用概念数据模型。
具体的说就是著名的“实体-关系模型”(E-R模型),是用户和数据库设计人员之间进行交流的工具,在设计数据库系统之前,我们需要使用E-R图将现实世界中的实体和实体之间的联系转换为概念模型。
E-R模型的基本元素是:
实体、属性和联系。
实体(entity)是一个数据对象,指可以区别客观存在的事物,如人、部门、表格、项目等。
同一类实体的
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 基于 行为 IE 浏览器 恶意代码 自动检测 分析 系统