虚拟机攻击服务器,一篇讨论虚拟机攻击的论文-subvirt（转）

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略