阅读笔记 - SubVirt: Implementing malware with virtual machines (2)

3.3 Example malicious services
下面介绍这篇paper提到的4个恶意程序

最简单的，开了个thttpd web服务器进行网络钓鱼，任何发送到8080端口的TCP请求都会被这个服务器截获。

然后是一个按键记录程序，号称只用了60行代码就搞定了这个模块，然后写了一个254行的带图形界面的程序来分析日志并显示。

一个扫描目标机文件系统的程序，这是一个24小时运行的perl脚本，会把诸如/etc/shadow, user_home/.ssh/id_dsa之类的机密信息保存下来。

最后是防止VMM被目标机侦测到的一个服务。paper中提到了一种叫做redpill的虚拟机侦测手段，通过使用sidt指令。这个指令会读出处理器的中断列表(interrupt descritor table)，在VMM上跑的系统和普通的操作系统读出来的结果不一样，当这个指令在内核态被执行时，VMM会模拟这个指令的执行；但是用户态却不会被截获（考虑到性能因素）。所以redpill通过用户态执行sidt来判断当前系统是否运行在虚拟机上。这篇paper提到的针对redpill的解决方案是在每个可执行文件的sidt指令前设置一个断点，截获这个指令后就模拟这个指令，以此绕过redpill检测。但是这种方法不适合于在程序运行期动态生成二进制的sidt指令的程序（想到我的lab4了，呵呵）。道高一丈魔高一尺（原文是Continuing the arms race，军备战争），通过二进制转换(binary translation)，动态生成的sidt同样可以被截获，但是这种方法的overhead会很大。

3.4 Maintaining Control
这块主要讲了对系统重启、关闭的处理。

系统要求重启时，VMBR总是尽可能的通过重启guest os来完成，这样就能最大化的掌握控制权。

另外通过ACPI模拟系统关闭也可以欺骗使用者。这种模式下硬盘、风扇停止，RAM仍然上电，下一次开机后可以恢复到上一次关机的状态，于是VMBR继续在第一时间掌握控制权。

4. Evaluation
测试下来开机、重启的速度都慢了不少。不过很正常，因为用的是Virtual PC和VMWare。

不过随着虚拟技术的发展，对系统性能的影响肯定越来越小的（比如Xen），这篇paper关键在于占了个坑，至少现在看来实用性还很差。

5. Defending against virtual-machine based rootkits
5.1 Security software below the VMBR
比VMBR更低的层次就很容易检测到VMBR了。比如硬件级别的安全支持(Intel LaGrande)，或者CDROM启动（注意这里首先要冷重启，否则说不准虚拟机给你模拟CDROM启动了），还可以先装个安全的VMM，即使收到VMBR攻击，VMBR也只能在安全的VMM和操作系统之间那层运行。


5.2 Security software above the VMBR
在VMBR上层要检测就有一定技术难度了。

一种基本的方法是利用CPU时间、内存上限、硬盘上限、网络带快来测定。

VMBR的存在必定会影响到CPU的表观性能，通过这种时间上的差异就能发现问题。不过VMBR可以通过放慢系统时钟返回的时间来欺骗目标机，对于这种欺骗，测试人员可以使用其他的不可控的计时工具（比如手表 -_-b）

另外硬盘、内存上限都会因为VMBR的存在而变小。后者很难侦查到，因为有一层虚拟内存。而针对前者的检测，VMBR可以截获对它占用的地址的访问，然后返回一些随机的信息，让guest os以为那是坏扇区从而躲过检查。所以这招不怎么好用。

另外由于性能考虑，并不是所有的硬件都是被迷你的，通常只有需要保护的设备（比如启动盘）和需要攻击的设备（比如网卡）被虚拟化，其他的硬件都是guest os直连的，这样就只需要在这些未被虚拟化的硬件上做一个DMA，把物理内存中的部分信息读过来就能分析了（ 通过这个貌似可以对同一个物理机上的其他虚拟机进行攻击啊）

另外一种方法就是前面的提到的通过sidt指令了。


6. Trends toward virtualization
略

7. Related work
略