本文主要是介绍基于VMM的Rootkit检测技术及模型分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
Linux通过其特有的虚拟文件系统(Virtual Filesystem)实现对多种文件系统的兼容。虚拟文件系统又称虚拟文件系统转换(Virtual Filesystem Switch vFs)，是一个异构文件系统上的软件粘合层，为访问文件系统的系统调用提供一个统一的抽象接口。VFS采用标准的Unix系统调用读写，位于不同物理介质上的不同文件系统，使open()、read()、write()等系统调用不用关心底层的存储介质和文件系统类型。基于VFS的Rootkit可以有效的绕过安全检测工具的检测，通过对Linux下文件系统操作指针的修改实现隐藏功能，该类型经典Rootkit为adore—ng。以系统调用getdents64为例，该系统调用用于目录获取，其执行过程实际上是调用vfs—readdir()函数完成功能，vfs—readdir()则是通过Linux下文件对象的操作函数结构体f_op中的readdir()获取目录。readdir()函数是在文件或目录打开时由Linux根据该目录的文件系统类型进行赋值的，如果当前目录为ext2文件系统，则通过ext2一
file— operations(ext2文件操作结构体)将readdir()函数赋给索引节 inode，再由inode赋值给文件对象。Adore—ng的VFS函数劫持代码如下，打开一个目录或文件，通过其文件对象结构体file中的f—op变量获取readdir()函数指针，并将自己的目录读取函数new_readdir()赋给文件对象，从而实现劫持。由于Linux在文件对象赋值过程中均采用指针操作，该操作实际上替换的是ext2一file—operation中的readdir()函数，因此进行readdir()替换后，任意目录和文件的读取操作都将由adore—ng提供的new_readdir()执行。在new_ readdir()中可以对指定的目录或文件进行过滤，从而实现隐藏的目的。
int patch_ vfs(const char P，readdir_t orig_ readdir，readdir_
t new
_ readdir)
{
stnict file filep；
filep=filp
_ open(p，O_RDONLY，0)
if(IS—ERR(filep))
return一1：
if(orig_ readdir)
orig_ readdir=filep->f_ op->readdir；
filep。 f
_ op。>readdir new_ readdir；
filp_ close(filep，O)；
retum0：
}
随着虚拟化技术的发展，基于VMM的Rootkit检测技术得到了广泛关注。基于VMM的Rootkit检测护技术不同于传统的基于主机内部的检测技术，由于在VMM中无法获取操作系统的完整视图，因此为检测带来了很大难度。随着这方面技术的深入研究，基于语义重构和基于系统完整性的Rootkit
检测技术被相继提出并日趋成熟。
在虚拟化环境下，VMM与客户虚拟机之间被隔离。这种隔离机制为VMM提供了安全的环境，但同时也给基于VMM的Rootkit检测带来更大的挑战。VMM的可观测视图仅仅包括内存、10操作等低级别视图，而无法获取客户虚拟机中关于进程、模块等高级视图信息。这种视图级别的差距导致了语义断层的出现，为了消除语义断层，基于VMM的Rootkit检测技术采用语义重构对高级视图进行恢复，进一步使用交叉视图进行检测。 交叉视图分析是目前针对Rootkit的一种有效的检测方法。该方法基于可信视图与感染视图的对比分析，找到隐藏或是可疑的Rootkit信息，从而实现对Rootkit的检测。在基于
VMM的Rootkit检测过程中，可信视图主要通过语义重构获取，感染视图则在客户虚拟机中通过shell命令获取。目前基于VMM的Rootkit检测技术侧重于进程信息的重构，具体重构方法主要包括以下四种。
1)task—list链表重构
Payne Bryan D等人提出了重构task—list链表的方法并实现了开源函数库Xenaccess 。该方法通过System．map中获取Linux导出符号init—task的线性地址。该符号表征task— list进程链表中首元素的地址。task—list属于内核数据，通过对swapper—Pg—dir内核页全局目录表及相应页表的查询，获取其对应机器地址，从而遍历链表恢复出当前系统的进程信息，包括ID、进程名等。该方法原理简单，在遍历进程过程中，需要提前根据客户虚拟机内核版本，获取task—struct结构体中指定变量的偏移量，从而获取数据值。由于客户虚拟机的内核数据信息处于该虚拟机的内存空间中，因此在重构时，需要将该部分内存映射到控制域中，该过程通过VMM的指定接口实现。
2)CPU可运行队列重构
针对基于task—list链表的重构方法在DKOM类Rootkit检测方面的不足，王丽娜、高汉军等人提出了基于CPU可运行队列的重构方法[81o Linux内核为每个CPU维护一个runqueue数据结构，用于存储该CPU的调度信息。该方法同样利用System．map获取per_cpu—runqueues和per_cpu—offset的线性地址，通过相加获取runqueue结构体地址。runqueue结构体中的active指向prio—array_t结构体，prio—array_t根据进程等级分为140个队列。通过遍历该运行队列，可恢复出
当前系统的进程列表。该方法的好处是对于DKOM类Rootkit检测效果明显。DKOM类Rootkit会进行断链操作，从而让进程从task—list中消失，使常规检测方法失效。然而，进程要运行必须进入CPU
运行队列进行等待，因此对于runqueues重构的信息可信等级更高。
3)系统调用劫持
Xuxian J等人提出了基于系统调用劫持的语义信息重构方
法 0。该方法通过将快速系统调用中的SYSENTER—EIP—MSR
寄存器值进行修改，使系统调用过程中出现页错误，从而进入缺页异常处理程序。通过修改缺页异常处理程序，根据错误信息判断系统是否在创建或删除进程，若是则通过VMCS获取ESP地址，进而获取threadinfo结构体。threadinfo结构体中包含指向task—struct结构体指针，从而恢复创建或删除进程的信息。该方法的优势在于可以实时监控系统内部进程，可以解决针对短时间运行的恶意或隐藏进程的检测问题。另外，由于该方法不涉及任何内核数据偏移量，因此可以简单地应用于多种内核版本，适用范围广实用性强。
4)CR3寄存器信息重构
SteDhen T．Jones等人提出了基于CR3寄存器信息重构的方法[101。在Linux操作系统中，CR3寄存器用于存储系统页目录指针，页目录指针指向进程页目录表，用于完成从线性地址到物理地址的转换工作。由于不同进程的内存空间不同，不同的进程也都有不同页目录表指针，通过监测CR3寄存器
的值，一段时间内，若出现新的CR3值，则证明有新的进程创建；若已存在的CR3值消失，则证明该进程已被删除。当判断新进程创建后，根据ESP指针获取threadinfo结构体。该方法基于VMM层进行重构，重构的可信视图信息可信度高。该方法需要基于时间维进行对比方可发现进程的创建与删除，因此其实现难度较大。由于CR3寄存器的监测要对VMM内核进行适当修改，且进程切换在系统内操作频繁，因此会影响虚拟环境的运行效率。
2．2系统完整性
基于语义重构的Rootkit检测技术通过Linux系统导出符号定位关键数据结构的内存位置，然而由于恶意代码的影响，系统导出符号有可能会出现错误，从而导致语义重构失败基于完整性检测的Rootkit检测技术检测可执行文件、内核控制流程的完整性，其检测效果明显，但是由于该技术多涉及内核修改，因此会带来较大的性能损失。李博等人通过虚拟环境下的系统调用劫持，辨识可执行文件的执行『1”。Linux的可执行程序在加载之前，会调用open系统调用打开文件，其中函数open()的第一个参数为所打开文件的路径。在获取文件路径后，通过对Linux文件系统布局的分析，重构文件系统元数据，并从磁盘中找到文件镜像，通过哈希值计算及对比分析，检测可执行文件的完整性。Grizzard提出一种内核控制流的完整性检测方法。该方法重写目标操作系统内核，使所有内核控制流分支均陷入到 VMM内核中。在VMM内核中，通过与预先训练获得的控制流图进行对比分析，从而检测控制流程的完整性。该方法对于内核工作效率影响大，经实验，其性能损失约在30％。Hai Jin等人在Xen平台利用其用户层驱动blktap实现文件完整性检测[121~Xen中的控制域Dom0包含所有10操作的原生驱动，客户虚拟机中的所有10操作均通过10环通知控制域中的Blktap进行执行。该方法通过劫持Blktap驱动，劫持客户虚拟机的文件操作，并通过哈希值对比检测文件完整性。该方法检测覆盖范围广但对于正常的文件修改容易产生误报。
2．3检测技术的综合分析
基于语义重构和基于系统完整性的检测技术从不同的角度对Rootkit进行检测。基于语义重构的检测技术侧重于恢复内存中关键数据结构信息或根据相关寄存器事件判断客户虚拟机中的行为；基于系统完整性的检测技术则通过哈希值对比分析文件是否遭到恶意修改，或通过数据分析方法检测内核控制流的一致性。在实际应用中往往将二者结合，如李博等人提出的基于VMM的可执行文件完整性检测技术，首先通过语义重构技术截获系统调用，恢复出文件绝对路径，再进行下一步的完整性检测工作。
针对语义重构技术的四种不同方法，由于其对于实现细节依赖性很大，因此只在适用范围、实现复杂性以及可信视图安全等级三方面进行简要对比分析。在适用范围方面，系统调用劫持和CR3寄存器信息重构适用于不同的操作系统内核版本，而CPU运行队列及task—list的信息重构技术则要依赖于目标操作系统的内核偏移量信息，因此其灵活性相对较差。在实现复杂性方面，task—list信息重构相对简单；CPU运行队列重构虽然原理简单，但由于CPU进程调度频繁，因此其在实现过程中会遇到进程遍历不全的情况；对于系统调用劫持和CR3寄存器信息重构两种方法，其均需要修改VMM内核，实现复杂度较高。
在可信视图安全等级方面，CR3寄存器信息重构属于VMM层信息，可信度最高；系统调用劫持、CPU可运行队列以及task—list均属于VM内核层信息，其可信度相对较低。其中task—list信息的安全等级最低，对于直接操作内核对象类Rootkit(Direct Kernel Object Manipulation，DKOM)其无法进行检测。
3基于VMM的Rootkit检测模型
近些年，基于VMM的Rootkit检测模型成为研究热点。根据检测模型的特点及相应检测原理可分为“In—VM”、“In—VMM”和“In—Host”模型。
3．1“ln—VM”模型
“In—VM”模型指在客户虚拟机VM中安装相应检测模块的Rootkit检测模型。该模块通常置于目标VM的内核中，通过VMM的接口与其他模块进行通信。基于该种模式的Rootkit检测模型主要有Lares等。Lares是由佐治亚理工的Bryan D．Payne等人于2008年开发[13]o Lares在VM内安装驱动程序Hookdriver．sys，该驱动程序实现对于VM的安全监测，并通过通信模块trampoline利用Xen平台的超级调用HyperCall将检测信息传入系统其他模块。为了实现对Hookdriver驱动程序的保护，在VMM层实现内存保护模块，将驱动程序所在的内存设置为不可写状态，从而实现驱动程序完整性保护。
3．2“In—VMM”模型
“In—VMM”模型不在VM内添加任何额外的模块，但修改VMM内核实现检测功能。基于该种模式的Rootkit检测模型主要有VMDetector和ComMon等。VMDetector是由Ying Wang、Chunming Hu和Bo Li于2011年开发[14]0 VMDetector结合硬件虚拟化技术，基于系统调用劫持和CR3寄存器信息重构技术，修改VMM内核中缺页异常处理程序，监测CR3及进程创建事件，获取隐藏进程的可信视图，并根据交叉视图分析，检测出Rootkit的存在，并恢复出其详细信息。该模型同时还支持隐藏连接的交叉视图分析。
ComMon是由Guofu，X．等人于2012年开发051 0 ComMon 是一个综合的Rootkit检测架构，其同样利用系统调用劫持技术修改VMM内核，当劫持相关文件操作的系统调用时，则通过task—struct中files—struct的fdtable恢复出当前操作的文件，并根据系统调用参数恢复文件的路径，从而提供文件检测功能。
3．3“In—Host”模型
“In—Host”模型不同于前两种模型，不存在任何模块位于VMM或VM内，其检测模型完全处于Host(控制域)内部。基于该种模式的Rootkit检测模型主要有XenPHD和XenAccess等。XenAccess是由佐治亚理工大学的Bryan D．Payne等人开发的基于Xen平台的语义重构及隐藏进程检测的开源库；
XenPHD是由王丽娜等人研发的Xen平台隐藏进程检测系统。二者分别采用基于VMM的Rootkit检测技术中task—list和runqueues重构，恢复系统内进程的可信视图，并通过交叉视图进行隐藏进程检测。
Hyperjacking虚拟化管理程序劫持
Hperjacking rootkit攻击，专门针对系统管理程序的攻击
获得底层权限，在操作系统启动前先启动VMM，让原先的操作系统执行在此VMM上，而恶意程序则执行在另一个与VMM平行的独立操作系统上，原先的操作系统便会无法察觉到这个恶意程序的存在。
Hyperjacking 工具：bluepill subvirt vitriol
In the early 2000’s virus writing was all the rage. Think of the massive virus outbreaks that took place. Millions of infected hosts. The Sober virus that infected 218 million machines in seven days. The MyDoom virus sent over 100 million virus-infected emails. The “I Love You” virus infected 55 million machines and collected their usernames and passwords. These attacks were about bragging rights, not money.
That’s so last decade. Virus writing is so passé. Following it, however, was the age of malware and phishing. This was monetary bound, and sought to phish the user/pass and actually use them. Western Union must have made a bazillion dollars as the fence for criminals and crooks worldwide.
There’s a bigger picture. As we’ve moved from local workstations and servers containing copious amounts of tasty private information and data, toward the cloud where all of that data sexiness lives behind the locked doors of the Cloud Providers, the game is changing.
There are new technical challenges.
The back end to the cloud is Virtual infrastructure. And if you think of a cake, there would be the pan which is the physical piece, or the hardware. Above that is a yummy bit called the hypervisor which is a software piece that governs the host machine. This is essentially the cake part, the soft mushy filler between the pan and the frosting. But it’s software. The hypervisor dictates the basic operation of the host machine. It’s the abstraction layer between physical hardware and virtual machines in any virtualized platform. And on top of that abstraction layer is the frosting, or the guest operating systems. These systems are the “Virtual Machines”.
Enough of the cake references. I’m getting hungry.
In my previous article I outlined the fact that going virtual adds simplicity for IT departments. It’s easier to provision servers, it’s easier to move servers, it’s easier to decommission servers. It’s easier to set up networks. It’s easier from a management perspective all around. But in order to attain this simplicity, we are adding complexity on the platform side (the hypervisor), and not enough complexity to the network side. (i.e., virtualization creates flat networks which out of the box virtualization creates.) So by creating simplicity in the management side, we need to add complexity by adding a hypervisor and add security back to a flat network. Segregation. Divide and conquer. Yin and Yang.
One element of this added complexity is hyperjacking. Still in its infancy, hyper-jacking revolves around the corporate world's newfound enthusiasm for application, operating system and solution virtualization. Hyperjacking is a verb that describes the hypervisor stack jacking. Hyperjacking involves installing a rogue hypervisor that can take complete control of a server. Regular security measures are ineffective because the OS will not even be aware that the machine has been compromised. Sneaky sneaky.
Why? Or rather, how? Because the hypervisor actually runs underneath the operating system, making it a particular juicy target for nefarious types who want not only to own (or PWN to those in the know) the host servers in order to attack guest VMs, but also to maintain persistence. (Okay, they’ve gotten into your hypervisor and stolen your data but, they’d also like the ability to come back whenever they want to steal more data.) Hyper-jacking is a great way to not only compromise a server and steal some data, but also to maintain that persistence. Get control of the hypervisor and you control everything running on the machine. The hypervisor is the single point of failure in security and if you lose it, you lose the protection of sensitive information. This increases the degree of risk and exposure substantially.
Now, what we’ve seen are some lab-based examples of hyper-jacking-style threats. But not many are in the wild. Or rather, we haven’t identified anything in the wild yet. Whether or not this has actually taken place across a mass amount of VMs we don’t know. But some examples of hyper-jacking-style threats include a specific type of malware called virtual machine based root-kits.
For a hyperjacking attempt to succeed, an attacker would need a processor capable of doing hardware-assisted virtualization. So the best way to avoid hyper-jacking is to use hardware-rooted trust and secure launching of the hypervisor. This requires the technology to exist in the processor and chipsets themselves and offers trusted execution technology as well as a trusted platform modules to execute a trusted launch of a system from the hardware through the hypervisor.
Now many vendors have subscribed to a set of standards from the Trusted Computing Groups compliance of measured launch and root trusts. And with that, there are also several security vendors who are offering hypervisor security products that work by checking the integrity of the hypervisor while it’s still in motion.
To do this, the programs examine the hypervisors and program memory, as well as the registers inside the CPU, to see if there are any unknown program elements. Root-kits in the hypervisor hide by modifying certain registers of the CPU and relocating the hypervisor somewhere else. And in this case, the hypervisor integrity software locates this relocated hypervisor. The hypervisor integrity software does this without the hypervisor being aware that it’s taking place. Of course, adding hooks into the process for examining the hypervisor also makes me uncomfortable, but that’s a conversation for another day.
This is all software, and software has rules that can be bent. So while addressing risks associated with the hypervisor we must remember that the hypervisor and the guest operating systems it supports are software and as such, need to be patched and hardened. Period.
Now with that in mind, you’re probably wondering “Well, how can I harden my environment?” Well, there are risks with all, but at least you’re thinking about it. Proactive thinking vs. reactive. Well done. Let’s put some basic design features in your environment to mitigate your risks:
1. Like security? Well, keep the management of said hypervisor in a secure environment. This is more of a network design issue than anything. It’s not hypervisor related, but still something to be considered. Never connect your hypervisor management functions to a less secure environment, than the virtual instances. Don’t put your management function access in the DMZ. Although this sounds like a common sense thing, we’ve all heard horror stories. Don’t be the horror story.
2. Your guest operating systems should never have access to the hypervisor. Nor should they know about it. Guest operating systems should never know they’re virtual. And your hypervisor should never tell a guest OS that it’s hosted. Secret secret.
3. Embedded solutions are much safer. I know this is common sense to most. Operating system-based solutions are traditionally less secure because there are more moving parts. My father always said, “keep it simple, stupid.” Same deal. Embedded modules are more simple and functional, as well as easier to manage, maintain and secure.
Understanding the hypervisor risks is one step toward securing them. Although much of the hyper-jacking conversation has been theoretical, don’t set yourself up in a place where youcould be compromised if some 0-day hypervisor attack pops up. Secure your hypervisor, secure your world. Or at least part of it.
这篇关于基于VMM的Rootkit检测技术及模型分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
