Docstoc

SubVirt_ Implementing malware with virtual machines

Document Sample
SubVirt_ Implementing malware with virtual machines Powered By Docstoc
					SubVirt: Implementing malware with virtual machines
Samuel T. King Peter M. Chen Yi-Min Wang Chad Verbowski Helen J. Wang Jacob R. Lorch Microsoft Research

University of Michigan

Motivation
• Attackers and defenders strive for control
– Attackers monitor and perturb execution
• Avoid defenders

– Defenders detect and remove attacker – Control by lower layers Attackers Defenders

App1

App2

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

App2

Target OS

Target OS
Hardware Before infection

VMM
Hardware 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 Attack OS App1 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


				
DOCUMENT INFO