1. SubVirt: Implementing malware with virtual machines Yi-Min Wang Chad Verbowski Helen J. Wang Jacob R. Lorch Microsoft Research Samuel T. King Peter M. Chen University of Michigan

2. 2/23 Motivation Attackers and defenders strive for control –Attackers monitor and perturb execution Avoid defenders –Defenders detect and remove attacker –Control by lower layers Hardware Operating system App1App2 AttackersDefenders

3. 3/23 Virtual-machine based rootkits (VMBRs) VMM runs beneath the OS –Effectively new processor privilege level Fundamentally more control No visible states or events Easy to develop malicious services

4. 4/23 Virtual-machine based rootkits (VMBRs) Hardware Target OS App1App2 Before infection Hardware Target OS App1App2 VMM Attack system After infection

5. 5/23 Outline Installing a VMBR Maintaining control Malicious services Defending against this threat Proof-of-concept VMBRs Attacker’s perspective Defender’s perspective

6. 6/23 Installation Assume attacker has kernel privilege –Traditional remote exploit –Bribe employee –Malicious bootable CD-Rom Install during shutdown –Few processes running –Efforts to prevent notification of activity

7. 7/23 Installing a VMBR Modify the boot sequence BIOS Master boot record Boot sector OS

8. 8/23 Installing a VMBR Modify the boot sequence BIOS Master boot record Boot sector OS VMBR loads

9. 9/23 Maintaining control Hardware reset VMBR loses control Illusion of reset w/o losing control Reboot easy, shutdown harder BIOS Master boot record Boot sector OS VMBR loads

10. 10/23 Maintaining control ACPI BIOS used for low power mode –Spin down disks –Display low power mode –Change power LED Illusion of power off, emulate shutdown Control the power button System functionally unchanged

11. 11/23 Malicious services Advantages of high and low layer malware –Provides low layer implementation –Still easy to implement services Use a separate attack OS to implement Hardware Target OS App1App2 VMM Attack OS App

12. 12/23 Malicious services Zero interaction malicious services –E.g., phishing web server Passive monitoring –E.g., keystroke logger, file system scanner Active execution modifications –E.g., defeat VM detection technique All easy to implement

13. 13/23 Defending against VMBRs Detecting VMBRs –Perturbations Where to run detection software

14. 14/23 VMBR perturbations Inherent –Timing of key events –Space Hardware artifacts –Device differences –Processor not fully virtualizable –See paper for more details Software artifacts –VM icon –Device names Easy to hide Hard to hide

15. 15/23 Security software above Attack state not visible –Can only detect side effects, e.g., timing VMBR can manipulate execution –Clock controlled by VMBR –Prevent security service from running –Turn off network –Disable notification of intrusion

16. 16/23 Security software below More control, direct access to resources –Could detect states or events Secure VMM and/or secure hardware Boot from safe medium –Unplug machine from wall

17. 17/23 Proof-of-concept VMBRs VMware / Linux host Virtual PC / Windows XP host Host OS was attack OS Malware payload ~100MB compressed Non fully virtualizable ISA –To defeat would degrade performance Software emulated devices –Host OSes had wide range of drivers

18. 18/23 Proof-of-concept VMBRs Implemented four malicious services –Phishing web server –Keystroke logger + password parser –File system scanner –Countermeasure to detection tool Installation scripts and modules ACPI shutdown emulation –Both sleep states and power button control

19. 19/23 Related work Layer below attacks –Kernel layer rootkits VMMs for security –Trusted VMMs: Terra, NGSCB –Detect intrusions: VMI, IntroVirt –Isolation: NSA’s NetTop –Analyze intrusions: ReVirt Current defenses –Secure/trusted boot –Pioneer

20. 20/23 Conclusion Realistic threat –Qualitatively more control –Still easy to implement service –Proof-of-concept VMBRs could be detected –HW enhancements might make more effective Defending is possible –Best way it for defenders to control low layers

21. 21/23 Questions

22. 22/23 Hardware artifacts Non fully virtualizable processor Computer have diverse hardware –Allow target OS to provide drivers –Device DMA unsafe, might expose VMBR –Results in different / incomplete visible HW Enhancements to MMU –Allow target OS to run many drivers directly

23. 23/23 Software artifacts Implementations make VMM visible VMware / Virtual PC hypercalls –E.g. GetVersion() VMware icon Name of virtual hardware Etc…

24. 24/23 Performance Non fully virtualizable hardware tradeoff –Performance vs. perfect virtualization –Dynamic binary translation –Paravirtualization Simplified driver interface Effects of HW enhancements unknown

25. 25/23 Impact of VM enhanced hardware VMBR allow target to run most HW –Only emulate devices needed for virt E.g., disk, network –Target can drive everything else Display, USB Better device performance Smaller VMBR payload

26. 26/23 Defeating the “redpill” Easy to detect VM on non-virt. x86 “Redpill” uses instructions that leak info Interpose on key windows functions –Fixup the “redpill” app to avoid VM detect Uses virtual-machine introspection