Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download SubVirt: Implementing malware with virtual machines
Transcript
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
