SubVirt: Implementing malware with virtual machines

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

Attackers perspective
Defenders 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
Installing a VMBR

• Modify the boot sequence

BIOS
8
Installing a VMBR

• Modify the boot sequence

VMBR loads
BIOS
9
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

App1
App2
App
Target OS
Attack 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 NSAs 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