SubVirt: Implementing malware with virtual machines

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

2. Attackers Defenders Motivation • Attackers and defenders strive for control • Attackers monitor and perturb execution • Avoid defenders • Defenders detect and remove attacker • Control by lower layers App1 App2 Operating system Hardware

3. 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. Attack system App1 App2 Target OS VMM Hardware After infection Virtual-machine based rootkits (VMBRs) App1 App2 Target OS Hardware Before infection

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

6. 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. Master boot record Boot sector OS Installing a VMBR • Modify the boot sequence BIOS

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

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

10. 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. 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 App App1 App2 Attack OS Target OS VMM Hardware

12. 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. Defending against VMBRs • Detecting VMBRs • Perturbations • Where to run detection software

14. 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 Hard to hide Easy to hide

15. 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. 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. 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. 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. 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. 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. Questions

22. 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. Software artifacts • Implementations make VMM visible • VMware / Virtual PC hypercalls • E.g. GetVersion() • VMware icon • Name of virtual hardware • Etc…

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

25. 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. 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