Vm Rootkits

3380-1 (CFNOC/DND CIRT) 23 Oct 06 NOS O (via CoC) I&W ANALYSIS FOLLOW THE WHITE RABBIT: VIRTUAL MACHINE ROOT KITS INTRODUCTION 1. (U) Recently there has been a great furor in the Information Security community regarding a new development in rootkit1 technology - Virtual Machine Rootkits (VMRs); the brouhaha in question culminated in August of this year with the revelation of Joanna Rutkowska's "Blue Pill"2 VMR. 2. (U) This technology is not only receiving a great deal of attention in the professional community; a brief survey of the Internet's dark underbelly reveals that amongst Blackhats3 and other ne'er do wells VMRs are currently the proverbial "talk of the town". 3. (U) This paper should be considered an "early warning" - the technology will continue to evolve in the future and considering the attention it is garnering in the underground community, it is only a matter of time until the technology is developed into a viable malware implementation which would, in theory, be practically undetectable using conventional, practical countermeasures. AIM 4.

(U) The purpose of this report is threefold: a. to acquaint the reader with the recent developments in VMR technology; b. to discuss this new technology in some detail; and c. to present recommendations to that will harden the organization's networks from future exploitation as it relates to this new technology.

1

2

Rootkit - A set of software tools intended to conceal running processes, files or system data, thereby allowing an intruder to maintain access to a system whilst avoiding detection. Ms. Rutkowska has displayed a recent tendency to assign designations to her projects that reference the film "The Matrix".

3

Black Hat - A malicious or criminal hacker.

1

DISCUSSION Virtual Machines 1014 5. (U) This section will serve to introduce the reader to the concept and technology behind virtual machine5 (VM) technology in order to convey a basic understanding of a VMR’s underlying technology. 6. (U) Virtual machine software (e.g. VMWare, VirtualPC, etc.) allows an individual host system to transparently implement a virtualization (also known as an “abstraction”) of a guest system that will emulate a real host (I/O devices, software and operating system). 7. (U) Regardless of the implementation used, all virtualization solutions utilize a Virtual-Machine Monitor (VMM) and a hypervisor. The VMM manages the resources of the host system and provides an abstraction of one or more virtual machines whilst the Hypervisor is responsible for hosting and managing virtual machines and runs directly on the host's hardware. Diagrams demonstrating the standard system configuration, a basic VM configuration, a basic VMWare virtualization stack and the full VMWare virtualization stack can be found in Annexes A-D. 8. (U) Each virtual machine can run a complete operating system and its applications; software running within a virtual machine (including the virtualized operating system) is designated as "guest software". All guest software including the guest OS runs in user mode; only the VMM runs at the most privileged level (kernel mode). 9. (U) The host OS, as demonstrated in Annex B, is used to provide portable access to a wide variety of I/O devices; VMMs serve to export hardware-level abstractions to guest software using emulated hardware. The guest OS interacts with the virtual hardware in the same manner as it would with real hardware; these interactions are trapped by the VMM and emulated in software, thereby allowing the guest OS to run without modification whilst maintaining control over the system at the VMM layer. 10. (U) A VMM can support multiple OSes on a single computer by multiplexing the system's hardware, thereby providing the illusion of multiple, distinct virtual machines all of which can run an independent OS and applications. The VMM also isolates all resources of each virtual machine by the use of redirection. 11. (U) Several products are available that allow the user to implement virtual machines; these include, but are not limited to: a. VMWare (*nix and Windows - screen captures of VMWare in action can be found in Annex E); b. Microsoft Virtual Machine (Windows); and c. Xen (*nix). 4

Samuel T. King et al. "Sub Virt: Implementing Malware with Virtual Machines".

5

Virtual Machine -A virtual machine is a operating enviroment completely defined and implemented in software rather than hardware that functions in conjunction with, yet independent of, a physical host/operating system.

2

12. (U) Lastly, two items are worthy of note that will be of greater importance later in this discussion – CPU based VM extensions and newer BIOS6 implementations. The newest generation of CPUs has implemented inherent virtualization extensions on the chip in order to facilitate virtualization and new BIOS versions accommodate this new technology. 13. (U) Although these extensions do not run as a native virtual machine, they do provide improved functionality in the virtual environment. The security trade off in doing so, however, is that the virtual machines may be more easily implemented on a host and consume less of the host's resources. Further, recent BIOS implementations allow the user to disable these extensions and future BIOS versions may enable users to fully disable virtualization altogether. Free Your Mind - Virtual Machine Rootkits7 14.

(U) Normal rootkits are limited in two ways, a. they have been unable to gain an advantage over modern antimalware solutions (anti-virus scanners, intrusion prevention/detection systems, etc.); and b. they are faced with the difficulty of balancing functionality and invisibility - complex, general purpose malware is much easier to detect than simple, single purpose malware.

15. (U) Both of the aforementioned limitations are addressed with the implementation of VMRs; this development in rootkit technology allows significantly more control over a machine with significantly more stealth than a mundane user/kernel level rootkit. 16. (U) This heightened degree of stealth and control is accomplished by installing a VMM underneath an existing OS and moving the original OS into a virtualized environment. VMRs also allow the implementation of a plethora of malicious services by allowing them to execute in a disparate OS that is protected from the host system.

17. (U) VMRs utilize a separate virtual machine implementation known as the "Attack OS" (AOS) that is invisible from the host and its OS; none of the system states or events associated with the AOS are visible from the host's perspective, effectively rendering any running applications with the AOS invisible. 18. (U) As detailed in their whitepaper "Sub Virt: Implementing Malware with Virtual Machines",8 the Sub Virt research team described the three types of malware that could be clandestinely implemented on a target system using the AOS: "The ability to run invisible malicious services in an attack OS gives intruders the freedom to use user-mode code with less fear of detection. We classify malicious services into three categories - those that need not interact with the target system at all, those that observe information about the target system, and those that intentionally perturb the execution of the target system. In the remainder of this section, we discuss how (VMRs) support each class of service.

6

7 8

BIOS - "Basic Input/Output System"; the software that is responsible for booting a computer, initializing the hardware and handling input-output functions. Samuel T. King et al, op. cit. Samuel T. King et al, op. cit.

3

The first class of malicious service does not communicate with the target system. Examples of such services are spam relays, distributed denial-of-service zombies, and phishing web servers. A (VMR) supports these services by allowing them to run in the attack OS. This provides the convenience of user-mode execution without exposing the malicious service to the target OS. The second class of malicious service observes data or events from the target system. (VMRs) enable stealthy logging of hardware-level data (e.g. keystrokes, network packets) by modifying the VMM’s device emulation software. This modification does not affect the virtual devices presented to the target OS. For example, a (VMR) can log all network packets by modifying the VMM’s emulated network card. These modifications are invisible to the target OS because the interface to the network card does not change, but the (VMR) can still record all network packets. (VMRs) can use virtual-machine introspection to help observe and understand the software-level abstractions in the target OS and applications. Virtualmachine introspection enables malicious services to trap the execution of the target OS or applications at arbitrary instructions. When these traps occur, a malicious service can use virtual machine introspection to reconstruct data and abstractions from the target system. For example, if a target application uses an encrypted socket, attackers can use virtual-machine introspection to trap all SSL socket write calls and log the clear-text data before it is encrypted. This logging is transparent to the target OS and applications since the malicious code runs outside of the target and also because virtual-machine introspection does not perturb the state of the target system. The third class of malicious service deliberately modifies the execution of the target system. For example, a malicious service could modify network communication, delete e-mail messages, or change the execution of a target application. A (VMR) can customize the VMM’s device emulation layer to modify hardware-level data. A (VMR) can also modify data or execution within the target through virtual-machine introspection." 19. (U) As both the rootkit proper and any malicious services related to its functioning are protected from the host system, VMRs are extremely difficult to detect and/or eradicate as their state cannot be accessed by software running on the host system; this renders standard security measures (e.g. IPS/IDS and anti-virus solutions) that are effective against kernel/user mode rootkits completely impotent. Welcome to the Desert of the Real - Enter SubVirt 20. (U) In March of this year, a joint Microsoft/University of Michigan research team successfully implemented a PoC9 VMR that they dubbed "SubVirt". In this implementation, they successfully demonstrated that a VMR could move the host operating system into a virtual environment and host arbitrary malware on the AOS.

9

PoC - "Proof of Concept"; demonstration that in principle shows how a system may be protected or compromised, without the necessity of building a complete working vehicle for that purpose

4

21. (U) Although SubVirt was a success from a functional standpoint, several issues with this implementation exist, as expressed by Allessandro Perilli in his "SecurityZero" blog:10 "Problems in (SubVirt's) approach are huge:

10

•

Finding space for malicious host operating system if the rootkit puts the victim OS in a VM mapping its raw partition, it has to find enough free space from that partition where to install the host OS (the research suggest the rootkit to disable victim OS swap file and use that space).

•

Hiding new virtualized hardware Maybe the most complex task: when the original operating system is put in the virtual machine it has to interact with new, virtualized hardware, which is different from the physical one and will trigger a driver installation process. Even if this operation can be hidden completely some things will not work in the usual way: consider for example a gaming desktop calling for enhanced 3D operations in his last-generation display card.It's not impossible to do but at today even VMware has serious troubles to provide an advanced set of virtualized hardware. I have difficulties believing this can be achieved by a rootkit developer without years of research.

•

Hiding highly degraded performances In my reversed scenario on the first part of this post I considered that a stealth VM would degrade victim OS performances using part of its memory. In this case it's even worst since the rootkit host OS is consuming memory as well but also every computation and I/O operation is slowed down by virtualization overhead.

•

Hiding at boot time The rootkit has to hide itself at boot time until the host OS is loaded, the VMM is initialized and the victim OS starts to boot."

Alessandro Perilli. SecurityZero Blog. "Rootkits Powered by Virtualization".

5

22. (U) In addition to the points raised above, SubVirt also has several other concerns that render the PoC impractical as an effective malware implementation:11 a. the SubVirt implementation is not standalone - a commercial virtualization product (e.g. MS Virtual PC or VMWare) is utilized to implement the virtual environment; b. the use of an commercial virtualization product makes the implementation subject to easy detection; c. SubVirt is persistent - it must take control of the target OS during the boot phase - this can be easily detected using offline analysis techniques; and finally d. SubVirt runs on x86 architecture - as this architecture does not meet the Popek and Goldberg requirements,12 true virtualization cannot be implemented. 23. (U) Despite these issues, the success of the SubVirt PoC represents a grand advance in rootkit design and effectively released the proverbial genie from the bottle with regards to VMRs. Swallowing the Blue Pill - Joanna Rutkowska's VMR Implementation 24. (U) At a recent Blackhat conference, Ms. Joanna Rutkowska, an information security researcher working for a Singaporean information security company, revealed a VMR she designated “Blue Pill”. Blue Pill utilizes the new AMD processor's VM extensions as an implementation assist and represents a huge leap forward in VMR technology. 25. (U) The primary impetus for the design of Blue Pill was to engineer a VMR which: a. does not rely on a singular concept to remain undetected; b. cannot be detected, even though the concepts associated with the implementation are known to the public; and c. cannot be detected even though its source code is known to the public.

11

Joanna Rutkowska. "Subverting Vista Kernel for Fun And Profit".

12

The Popek and Goldberg virtualization requirements are a set of requirements necessary for a computer architecture to efficiently support full system virtualization; they were introduced by Gerald J. Popek and Robert P. Goldberg in their 1974 article "Formal Requirements for Virtualizable Third Generation Architectures".

6

26.

(U) These design goals being stated, Blue Pill differs from SubVirt in that it: a. exploits the VM extensions (e.g. AMD Pacifica and Intel VT-x13) inherent in the new generation of processors to provide full virtualization; b. provides an inherent, "ultra-thin" hypervisor to facilitate control of the target system; c. installs on the fly without restarting the system and without any BIOS or boot sector modifications; d. is non-persistent on reboot of the target system; and e. once fully implemented, it is undetectable by any practical means.

27. (U) Like SubVirt, Blue Pill technology facilitates the implementation the three types of malicious services as discussed earlier; however, in this case, the services would be virtually undetectable. Considering the furtive advances represented by the Blue Pill implementation, VMR technology now displays the potential to be a viable threat in the near future. Defending Zion - VMR Defence Strategies 28. (U) Despite the threat posed by future VMRs, proactive defensive action can be undertaken to mitigate the risk of future exploitation and/or compromise:

•

Selective Acquisition - Restrict the future acquisition of computing platforms to those that utilize processors without inherent VM extensions.

•

Secure BIOS Settings - Ensure that VM extensions, when supported are disabled in the BIOS settings of all current and future computing platforms.

•

BIOS Upgrades - When possible, ensure that all future BIOS upgrades include a facility to disable virtual machine support and/or VM extensions.

•

Custom Hypervisor - Engineer or acquire a custom hypervisor solution that would prevent the implementation of unauthorized VMs; this solution could then be deployed on installed network assets.

•

Custom Detection Software - Engineer or acquire custom detection software that provides for the detection of VM extension virtual modes.

•

Detection Software Deployment - VM detection software that is currently available (e.g. Rutkowska's "Red Pill"14) should be deployed to all concerned parties that are responsible for the auditing, accreditation or forensic analysis (e.g. NVAT, forensics teams, VIRT, and base/station ISSOs) in order to facilitate auditing should it become necessary.

13

Pacifica and VT-x are the codewords respectively assigned to AMD and Intel's VM extension solutions; these extensions will be implemented on the new generation of processors being developed.

14

Joanna Rutkowska. "Red Pill: How to Detect VMM Using (Almost) One CPU Instruction".

7

How Deep the Rabbit Hole? - The Future 29. (U) VMRs are a relatively new technology that is still in the early stages of development. As of this writing, all of the VMRs developed thus far are either experimental or PoC; no practical implementation of this technology has been noted in the wild. 30. (U) This being stated, VMRs represent a great leap forward in rootkit technology and it is only a matter of time before it is ported to a viable rootkit implementation; one can expect to be VMRs to be a significant threat to the integrity of the organization's networks in the future. 31. (U) Considering the potential threat this technology may pose in the future, the organization should be proactive and the recommendations below implemented as soon as fiscally and technically possible. CONCLUSIONS & RECOMMENDATIONS 32. (U) Although not a clear threat as of this writing, it is only a matter of time before VMR technology is evolves to the point that it can be deployed in a viable malware implementation. 33. (U) Bearing this in mind, the following recommendations are hereby suggested in order to mitigate the threat to the organization: a. avoid the purchase of platforms utilizing processors that support virtual machine extensions; b. where possible, disable virtual machine extensions and virtual machine support in the BIOS of deployed platforms; c. upgrade the BIOSes of deployed platforms to newer versions that allow virtual machine support/VM extensions to be disabled; d. the engineering and deployment or acquisition of a custom VMM/Hypervisor based solution that will prevent the implementation of unauthorized third party virtualization solutions; e. the engineering and development or acquisition of software designed to detect VM extension virtual modes; and f. the immediate deployment of VMR detection software.

8

34. (U) Any questions regarding this I&W report may be addressed to the undersigned.

E.L. Mac Daibhidh, CD Cpl Special Operations Analyst DND CIRT IH&AA Team Special Operations Cell 613-945-7748 Attachments: Annexes A-G References

9

(U) Annex A – Standard System Configuration

15

The diagram above demonstrates the standard system configuration which is comprised of three primary constituents: a. Host Applications - consists of the software, exclusive of the operating system, that are running on the system; b. Host Operating System - consists of the software that controls the components of a computer system and facilitates the operation of the host applications; and c. Host Hardware - the physical equipment of a computer system, including the central processing unit, memory, data-storage devices, I/O devices, etc.

15

Samuel T. King et al, op. cit.

A-1

(U) Annex B – Virtual Machine Implementation Configuration

16

The diagram above demonstrates the standard configuration of a system with a virtual machine implementation which is comprised of six primary constituents: a. Host Applications, Host Operating System and Host hardware - as per the standard system configuration system above; b. Virtual Machine Monitor - manages the resources of the underlying hardware and provides an abstraction for one or more virtual machines (the virtual machine abstraction is contained within the dashed lines); c. Guest Operating System - the operating system running within the virtual machine abstraction - this does not have to be in common with the host operating system (e.g. a Windows host can run Linux as a guest operating system; and d. Guest Applications - the software running within the virtual machine abstraction. The VMM provides the abstraction of a virtual machine (contained within the dashed lines in the diagram), each of which can run a complete guest operating system and a set of guest applications. The host operating system and its host applications are used to provide convenient access to I/O devices and to run VM services.

16

Samuel T. King et al, op. cit.

A-2

Annex C - Basic VMWare Virtualization Stack

17

The diagram above demonstrates the basic VMWare virtualization stack and the placement of the VMMs and Hypervisor within the stack; most other virtualization implementations are similar.

17

Jack Lo. "VMWare and CPU Virtualization Technology".

A-3

(U) Annex D - Full VMWare Virtualization Software Stack

18

The diagram above demonstrates VMWare's full implementation of the virtualization software stack; other virtualization stack implementations may differ.

18

Jack Lo, op. cit.

A-4

Annex E – VMWare Screen Captures

A-5

The screen captures above demonstrate a VMWare installation implementing a Windows XP virtual machine in various stages of startup.

A-6

(U) Annex F – Operating System Compromised with VM Rootkit

19

The diagram above demonstrates how an existing target system can be moved to run inside a virtual machine provided by a VMM. The components of the virtual machine rootkit consist of the malicious services, host operating system and the VMM itself.

19

Samuel T. King et al, op. cit.

A-7

(U) Annex G - Acknowledgements This being stated, the majority of the information regarding network based covert channels was gleaned from the works of: a. Mr. Samuel T. King, Peter M. Chen, Yi-Min Wang, Chad Verbowski, Helen J. Wang and Jacob R. Lorch ("SubVirt: Implementing Malware' with Virtual Machines"); and b. Ms. Joanna Rutkowska (multiple papers & personal blog). Gracious thanks are hereby extended to these professionals without whose superb work this report would not have been possible.

A-8

References Anagnostakis, K.G. et al. "Detecting Targeted Attacks Using SHADOW Honeypots". Proceedings of the 2004 USENIX Security Symposium. August 2005. Accessed on 25 August 2006. http://www.ics.forth.gr/dcs/Activities/papers/replay.pdf. Author unknown. "How to Write a Rootkit". Linux Magazine, Issue #69, August 2006: pp. 22-29. Dai Zovi, Dino A. "Hardware Virtualization Rootkits". Date unknown. Accessed on 02 September 2006. http://www.blackhat.com/presentations/bh-usa-06/BH-US-06Zovi.pdf. Garfinkel, T. et al. "Virtual Machine Introspection Based Architecture for Intrusion Detection."Proceedings of the 2003 Network and Distributed System Security Symposium". February 2003. Accessed on 26 August 2006. http://suif.stanford.edu/ papers/vmi-ndss03.pdf. Joshi, A. et al. "Detecting Past and Present Intrusions Through Vulnerability Specific Predicates". Proceedings of the 2005 Symposium on Operating System Principles. October 2005. Accessed on 26 August 2006. http://www.eecs.umich.edu/~kingst/ introvirt.pdf. King, Samuel T. et al. "SubVirt: Implementing Malware with Virtual Machines". Date unknown. Accessed on 02 September 2006. http://www.eecs.umich.edu/virtual/ papers/king06.pdf. King, Samuel T. et al. "Debugging Operating Systems with Time-Traveling Virtual Machines". Proceedings of the 2005 USENIX Technical Conference. April 2005. Accessed on 25 August 2006. http://www.usenix.org/event/usenix05/tech/ general/king/king.pdf. Lo, Jack. "VMWare and CPU Virtualization Technology". Date unknown. Accessed on 30 September 2006. http://download3.vmware.com/vmworld/2005/pac346.pdf. Microsoft Corp. "Windows Preinstallation Eniroment Overview". 2005. Accessed on August 25 2006. http://www.microsoft.com/whdc/system/winpreinst/ WindowsPE.over.mspx. Naraine, Ryan. “VM Rootkits: The Next Big Threat?”. 10 March 2006. Accessed on August 25 2006. http://www.eweek.com/print_article2/0,1217,a=173285,00.asp. Ou, Geroge. “Blue Pill The First effective Hypervisor Rootkit”. 15 August 2006. Accessed on September 23. http://blogs.zdnet.com/Ou/?p=295. Perilli, Alessandro. "Rootkits Powered by Virtualization". 16 March 2006. Accessed on 15 October 2006. http://www.securityzero.com/2006/03/rootkits-powered-byvirtualization.html. Popek, G.J et al. Communications of the ACM, Volume 17, Number 7. "Formal Requirements for Virtualizable Third Generation Architectures". July. 1974. Accessed on 14 October 2006. http://www.cis.upenn.edu/~cis700-6/04f/papers/ popek-goldberg-requirements.pdf.

i

Rutkowska, Joanna. "Red Pill: How to Detect VMM Using (Almost) One CPU Instruction". November 2004. Accessed on 14 October 2006. http://invisiblethings.org /papers/redpill.html. Rutkowska, Joanna. "Subverting Vista Kernel for Fun and Profit". 03 August 2006. Accessed on 02 September 2006. http://www.invisiblethings.org/papers/joanna% 20rutkowska%20-%20subverting%20vista%20kernel.ppt. Sugerman, J. et al. "Virtualizing I/O Devices on VMWare Workstation's Hosted Virtual Machine Monitor". Proceedings of 2001 USENIX Techical Conference. June 2001. Accessed on 25 August 2006. http://www.eecs.harvard.edu/~jonathan/reviews/ sugerman01vmware.txt. Singh, Amit. "An Introduction to Virtualization". Date unknown. Accessed on 23 August 2006. http://www.kernelthread.com/publications/virtualization. Tikhonova, Anna et al. "How Real is Virtual: Hiding Artifacts of Virtual Machines". 15 Dec 2005. Accessed on 01 September 2006. http://wwwcsif.cs.ucdavis.edu/ ~tikhonov/ecs235pw/documents/paper/detectvm.ps. Whitaker R. et al. "Configuration Debugging as Search: Finding the Needle in the Haystack" Proceedings of the 2004 Symposium on Operating Systems Design and Implementation. December 2004. Accessed on 25 August 2006. http://www.usenix.org/ events/osdi04/tech/full_papers/whitaker/whitaker.pdf. Wikipedia. "Blue Pill (Malware)". Last edited 12 October 2006. Accessed on 16 October 2006. http://en.wikipedia.org/wiki/Blue_pill_(malware).

ii