subvirt: implementing malware with virtual machines yi-min wang chad verbowski helen j. wang jacob...

SubVirt: Implementing malware with virtual

machines

Yi-Min WangChad VerbowskiHelen J. WangJacob R. Lorch

Microsoft Research

Samuel T. KingPeter M. Chen

University of Michigan

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

App1 App2Attackers Defenders

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

Virtual-machine based rootkits (VMBRs)

Hardware

Target OS

App1 App2

Beforeinfection

Hardware

Target OS

App1 App2

VMM

Attacksystem

Afterinfection

5/23

Outline

• Installing a VMBR• Maintaining control• Malicious services

• Defending against this threat

• Proof-of-concept VMBRs

Attacker’sperspective

Defender’sperspective

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

Installing a VMBR

• Modify the boot sequence

BIOS

Masterboot

recordBoot

sector OS

8/23

Installing a VMBR

• Modify the boot sequence

BIOS

BIOS

Masterboot

recordBoot

sector OS

VMBRloads

9/23

Maintaining control

• Hardware reset VMBR loses control• Illusion of reset w/o losing control• Reboot easy, shutdown harder

BIOS

BIOS

Masterboot

recordBoot

sector OS

VMBRloads

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

App1 App2

VMM

Attack OS

App

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

Defending against VMBRs

• Detecting VMBRs– Perturbations

• Where to run detection software

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 tohide

Hard tohide

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

Questions

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

Software artifacts

• Implementations make VMM visible

• VMware / Virtual PC hypercalls– E.g. GetVersion()

• VMware icon• Name of virtual hardware• Etc…

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