Windows rootkits of 2005, part three（翻译）

转载于：http://hi.baidu.com/ring3world/blog/item/a0d30282c97a1d93f703a620.html

英文原文：http://www.symantec.com/connect/articles/windows-rootkits-2005-part-three

本系列的最后一章将探索5种不同的rootkit侦测技术用于发现Windows rootkit的分布。另外还会谈到9种为系统管理员设计的工具。

1.介绍
     在过去几年里Rootkit已经发展得很成熟，2005年中随着各种恶意软件甚至音乐CD蜂涌而至。尽管计算机系统被rootkit扰乱后要发觉或者清除 rootkit是极度困难的，但是仍然有些方法可以侦测不同程度的rootkit。第一部分我们知道了什么是rootkit以及为什么他们如此危险，第二 部分研究了了最前沿的rootkit技术以及他们是如何隐蔽的完成的。

2.基于签名的侦测
     基于签名的侦测方法防毒软件已经用了些年头了。概念上很简单，扫描系统文件的字节序列是否包含某个rootkit的指纹。如果在用户系统的文件中找到了签 名，就表示被感染了。由于rootkit通过执行路径hook技术隐藏文件的天赋，传统意义上的文件系统扫描技术用于侦测rootkit有局限性，除非综 合其他一些更高级的侦测技术。
     尽管这有些古老，然而值得一提的是基于签名的侦测技术除了用于文件系统外，还可以用于系统内存的扫描。相反的，大多数公开的内核rootkit对于内核内 存扫描都没有免疫力。作为内核驱动，他们都驻留在非分页池中，并且很少会朝着变种代码扰乱方面努力。因此内核内存扫描可以简单的识别大多数公开的内核 rootkit，不论他们耍啥小把戏(像DKOM, SSDT, IDT hooking之类的)。然而，注意上一句话的关键词语：公开的rootkit。就如同它的定义一样，基于签名的侦测技术对于没有已知签名的恶意软件是没 用的。最后要指出的是对于虚拟内存hooking的rootkit，比如Shadow Walker这种能够控制扫描程序读到的内存的rootkit，基于签名的扫描技术也是没用的[ref 1]。

3.启发式侦测/行为侦测
     基于签名的侦测技术的缺陷正是启发式侦测的强项。他们主要的优势就是能够识别出最新的，之前没有被确认的rootkit。其工作原理是识别不正常的系统模 式或者行为。各种启发式侦测都是针对执行路径hooking的rootkit。本节将分析2中这样的工具：VICE和Patchfinder。

3.1 VICE
     VICE是用于侦测hook的自由软件[ref 2]。这是一个很棒的程序，安装一个设备驱动来分析用户态的程序和操作系统内核。在内核中，VICE检查SSDT中没有指向ntoskrnl.exe的函 数指针。你也可以添加设备到"driver.ini"文件中，VICE会检查其对应的IRP主要函数表是否指向其自身地址，如果不是，那么就是被hook 了。在用户态，VICE检查每个应用程序的地址空间，查找这些应用程序使用的每个DLL中的IAT。侦测应用程序导入的动态库函数的内联函数钩子以及 SSDT函数。VICE可以找出那些函数被hook以及hook函数的地址，如果可能的话，VICE也会显示使用hook的DLL或设备驱动的完整路径以 便系统管理员能够清除恶意软件。如今，VICE可以侦测到大部分已知的公共Windows rootkit以及任何使用hoot相关技术的隐蔽行为。要运行VICE，需要安装Microsoft .NET Framework，免费下载。
     VICE的当前版本已经被至少一个公开的rootkit盯上了，并且被破坏了[ref 3]。Rootkit发现VICE总是用一个特定的进程名运行，当rootkit侦测到VICE进程，它就不hook了。于是VICE就啥都发现不了。另 一种攻击手段瞄准了VICE用户态和设备驱动之间的通讯通道。然而VICE最大的弱点大概是其返回的大量的错误判断。VICE被设计为侦测hook，但是 在操作系统中有些合法的hook用法。微软自己在动态补丁和DLL转向技术中也提供hook。真的很难确定某个hook是合法的还是恶意的。

3.2 Patchfinder
     VICE是基于代码和数据结构的静态分析识别rootkits，Joanna Rutkowska提出了一种基于运行时执行路径剖析的方法[ref 4]。在她的网站(invisiblethings.org)上提供了该原型的实现：Patchfinder。Patchfinder的理论基础是 rootkit必须添加代码到一条给定的执行路径（例如通过hook服务过滤返回的结果）。因此，如果能够计算被rootkit钩到了的一般系统服务执行 的指令数，那么该指令数一定会比未被感染的系统执行相同的服务运行的指令数要多。Rutkowska利用x86处理器的单步执行特性完成指令计数。当代码 运行在单步模式，处理器中断运行，在每条指令执行后调用一个特殊的中断服务例程(ISR)。这个例程会更新该计数。不幸的是，像windows这样复杂的 系统中可能存在多条执行路径，导致行为有不确定性。也就是说，被测试的服务的多个执行路径在不同的系统条件下会返回不同的计数。Rutkowska在 Patchfinder中处理这个问题是通过构造柱状图来统计。经验证明无论系统负载如何，柱状图中主要的峰值都维持了一个常量，而被rootkit插入 了额外的指令则会导致峰值的变化。不管怎样说，这种技术还是有错误判定发生的问题。对于能够意识到其被跟踪的rootkit，这种技术有缺陷。

4.基于交叉查看的侦测
     基于交叉察看的侦测技术是比较新的技术，被寄予厚望。其依据是总是可以通过多种途径来发送相同的请求。它假设操作系统已经被破坏，然后调用普通的API来 遍历系统中的关键元素，比如文件列表，进程列表，注册表键值等。为了达到目的，它还必须有个不依赖于普通API的算法来生成相似的数据集。如果这两个数据 集存在任何一点差异即说明有东西被隐藏了。因为在用普通API生成的数据集中缺少了东西。基于交叉查看的侦测技术依赖于一个事实，即API hooking或者修改内核数据结构会影响通过调用操作系统API返回的数据，但是通过一些底层的方法获取相同的信息时不会被hook或者DKOM破坏。

4.1 Rootkit Revealer
     Rootkit Revealer可以到Sysinternals下载[ref 5]。Sysinternals为系统管理员和开发人员提供了很多免费工具。Rootkit Revealer的目标是rootkit的子集：持久rootkit。所谓持久rootkit是指重新启动机器后还存在的rootkit。从这个角度来 说，驻留在内存的rootkit是不能持久的。Rootkit Revealer认为rootkit为了能持久，就必须存在于文件系统和Windows注册表中。Rootkit Revealer通过交叉查看的技术来侦测它。先调用高级API来遍历磁盘文件和注册表项，然后解析原始的磁盘文件系统结构和组成注册表的文件来比较差 异。
     跟大多数rootkit侦测工具一样，Rootkit Revealer也能被那些阻止或转移磁盘卷或注册表访问的rootkit破坏。同时Rootkit Revealer也会受错误判断的苦。如果在两次遍历之间，文件或注册表项被创建，删除或修改，结果就会不一样。所有基于交叉察看技术的侦测手段都有这个 问题，这是其算法本质决定的。

4.2 Klister
     Klister是由Joanna Rutkowsk开发的另一个rootkit侦测的原型工具[ref 4]。Klister展示了一个用于侦测类似FU的使用DKOM技术隐藏进程的rootkit的方法。FU是通过删除 PsActiveProcessList中的EPROCESS对象来隐藏进程(参见第一部分)[ref 6]。按理说，如果把一个进程从操作系统的进程列表中删除的话它应该会停止运行(或者说操作系统调度器不会为它分配时间片)。有趣的是实际情况并非如此， 因为操作系统的分派器和进程调度维护的是不同的队列。Klister利用操作系统数据结构的这种冗余来侦测被从PsActiveProcessList中 移除的隐藏进程。通过比较活动进程列表和分派队列来识别差异是可行的。如果一个进程出现在分派队列但是没有出现在活动进程列表，则可以认为它被 rootkit隐藏了。虽然Rutkowska只将这种技术用于进程检测，对于DKOM攻击，通过比较内核冗余数据也同样有效。

4.3 Blacklight
     由F-Secure开发的Blacklight是瞄准rootkit侦测的最早的商用产品之一[ref 7]。尽管Blacklight技术已经融入到了F-Secure的其他产品，但是现在已经可以免费下载(http://www.europe.f-secure.com/exclude/blacklight/blbeta.exe)了。Blacklight的目标是被rootkit隐藏的进程和文件，也是用的基于交叉查看的方法，用高级API遍历所有进程然后与用底层方法获取的列表比较。侦测隐藏文件的方法与此类似。
     过去的一年里，Blacklight用于底层遍历的算法多次变更。每次Balcklight都试图识别会导致它出错的关键数据是否被rootkit修改。 Blacklight和其他基于交叉查看的侦测方法都曾经在识别其不能被更改的关键元素方面获得不同程度的成功。然而，一旦rootkit的作者发现了正 被使用的算法，设计严谨的rootkit通常能改变这些数据而不产生任何负面影响。

4.4 Strider GhostBuster
     微软的Strider GhostBuster跟Rootkit Revealer相似，也是基于交叉察看的方法来侦测隐藏文件，注册表项，进程和加载的模块[ref 8]。比较高级API查询到的信息与分析操作系统或文件系统的数据结构(比如NTFS Master File Table和Windows注册表文件)这样的底层查询获得的信息，如果发现差异，就说明当前系统中存在ghostware。Ghostware是微软研 究团队创造的术语，用于指代rootkits，trojans，keyloggers以及其他试图隐藏自身存在的商用广告软件或间谍软件等。
     GhostBuster对系统进行两次扫描。第一次是对可疑系统在运行时进行扫描，称之为inside-the-box。第二次是重新启动系统到一个干净 的操作系统执行一些低级的扫描操作，称之为outside-the-box。离线扫描的特性降低了扫描程序受rootkit攻击的可能性，但是很不方便。 为了日常的恶意软件扫描来重启服务器明显不切实际。不管怎样，对于强烈怀疑的或者已经知道受威胁的系统，用这个方法能够提供判别的证据。
     尽管从目前来看，交叉察看技术似乎是rootkit侦测的尖端技术，但对于已经存在的rootkit攻击方法来说并非是无懈可击的。事实上，它的成功很大 程度上依赖于实现，特别是用于获得低级的系统视角的方式。比如，为了解析NTFS磁盘布局，侦测者必须首先获得磁盘卷的句柄，然后读取各个扇区。如果侦测 者使用系统API来完成这些操作，那就又绕回到之前的问题了。也就是说，侦测程序必须假定这些API接口已经被感染（rootkit确实会尝试用API钩 子来欺骗这种侦测）。因此，交叉察看方式的最牛实现就是仅仅依靠直接与磁盘控制器通讯来获取信息。

5.基于完整性的侦测
     基于完整性的侦测可以是签名检测或者启发是检测两种选择。依赖于比较当前文件系统或内存的快照与已知的可信任的基准之间的差异来证明恶意活动存在的证据。遗憾的是完整性检查通常不能查明导致变化的行为的源头。

5.1 Tripwire
     Tripwire是基于磁盘完整性的检测程序[ref 10]。它首先在用户硬盘上创建一个可信任的数据库，饱含了每一个系统文件的CRC校验值。当用户开始扫描恶意行为时，就重新计算所有系统文件的CRC值 并与数据库中记录的CRC值比较。其依据是系统文件应该不会变化（除非系统升级或者打补丁）。因此比较结果有差异就说明被感染了。Tripwire对于早 期简单的替换磁盘上的系统文件为特诺伊版本的rootkit非常有效。不过现代的rootkit改为修改内存而不是磁盘，Tripwire就形同虚设了。 不过，一旦基于磁盘完整性的检查失败，那么基于内存完整性的检测就会成功。

5.2 System Virginity Verifier
     System Virginity Verifier也是Joanna Rutkowska开发的一个rootkit侦测的原型工具[ref 11]，融合了类似VICE的启发式侦测与内存完整性校验技术。它会检测操作系统数据结构(IAT/EAT/SSDT/IRP表)的完整性，同时还混入了 一些更高级的试探法协助处理由病毒扫描以及个人防火墙之类的合法应用程序使用的良性hook导致的误判问题。内存完整性校验是用于比较磁盘上重要的系统库 和驱动程序的代码段与它们被加载到内存中的对应映像。

6.硬件侦测 - Copilot
     Copilot是唯一基于硬件检测的工具。刚开始这只是Maryland大学的一个项目，而现在已经是一个独立的公司了。当前的Copilot产品 [ref 12]是一块PCI卡，被安装在要监视rootkit行为的机器上。其目标是不依赖于潜在可能已经被扰乱的操作系统。所以它有自己的CPU，并且通过直接 内存访问(DMA)的方式扫描目标机器的物理内存，寻找各种rootkit行为，比如SSDT hook，修改内核函数(使用内存完整性校验)，DKOM供给修改关键数据结构等。Copilot卡尤其自己的网络接口和管理组件安全的通讯。
     Copilot是基于硬件的解决方案，它提供了很好的保障，然而价格不菲。任何基于硬件的解决方案总是花费更高，并且需要维护。但是有时候就是需要这种保 障。如果再配合一套软件监控组件，Copilot就是rootkit作者的噩梦。它甚至能校验它自己运行与系统上的软件。

7.总结
       As we survey the existing rootkit detection techniques, it becomes apparent that all of the approaches have strengths and weaknesses. Every one of the described tools brings a piece of the puzzle to the table, but none of them yet provide a truly comprehensive solution to the problem. Many of the tools are still proof of concept and, ironically, some of them were written by the rootkit authors themselves. It is, however, encouraging to see anti-rootkit activity beginning in the commercial AV / Anti-malware arena (as we saw with Blacklight and Strider GhostBuster) as well as in the high assurance market (Copilot). In attempting to consider the "big picture," we can finally make a few observations based upon our firsthand observations of some of the battles that occur between rootkit authors and detectors. First, a number of the aforementioned tools show promise. Hybrid approaches which combine several of these techniques, however, will be stronger because they will maximize their strengths while minimizing the effects of weaknesses. Second, "lower is better" should be the mantra of the rootkit detector. Many detectors get themselves into trouble by relying upon operating systems API's which they should assume to be compromised. Finally, one must keep in mind that the rootkit still has the upper hand. Unlike a rootkit which rarely needs to concern itself with the stability of the victim's system, this concern is of paramount importance to the detector, especially commercial detectors with a paying client base. This often constrains the rootkit detection software by forcing it to avoid some useful but dangerous methods. Despite this, detectors are clearly "upping the ante." Now in early 2006, it will be interesting to see how the ongoing battle between rootkit detector and developer plays out over the coming year.

8. References

[ref 1] Butler, James and Sparks, Sherri. "Shadow Walker: Raising The Bar For Windows Rootkit Detection", Phrack 63, July 2005.
[ref 2] Butler, James, "VICE - Catch the hookers!" Black Hat, Las Vegas, July, 2004. www.blackhat.com/presentations/bh-usa-04/bh-us-04-butler/bh-us-04-butler.pdf
[ref 3] Holy Father, Hacker Defender. http://www.hxdef.org/download/hxdef100r.zip
[ref 4] Rutkowska, Joanna. "Detecting Windows Server Compromises with Patchfinder 2", Jan 2004.
[ref 5] Rootkit Revealer. http://www.sysinternals.com/Files/RootkitRevealer.zip
[ref 6] Fuzen, FU Rootkit. http://www.rootkit.com/project.php?id=12
[ref 7] BlackLight. http://www.europe.f-secure.com/exclude/blacklight/
[ref 8] Y. Wang, D. Beck, R. Roussev, and C. Verbowski. "Detecting Stealth Software with Strider GhostBuster". Technical Report, Feb 2005.
[ref 9] Rutkowska, Joanna. "Thoughts about Cross-View based Rootkit Detection", June 2005http://www.invisiblethings.org/papers/crossview_detection_thoughts.pdf andhttp://www.invisiblethings.org/papers/rootkits_detection_with_patchfinder2.pdf
[ref 10] Tripwire, Inc. http://www.tripwire.com
[ref 11] Rutkowska, Joanna. "System Virginity Verifier: Defining the Roadmap for Malware Detection on Windows Systems", Sept 2005.http://www.invisiblethings.org/papers/hitb05_virginity_verifier.ppt
[ref 12] N. Petroni, T. Fraser, J. Molina, and W. Arbaugh, "Copilot - a Coprocessor-based Kernel Runtime Integrity Monitor," in Proc. Usenix Security Symposium, Aug. 2004. On the Web at http://www.komoku.com/pubs/USENIX-Copilot.pdf.

About the authors

James Butler is the CTO of Komoku, which specializes in high assurance, host integrity monitoring and management. Before that, Mr. Butler was the Director of Engineering at HBGary, Inc. focusing on rootkits and other subversive technologies. He is the co-author and a teacher of "Aspects of Offensive Rootkit Technologies" and co-author of the newly released bestseller "Rootkits: Subverting the Windows Kernel."

Sherri Sparks is a PhD student at the University of Central Florida. Currently, her research interests include offensive / defensive malicious code technologies and related issues in digital forensic applications.