HYPERVISORS

cross-site exploits. But perhaps the most effective and immediate remedy is yet another education campaign among users to stop them being so trusting. Whether you think thats a good thing is another matter. to security and defence, as well as the implications of technology for personal liberties and privacy. 2. Dan Goodin, Facebook summarily denies undeniable user-menacing security hole, The Register, 25 Aug 2008. <http:// www.theregister.co.uk/2008/08/25/ facebook_security_hole/> 3. E. Athanasopoulos, A. Makridakis, D. Antoniades, S. AntonatosK.G. Anagnostakis, S. Ioannidis and E,P. Markatos, Antisocial networks: turning a social network into a botnet, 2008. <http://www.ics.forth. gr/dcs/Activities/papers/facebot. isc08.pdf>

References
1. Shawn Moyer and Nathan Hamiel, Satan is on my Friends list: attacking social networks, August 2008. <https://www. blackhat.com/presentations/ bh-usa-08/Moyer_Hamiel/BH_US_ 08_Moyer_Hamiel_Satan_is_on_ my_Friends_List_Whitepaper.pdf>

About the author

Steve Mansfield-Devine has been a freelance journalist for more than 27 years and has contributed to more than 100 newspapers, journals and magazines. He has a particular interest in IT relating

Preventing hypervisor-based rootkits with trusted execution technology

Carlo Gebhardt, security researcher, Hewlett-Packard Systems Security Lab, Bristol, UK Chris I. Dalton, principal research engineer, Hewlett-Packard Systems Security Lab, Bristol, UK Richard Brown, senior research manager, Hewlett-Packard Systems Security Lab, Bristol, UK Virtualisation offers many benefits for data centres, developers as well as consumers. In data centres, virtualisation can help to increase utilisation of previously under-utilised servers, hence reducing operational cost. For developers and on the client side it can provide an easy try out feature for complex software, such as kernel development, unfamiliar operating systems, or even new application delivery models such as virtual appliances. to detect the presence of a hypervisor is of great interest for both malware authors as well as malware hunters. In this article we want to begin by exploring new virtualisation technologies that are available to modern platforms, followed by discussing how they can prevent hypervisor-based rootkits. We show in detail, memory protection via input/output memory management unit (IOMMU), dynamic roots of trust for measurement, and the trusted platform module (TPM), and examine how these concepts perform in this problem space. Due to platform availability, this article will mainly focus on Intels Trusted Execution Technology (TXT). However, the concepts are equally applicable to different vendors or products.

The fast adoption and deployment of virtualisation poses challenges for security
However, the fast adoption and deployment of this technology also poses challenges for security. The security aspects of virtualisation have been an ongoing field of research ever since the technology emerged in the 1960s. One of the first security analyses was carried out by Madnick and Donovan in the early 1970s. Since then researchers have been

investigating the various security benefits and threats of virtualisation.

The ability to detect the presence of a hypervisor is of great interest for both malware authors as well as malware hunters
Many papers have documented the use of virtual machines (VMs) for malware analysis.1,2 This has also generated new thinking amongst malware designers, who are now trying to hide their malicious behaviour while they suspect being inside a VM. Consequently, the ability

The impact of malware

Abusing virtualisation to mask malware as a hypervisor-based rootkit, has been independently presented by Rutkowska and Zovi in 2006.3,4 The hypervisor (or virtual machine monitor, VMM) is the critical part in this scenario. It is the privileged piece of
7

November 2008

Network Security

HYPERVISORS
software which runs underneath the actual operating system, creating the illusion of dedicated hardware for the operating system above it. We begin our analysis by assuming that initially no hypervisor is present. This leads to the following attack scenarios: Software virtualisation-based rootkit Hardware virtualisation-based rootkit. King et al presented a proof of concept rootkit for hosted hypervisors such as Microsofts Virtual PC and VMwares Workstation in 2006.5 These rootkits had to be initially installed with sufficient privileges so that they could subsequently modify the boot process to launch their own code. The detection of such malware is fairly easy as it has to be installed onto persistent storage. Additionally, the X86 non-virtualisable instructions give a good indication of the presence of a hypervisor. Software-based rootkits also have a major disadvantage, in that they have to implement virtualisation functionality and hardware support completely and precisely. This renders a universal applicable rootkit quite difficult, but still poses a threat for bare metal hypervisors which are tightly tailored to a specific set of hardware. Unfortunately, a more serious threat emerged with the hardware support for virtualisation introduced by AMD and Intel. The much talked about Blue Pill by Rutkowska claimed to be undetectable and hence created a lot of controversy.3 This was mainly because it targeted new software and hardware techniques such as Windows Vista and AMDs Pacifica. However, it also targeted a long feared threat the undetectable malware. This stealth property was based on the fact that the malware could be executed as a hypervisor and thus run underneath the actual operating system. This certainly makes detection even for experienced users more difficult, but not impossible. It was immediately followed by numerous articles on how to detect the Blue Pills hypervisor-based malware and on hypervisor detection mechanisms in general. Firstly, there will be a mapping between physical hardware and the
8

virtual interfaces, which the operating system will see. Secondly, the consumption of resources such as CPU time and memory will create a detectable anomaly on the system. Those anomalies will also be reflected in latency and timing characteristics. More importantly those techniques allow the detection of all hypervisors, and not only the Blue Pill. It remains to be seen how such rootkits and their countermeasures will perform in the wild and with the arrival of advanced virtualisation support for the popular X86 architecture, even more sophisticated methods to hide malware are likely to emerge. Virtualisation itself has certainly the potential to fundamentally change the way computing resources are consumed in the future. This poses both a challenge and an opportunity for security. Consequently, we discuss in the remainder of this article, how hypervisors can be made more tamper-evident.

The recent work conducted by McCune et al. on a reduced trusted code base outlines how a system could be trusted with only relying on a minimum amount of code, whilst providing hardware-supported isolation of security-sensitive code.6,7 Similar areas have been researched by Anderson et al. with the library OS. For instance, they allow an application to run directly on XEN without the requirement of a full-blown OS.8

Given the fact that the hypervisor is responsible for isolation, less code will result in less bugs, thus fewer potential security flaws but also less functionality
In addition to reducing the code base and attack surface, we also need to provide mechanisms to ensure hypervisor integrity. In the following we want to focus on how we can measure and possibly preserve the integrity of a hypervisor. For instance, can we prevent unauthorised code from being loaded into the hypervisor and how could we preserve its integrity while running?

Hardening the hypervisor

Hypervisors are different to past software sandboxing techniques, as they address isolation on a much lower level. Rather than isolating single processes, a hypervisor isolates whole operating systems. Each OS is further responsible for its own integrated security protection mechanisms. The hypervisor only handles access to the hardware and provides each isolated guest the illusion of running directly on dedicated hardware. If a malicious party manages to compromise one virtual system, it should not be possible to access resources used by different virtual guests or the host system. Given the fact that the hypervisor is responsible for isolation, less code will result in fewer bugs, thus fewer potential security flaws but also less functionality. While the code base of hypervisors, such as XEN, is relatively small (XEN 3.3 contains an estimate of 150k lines of code), it still forms a large code base, which has to be trusted. This renders an evaluation of code quite difficult, and as a result, there is a strong movement to minimise the trusted code base of the XEN hypervisor.

Trusting the hypervisor

The notion of trust in computing has been introduced by the Trusted Computing Group (TCG). Unfortunately, the term trust is often misunderstood in this context and sometimes even abused. We only rely on a trusted system to behave in a particular manner, this behaviour being enforced by the trusted computing software and hardware. The hardware protection mechanisms are realised within a Trusted Platform Module (TPM), which is integrated on the trusted computing platform. Numerous research projects are utilising the Trusted Computing integrity mechanism to ensure only a specific and trusted hypervisor is loaded. For example, Terrra is a trusted Virtual Machine Monitor which partitions general-purpose platforms into high assurance Virtual Machines, using virtualisation and Trusted Computing.9

Network Security

November 2008

HYPERVISORS
Another example is OpenTC, which is a European funded research project to create an open source trusted computing platform. The first OpenTC prototype utilises the concept of a trusted boot to measure the (XEN or L4 based) hypervisors. With the ongoing convergence of virtualisation and trusted computing, it is not surprising then, that chip manufacturers such as Intel and AMD combine virtualisation enabled hardware with trusted extensions. We will highlight in the following paragraph how we can use the concept of trusted computing combined with newest hardware enhancements to increase integrity assurance for a hypervisor. As mentioned earlier, we will focus on Intels Trusted Execution Technology in particular, based on platform availability. In 2008 Rutkowska and Wojtczuk presented a new type of malware, an attack on the hypervisor itself.10 The 2006 attack imitated a hypervisor in order to mask itself and defer detection. The new attack XenBluePill targets a running hypervisor. As the name suggests, they target XEN in particular, but some of the attack vectors are also applicable to other hypervisors. One of their latest attacks is based on Direct Memory Access (DMA), which is used by most hardware components in modern platforms, to efficiently access main memory. DMA attacks are not particularly new. They have already been researched and exploited in the past. It is the new target of the attack, which intends to overwrite parts of the main memory to insert a rootkit into the hypervisor, which is significant. This particular attack requires either physical access to the running machine or root access to XENs privileged Domain 0. We will discuss an attack mechanism later that is not bound to any of those restrictions. Without restrictions on access to the hosts main memory, any DMA capable device can alter the hosts main memory and thus, potentially modify parts of the hypervisor itself. New chipset features such as AMDs IOMMU and Intels VT-d route the devices DMA request through an MMU (Memory Management Unit). Hence the memory exposed to a device is abstracted from the physical layout and additionally protected through access control mechanisms. Interestingly, the work by Rutkowska and Wojtczuk also demonstrated how an IOMMU could be circumvented by reclaiming XEN memory from the dynamic random access memory (DRAM) controller itself. However, this does not represent a flaw in the IOMMU architectural design. It is rather an improper use of the chipsets protection facilities within one specific BIOS. There are other possible ways to hook into the hypervisor other then hardware-based attacks. Another method Rutkowska and Wojtczuk presented exploits a heap overflow in the FLASK security module, one of XENs own security modules. The XEN Security Module (XSM) is a generalised security framework, which removes security dependant functionality from XEN itself and allows custom security modules, such as FLASK, to utilise the XSM interface. The vulnerability identified by Wojtczuk exploited a buffer overflow in the FLASK security module. FLASK implements fine grained Mandatory Access Control (MAC) mechanisms into XEN, but it is disabled in the default build process. Even though this particular vulnerability has already been removed, it highlights once more the importance of a robust hypervisor as a fundamental building block for a secure virtualised architecture. As we have seen earlier, it is difficult to eliminate all security pitfalls at the same time. Many different entities with often orthogonal interests are involved. On the software side, considerable effort is taking place to reduce the trusted code base. On the hardware side we see efforts by Intel to provide a more secure hardware platform for virtualisation the Trusted Execution Technology. Consequently, we want to focus in the following section, on the TXT capabilities and outline how this, when carefully applied, could help to prevent hypervisor-based rootkits.

Checking the hypervisors integrity

As outlined above, checking the integrity to prevent a malicious hypervisor from being loaded is the first step to secure a virtualisation enabled platform. However, the static concept of a consecutive chain of measurements introduced by the TCG has been found to be not flexible enough for the requirements of a virtualised infrastructure. Dynamic mechanisms to start a hypervisor and migrate a running operating system to a hypervisor, have been introduced with AMDs and Intels security extensions. They offer new features, but also new opportunities for attackers to insert malware into and under the hypervisor. We have described previously how malware could hide a rootkit under an OS if no hypervisor is present. On systems where a hypervisor is already running, there are two different possible attack vectors imaginable: Placing a nested hypervisor underneath the actual hypervisor. Modifying the running hypervisor to inject malicious code. These could be achieved, for instance, by modifying the bootloader to boot initially into a malicious hypervisor, and also by modifying the hosts memory during runtime.

Trusted execution technology

Many changes to various parts of the platforms hardware are necessary, for instance, changes to the chipset and CPU to allow protected access to memory and I/O components. The trusted extensions are very complex and consequently require in-depth system knowledge. 11,12

On the software side, considerable effort is taking place to reduce the trusted code base. On the hardware side we see efforts by Intel to provide a more secure hardware platform for virtualisation
However, in order to explain how to prevent hypervisor-based rootkits, we will provide details where required and skip over other parts in order to maintain a good conceptual understanding.
9

November 2008

Network Security

HYPERVISORS
The TXT extensions are a good example of how Trusted Computing and virtualisation are merging. Hardware virtualisation support in the CPU and chipset is extended by a TPM, to provide trusted and sealed storage as well as reporting platform attestation. The TXT platform enhances the static root of trust for measurement (SRTM) by allowing a dynamic creation of protected VMs via a dynamic root of trust for measurement (DRTM). Instead of creating a consecutive chain of measurements starting with the BIOS, TXT enables the platform to start a measured environment anytime after the platforms initial boot. This so-called late launch can occur anytime during runtime and thus puts the root of trust dynamically into its hardware. The goal of this procedure is to bootstrap a measured launch environment (MLE), which can operate as the trusted base for an OS kernel or hypervisor. More broadly speaking, the MLE is the piece of software which utilises Intels Safer Mode eXtension (SMX). The launch occurs in different phases: Firstly, the MLE code and a special authentication module (SINIT AC module) are loaded into protected memory regions. The SINIT AC module is a platform and processor specific module to measure and enforce policies for the MLE. It is cryptographically signed by the platform vendor and authenticated by the platforms CPU. Secondly, the environment broadcasts the SENTER, provided by the new SMX extensions. This initialises hardware procedures to bring the chipset and processor into a protected state. Afterwards, the AC module is authenticated and launched. The AC module measures and checks the MLE in memory, and if it conforms to the platform policies, it launches the MLE. Finally, the MLE is responsible for dispatching every VMExit operation in order to maintain the measured environment. VMExit instructions are used to transit from a virtualised guest into the hypervisor. Eventually, to tear down a MLE, the GETSEC[SEXIT] is issued. Basically, it works in reverse to the GETSEC[SENTER] command. All processors are synchronised, remaining
10

Figure 1: TXT initialisation phase.

secrets are encrypted and trusted memory is scrubbed. After the GETSEC[SEXIT], the platform continues with normal operation. The above steps are outlined in Figure 1. The hardware extensions create the special protection environment required for the code and policy verification to be executed at a later stage. Together with the platform policy described below, the system is able to determine if the environment meets a pre-defined and trusted state.

default by the platform supplier.12 The SINIT AC module loads and enforces the policies, which are stored on the platform itself. Polices are kept inside the TPMs non-volatile (NV) memory to protect them from unauthorised access and to persist after power cycles. Intels TXT extensions define two different sets of policies: Supplier or default policy (PD). Owner-specific policy (PO). If no policy has been defined, the SINIT AC module allows any MLE with any configuration, if both policies are defined, they are combined. Each policy can contain a list of valid MLE measurements (typically SHA-1) as well as a list of valid platform configuration measurements. The pre-stored MLE measurements are then compared against

The launch control policy

Using the launch control policies (LCPs), the platform is able to determine whether the MLE meets a specific set of criteria. Those criteria might be defined by the platform owner, or defined as a

Figure 2: TXT policy ow.

Network Security

November 2008

HYPERVISORS
the measurements of the pending MLE. Further, the platform configuration value is checked against a policy defined platform control register (PCR). The PCRs are special protected registers contained within the TPM chip. As the TPM NV storage is very limited, the policy only contains one aggregated measurement. However, this measurement could also be the value of an externally stored list of measurements. If all requirements of the active policies are fulfilled, the SINIT AC module proceeds and launches the MLE. The policy enforcement model is a powerful tool for any platform supplier, as it enables them to define their policy by default. However, the platform owner can decide whether this policy will be enforced or not. Also, keeping a list of trusted environments and enforcing their policy in hardware means that it is much harder for potential malware to slip under the hypervisor. The Launch Control Policy flow is outlined in Figure 2. possibly sanitising a virtualisation-based rootkit. Unfortunately, the signature-based approach has certain disadvantages. Firstly, the malware could adapt easily by changing its signature and secondly, the low level position of the scanner renders maintenance quite difficult. Also, DeepWatch does not monitor the system management mode, which has been attacked in the past and recently for a new generation of rootkits.14 As a result, future integrity enforcement and protection mechanisms will have to be tightly tailored to, and integrated into, a platform. structure (VMCS) for instance stores and manages the state of the host system as well as the virtual machine. This control structure is embedded in hardware, which is potentially the best location to position a hardware-based integrity monitor.

About the authors

Carlo Gebhardt is currently a security researcher at the HP Labs in Bristol. He also is a PhD candidate with the Information Security Group at Royal Holloway University, London. His major research interests are virtualisation, trusted computing and system security. Carlo received his Diploma in Computer Engineering from the University of Applied Sciences, Ulm, Germany. Before he commenced his studies, he has worked for an IT security company. Chris I. Dalton is a principal research engineer in the Systems Security Lab, HP Laboratories, Bristol, UK. He has been working in the area of operating system and platform security for over 10 years whilst in HP Labs, and has a particular interest in pragmatic yet strong security mechanisms. Currently he is working in the area of machine virtualisation and security. As the Department Manager within the Trusted Systems Laboratory, Richard Brown is responsible for shaping the labs technology agenda and leading a team of IT security specialists at HP Labs in Bristol. Richards areas of interest include virus throttling and active countermeasures. He leads his team in the area of trusted infrastructure and virtualisation technologies. Richard joined HP Labs in 1987, and has also worked as a software engineer at GEC developing network protocols such as X25. Richard received a First Class Honours Degree in Mathematics and Computer Sciences from the University of Birmingham.

An outlook
The current risk level of hypervisor-based rootkits is still moderate, as virtualisation is not yet widespread enough. However, the threat remains a real one, since the current trend is to integrate virtualisation into future platforms. Classic OS-based detection mechanisms, such as memorybased integrity scanners or heuristic-based analysis, are not sufficient to detect rootkits on lower system levels. Hence, it is important to implement other protection mechanisms, such as TXT, rather than detection only schemes. In the ongoing game of hide and seek, implementing traditional malware is becoming increasingly complicated. Therefore attackers are looking for new, potentially easier targets. Also, attack mechanisms and counter measurements are becoming increasingly complex and use-case specific. We see an increasing number of a new types of OS-independent rootkits, such as system management or hypervisor-based ones. This indicates that malware authors have already adapted to new technologies and trends. In terms of hypervisor security, the platform or chipset level is currently the new battleground. Here, the TXT launch and policy enforcement process can prove a hypervisors integrity and are therefore the first step in the right direction of preventing hypervisor-based rootkits. Future chipset generations could possibly integrate permanent integrity monitoring and enforcing functionality to guarantee the integrity (and confidentially) of a hypervisor, not only during launch, but also during runtime. The virtual machine control

Preserving integrity
We have seen how we could install a trusted environment and prevent virtualisationbased rootkits. However, this cannot prevent possible flaws in the trusted software from being exploited. For instance, the attack on the FLASK module discussed previously could still be successful, even with TXT in place. This outlines once more the importance of a robust hypervisor.

The policy enforcement model is a powerful tool for any platform supplier, as it enables them to define their policy by default. However, the platform owner can decide whether this policy will be enforced or not
Consquently, we want to briefly introduce a hardware assisted, signature-based rootkit detection mechanism. In 2008, Bulygin et al. introduced a proof of concept design of a chipset-based rootkit detection.13 The so-called DeepWatch is embedded into the chipsets firmware, hence it runs underneath every hypervisor and potential rootkit.13 DeepWatch is capable of scanning, detecting and

References
1. Peter Ferrie, Attacks on virtual machine emulators. Tech. rep., Symantec Security Response, 2006. 2. Jedidiah R. Crandall, Gary Wassermann, Daniela A.S. de Oliveira, Su Zhendong, S. Felix Wu and Frederic T. Chong, Temporal search: detecting hidden malware timebombs with virtual machines. ASPLOS-XII: Proceedings of 12th International Conference on Architectural Support
11

November 2008

Network Security

NETWORKING RECON
for Programming Languages and Operating Systems. New York, NY, USA: ACM, 2006, 2536. Joanna Rutkowska, Subverting Vista kernel for fun and profit. Black Hat 2006, 2006 <http://www.blackhat. com/presentations/bh-usa-06/BHUS-06-Rutkowska.pdf> Dino A. Dai Zovi, Hardware virtualization rootkits, 2006. <http://www. blackhat.com/presentations/bh-usa06/BH-US-06-Zovi.pdf> Samuel T. King, Peter M. Chen, YiMin Wang, Chad Verbowski, Helen J. Wang and Jacob R. Lorch, SubVirt: implementing malware with virtual machines. SP 06: Proceedings of 2006 IEEE Symposium on Security and Privacy. Washington, DC, USA: IEEE Computer Society, 2006, 314327. Jonathan M. McCune, Bryan J. Parno, Adrian Perrig, Michael K. Reiter and Hiroshi Isozaki, Flicker: an execution infrastructure for TCB minimization, SIGOPS Oper. Syst. Rev. 42 (2008) 4: 315328. 7. Jonathan M. McCune, Bryan J. Parno, Adrian Perrig, Michael K. Reiter and Arvind Seshadri, How low can you go? Recommendations for hardware-supported minimal TCB code execution. ASPLOS XIII: Proceedings of 13th International Conference on Architectural Support for Programming Languages and Operating Systems. New York, NY, USA: ACM, 2008, 1425. 8. Melvin J. Anderson, Micha Moffie and Chris I. Dalton, Towards trustworthy virtualisation environments: Xen library OS security service infrastructure. Tech. rep., HP Laboratories, Bristol, UK, 2007. 9. Tal Garnkel, Ben Pfaff, Jim Chow, Mendel Rosenblum and Dan Boneh, Terra: a virtual machine-based platform for trusted computing. SOSP 03: Proceedings of 19th ACM Symposium on Operating Systems Principles. New York, NY, USA: ACM, 2003, 193206. 10. Rafal Wojtczuk, Subverting the Xen hypervisor, 2008. <http:// invisiblethingslab.com/bh08/papers/ part1-subverting_ xen.pdf> 11. David Grawrock, The Intel safer computing initiative. Intel Press, 2006. 12. Intel, Intel trusted execution technology measured launched environment developers guide, 2008. <http:// download.intel.com/technology/ security/downloads/315168.pdf> 13. Yuriy Bulygin and David Samyde. Chipset based approach to detect virtualization malware a.k.a. DeepWatch. Black Hat USA, 2008 <http://www. mnm-team.org/pub/Fopras/frit08/ PDF-Version/frit08.pdf> 14. Shawn Embleton, Sherri Sparks, and Cliff Zou, SMM rootkits: a new breed of OS independent malware. SecureComm 2008, Istanbul, Turkey, 2008.

3.

4.

5.

6.

Network reconnaissance
Siraj A. Shaikh, research officer, Department of Informatics and Sensors, Cranfield University, UK Howard Chivers, professor, Department of Informatics and Sensors, Cranfield University, UK Philip Nobles, lecturer, Department of Informatics and Sensors, Cranfield University, UK John A. Clark, professor, Department of Computer Science, University of York, UK Hao Chen, research associate, Department of Computer Science, University of York, UK Along with its wider reach in society, in the form of both mobility and relatively affordable access, the internet has transformed the world we live in, serving as bedrock for electronic commerce and other digital and communication services. It has become an integral part of the personal, professional, and economic spheres of our daily life. Global organisations, whether official, commercial, or social, are relying on it ever more to function, bringing an increasing need for a secure electronic infrastructure. The pervasive nature of the internet, one major factor behind its success, is also proving to be its main threat. Once connected to this global network, no one is more than a few clicks away from servers hosting websites that transact commerce worth millions or critical state-run networks that run sensitive operations. While such infrastructures are increasingly under threat from worm propa12

threat is posed by sophisticated intruders who: Attempt slow and subtle attacks Have a presence or access on the inside Target specific resources Possibly make use of zero-day exploits. Sabotage attempts launched by such intruders are likely to be more damaging and difficult to detect early on. An important first step that these intruders take is to perform intelligence gathering.1 This involves engaging in reconnaissance exercises to scan networks for connectable active hosts, enumerate services, and identify potential vulnerabilities that could be exploited. The more an intruder is aware of her target (in terms of topology, address space, and services) the greater her chances are of launching an exploit and successfully evading detection.

gation and script kiddies launching denial of service attacks, a more severe

Network Security

November 2008