Transcript SubVirt: Implementing malware with virtual machines

SubVirt: Implementing malware
with virtual machines
Samuel T. King
Peter M. Chen
Yi-Min Wang
Chad Verbowski
Helen J. Wang
Jacob R. Lorch
University of Michigan
Microsoft Research
Motivation
• Attackers and defenders strive for control
– Attackers monitor and perturb execution
• Avoid defenders
– Defenders detect and remove attacker
– Control by lower layers
Attackers
App1
App2
Defenders
Operating system
Hardware
2/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
3/23
Virtual-machine based rootkits
(VMBRs)
App1
App2
Attack
system
App1
Target OS
Target OS
VMM
Hardware
Hardware
Before
infection
App2
After
infection
4/23
Outline
• Installing a VMBR
• Maintaining control
• Malicious services
Attacker’s
perspective
• Defending against this threat
Defender’s
perspective
• Proof-of-concept VMBRs
5/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
6/23
Installing a VMBR
• Modify the boot sequence
Master
Boot
boot
BIOS record sector
OS
7/23
Installing a VMBR
• Modify the boot sequence
BIOS
VMBR
loads
Master
boot
Boot
BIOS record sector
OS
8/23
Maintaining control
• Hardware reset VMBR loses control
• Illusion of reset w/o losing control
• Reboot easy, shutdown harder
BIOS
VMBR
loads
Master
boot
Boot
BIOS record sector
OS
9/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
10/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
App
App1
Attack OS
App2
Target OS
VMM
Hardware
11/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
12/23
Defending against VMBRs
• Detecting VMBRs
– Perturbations
• Where to run detection software
13/23
VMBR perturbations
• Inherent
– Timing of key events
– Space
Hard to
hide
• Hardware artifacts
– Device differences
– Processor not fully virtualizable
– See paper for more details
• Software artifacts
– VM icon
– Device names
Easy to
hide
14/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
15/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
16/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
17/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
18/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
19/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
20/23
Questions
21/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
22/23
Software artifacts
• Implementations make VMM visible
• VMware / Virtual PC hypercalls
– E.g. GetVersion()
• VMware icon
• Name of virtual hardware
• Etc…
23/23
Performance
• Non fully virtualizable hardware tradeoff
– Performance vs. perfect virtualization
– Dynamic binary translation
– Paravirtualization
• Simplified driver interface
• Effects of HW enhancements unknown
24/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
25/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
26/23