Roberto Di

Federico Franzoni

Flavio Lombardi

HyBIS: Advanced Introspection for Effective Windows Guest Protection

Effectively protecting the Windows TM OS is a challenging task, since most implementation details are not publicly known. Windows OS has always been the main target of malware that have exploited numerous bugs and vulnerabilities exposed by its implementations. Recent trusted boot and additional integrity checks have rendered the Windows OS less vulnerable to kernel-level rootkits. Nevertheless, guest Windows Virtual Machines are becoming an increasingly interesting attack target. In this work we introduce and analyze a novel Hypervisor-Based Introspection System (HyBIS) we developed for protecting Windows OSes from malware and rootkits. The HyBIS architecture is motivated and detailed, while targeted experimental results show its effectiveness. Comparison with related work highlights main HyBIS advantages such as: effective semantic introspection, support for 64-bit architectures and for recent Windows versions (≥ win 7), and advanced malware disabling capabilities. We believe the research effort reported here will pave the way to further advances in the security of Windows TM OSes.

Introduction

Securing the Windows OS is a very challenging task, given its complexity and also given that its internals are not publicly known. Over time, a large set of malware has targeted vulnerabilities in Windows OSes and services. Due to the very large installed base of Windows OSes, there is a great amount of new malware produced every year, which implements advanced methods for detection avoidance. The problem is particularly interesting for recent Windows versions, which have not yet been fully analyzed/investigated by the research community.

Among the different kinds of malware, rootkits represent the most complex and dangerous threats. In fact, rootkits can alter the system's perception of itself, and conceal malicious activities over a large period of time. In particular, modern rootkits can directly manipulate memory structures to further enhance their stealthiness. As such, security tools can hardly detect them and are usually unable react to the infection. For this reason, rootkit detection is a vital task for protecting Windows and it is then fundamental to make it as effective as possible.

Motivation

Current monitoring approaches cannot provide an adequate level of protection against rootkits targeting Windows OSes. In fact, most solutions operate at the same level as rootkits do [START_REF] Battistoni | A Host Intrusion Prevention System for Windows Operating Systems[END_REF][START_REF] Mahapatra | An online cross view difference and behavior based kernel rootkit detector[END_REF][START_REF] Tsaur | Identifying rootkit infections using a new windows hiddendriver-based rootkit[END_REF]. By tampering with the functions leveraged by security tools, rootkits are able to evade detection from within the OS. Hence, anti-rootkit tools working at the OS level cannot be trusted in case of rootkit infection. When the OS is running in a virtual machine, however, this problem can be addressed in a different way. Such a scenario, in fact, allows an external observation of the OS, from a more trustworthy and isolated environment. This capability is provided by the hypervisor, which can directly access VM components without leveraging OS functions.

Such a capability enables the adoption of virtual machine introspection (VMI [START_REF] Hebbal | Virtual machine introspection: Techniques and applications[END_REF][START_REF] Lombardi | Secure virtualization for cloud computing[END_REF]), which consists of inferring the guest OS semantics from the analysis of the status of VM components. VMI provides a valuable tool to counter rootkits since they can hardly conceal their presence to a monitoring system not dependent on OS functions.

On the one hand, VMI on Windows guest is however hard in practice, as it requires some specific OS information in order to make sense out of raw machine data [START_REF] Hebbal | Virtual machine introspection: Techniques and applications[END_REF]. This is one of the challenges of our present work, and it is also one of the main contribution of this work. On the other hand, VMI can be supported by the use of forensic memory analysis (FMA), which provides the means for extracting OS information from raw memory data. In fact, as stated above, since modern rootkits manipulate memory to avoid detection, they can be identified by inspecting the same memory contents [START_REF] Kornblum | Exploiting the rootkit paradox with windows memory analysis[END_REF]. This is a clear advantage over rootkits and allows the implementation of more reliable security systems.

Moreover, once the infection has been identified, the hypervisor also allows an effective reaction. In fact, by leveraging unfettered access to physical resources, a security tool can directly manipulate the VM and stop rootkit activities.

All these features, render the hypervisor a very attractive place where to implement security functionalities. In this work, we will leverage advanced VMI and FMA to help securing Windows OSes in virtualized environments.

Contribution

This work introduces and discusses a novel effective approach for countering rootkits on a Windows OS running in a VM. The implemented security monitor is external to the target machine, similarly to some recent literature [START_REF] Harrison | ODinn: An In-Vivo Hypervisor-based Intrusion Detection System for the Cloud[END_REF][START_REF] Zhong | A virtualization based monitoring system for mini-intrusive live forensics[END_REF]. By leveraging VMI and current FMA tools, we developed a novel Hypervisor-Based Introspection System (HyBIS) for protecting a Windows OS from stealth malware, in particular from rootkits.

The proposed system extends the hypervisor to monitor the state of the running machine, to detect rootkits, and to react to the discovered anomalies. The monitoring functionality leverages VMI techniques to infer the guest OS status. In order to detect rootkits, guest memory is scanned for kernel objects which may have been hidden. Such a scan is performed on memory dump files by means of FMA techniques and tools. Although such tools are typically used for offline analyses, the proposed system utilises them in a live way, during the system execution. To this purpose, HyBIS provides a novel dumping system which allows improving the performance of the memory acquisition task. Furthermore, a novel reaction approach is implemented that makes use of the hypervisor to manipulate memory contents while the virtual machine is running. This capability is leveraged to prevent the execution of detected rootkit processes. HyBIS allows detecting and reacting to rootkits effectively on recent Windows OSes. HyBIS successfully proves that the combination of VMI and FMA provides a valuable tool for countering rootkits on Windows OSes.

Related Work

This section surveys most relevant related work and stresses the main differences with respect to our solution.

Zhang et al. [START_REF] Zhang | SPECTRE: A dependable introspection framework via System Management Mode[END_REF] leverage SMM, an advanced x86 execution mode, for detecting memory-based stealthy malware. Their SPECTRE framework can introspect a live operating system and supports both Windows and Linux OSes. However, this framework is vulnerable to hardware-based attacks, such as [START_REF] Zhang | Now you see me: Hide and seek in physical address space[END_REF]. Furthermore, their work is limited to Windows XP SP3.

In [START_REF] Hizver | Real-time deep virtual machine introspection and its applications[END_REF], Hizver and Chiueh make use of Volatility for the analysis of VM execution states. Their RTKDMS system is able to perform real-time monitoring at the hypervisor level. Differently from HyBIS, such an architecture leverages an additional VM for the introspection analysis. Again, the experiments are limited to Windows XP. Furthermore, their system does not tackle the rootkit threat specifically, neither it explores any reaction possibility.

Deng et al. [START_REF] Deng | Spider: Stealthy binary program instrumentation and debugging via hardware virtualization[END_REF] propose the SPIDER architecture, a stealthy program instrumentation and debugging framework built upon hardware virtualization. SPIDER enables monitoring memory read/write at any address. Nonetheless, unlike HyBIS, it requires an in-guest agent which modifies the guest OS kernel.

In [START_REF] Lengyel | Scalability, fidelity and stealth in the DRAKVUF dynamic malware analysis system[END_REF], Lengyel et al. describe DRAKVUF, a novel dynamic malware analysis system based on Xen, which improves hardware resources usage efficiency. DRAKVUF takes advantage of the hardware virtualization extensions to provide a transparent and scalable environment to enable in-depth analysis of malware samples. In this case, the target OS is Windows 7 SP1 in both 32-and 64-bit versions.

Differently from DECAF [START_REF] Henderson | Make it work, make it right, make it fast: Building a platform-neutral whole-system dynamic binary analysis platform[END_REF] which only supports introspection of 32 bit guests, our HyBIS approach also allows inspecting 64 bit Windows guests. Furthermore, Henderson et al. declare that VMI has limitations against some types of attack (due to the ability of the guest attacker to modify memory contents at will). While we agree that memory analysis can be circumvented in theory, we believe in practice continuous monitoring and effective/smart diff-deltas can render an attack much less practical.

As regards memory forensics issues, an interesting work by Balzarotti et al. [START_REF] Balzarotti | The impact of GPU-assisted malware on memory forensics[END_REF] assesses the impact of GPU-assisted malware [START_REF] Di Pietro | CUDA Leaks: A Detailed Hack for CUDA and a (Partial) Fix[END_REF] on memory forensics. They discuss different techniques that malware can adopt to hide its presence on GPUs. Their analysis shows that, by offloading some computation to the GPUs, it is possible to successfully hide some malicious behavior.

Harrison [START_REF] Harrison | ODinn: An In-Vivo Hypervisor-based Intrusion Detection System for the Cloud[END_REF] suggests an approach that is somewhat similar to HyBIS. However it aims to be integrated into other IDS solutions [START_REF] Pietro | Intrusion Detection Systems[END_REF], and mostly focuses on the analysis phase. HyBIS, instead also explores the novel reaction capabilities given by the combination of VMI and FMA techniques.

HyBIS -Approach and Functionalities

This section describes the approach behind HyBIS, the proposed Hypervisor-Based Introspection System for Windows. HyBIS combines FMA techniques with the VMI approach. As mentioned above, the main goal of our work is to improve Windows security in virtualized environments. In particular, our research focuses on protecting such OS from rootkits. In order to protect Windows from modern rootkits, we mostly focused our studies on the RAM component. Memory, in fact, stores both code and data and is involved in almost every operation performed on the machine during OS execution. Thus, RAM can be considered the most complete source of information about the status of a running OS at a specific time. For such a reason, modern rootkits use to manipulate memory to conceal their activities and resources. Nonetheless they reside in RAM while running, thus giving the opportunity to detect their presence. Hence, memory is the best place where to look for inferring the current status of the target machine. FMA enables performing such a task in an effective and convenient way.

The basic idea we followed for the development of our security system was that the hypervisor can do more than what it is intended for. The chosen design approach was then to augment the hypervisor capabilities by means of introspection techniques. We extended the hypervisor by introducing the following functionalities: i) Monitoring: the hypervisor is enabled to monitor the machine state in order to realize if something anomalous is happening; ii) Analysis: the hypervisor is enabled to analyze the state of the guest OS in order to detect the presence of rootkits; iii) Reaction: the hypervisor is enabled to react when a rootkit is detected and block its activities. The above functionalities leverage internal hypervisor functions as well as external libraries and tools. The internal functions provide direct access to virtual machine hardware components. In particular, they allow to monitor the VM CPU and physical memory. By checking the CPU state and reading the memory contents, it is possible to implement a transparent monitoring function. Furthermore, the write access to memory can give the ability to perform changes into a running VM.

By making use of external tools and libraries, the hypervisor can be given even more capabilities. For instance, by integrating memory forensic functions, it is possible to implement advanced analysis techniques, which may allow detecting the presence of rootkits into the system.

Monitoring -Checking The System State: the virtual machine state can be analyzed by means of VMI. As stated before, the hypervisor has the ability to access virtual hardware resources directly, allowing the monitoring of all the VM components. In particular, we chose to monitor CPU and memory as they are core components of the machine.

CPU state changes can be easily monitored by using internal hypervisor functions. Such functions allow, for instance, checking the current operating mode, or inspecting registers.

VM memory contents changes can be monitored by means of differential dumps. With this approach, memory dumps are periodically generated to check if a particular area has been modified. In order to implement such a functionality, an initial memory snapshot must be taken at a specific time. Such a snapshot can then be used as basis for the comparison with the following checkpoints.

Analysis -Detecting Rootkits: as previously explained, modern rootkits are able to manipulate memory objects at runtime to conceal their activities. Hence, in order to detect rootkits, the analysis functionality should focus on the memory contents. This kind of analysis requires advanced forensic techniques to discover an infection. A convenient approach would be then to make use of functions from an external forensic tool or library.

Memory forensic analyses are commonly based on memory dumps. Hence, a memory acquisition functionality is required to make use of the forensic tools. Fortunately, most hypervisors implement their own dumping facility which can be used to acquire guest memory. Such a facility can be easily expanded/adapted to improve the acquisition process and realize the above-mentioned differential dumping functionality.

Reaction -Countering Rootkits: in order to react when a rootkit is detected, some kind of action has to be taken to prevent it from performing further activities. As such, guest memory can be used to implement the reaction functionality.

Since rootkits, even if concealed, reside in memory, it would be a good approach to counter them into the same place. Once again, hypervisor functions can come in handy: by writing into guest memory, it could be possible to delete the detected rootkit from memory, or to block its current execution.

HyBIS Functionalities

We set up to implement four high-level functionalities in HyBIS: Automatic boot dump generation; Smart differential dumping; Detection of hidden rootkit processes; Blocking of hidden rootkit processes. In the following, we detail each functionality.

Automatic Boot Dump Generation: as explained above, the monitoring functionality should allow deciding when an analysis operation would be appropriate. Since the analysis functionality operates over memory dumps, we decided to automatically generate a dump on the basis of some hardware event.

In particular, we chose to monitor the VM during the boot phase in order to produce a dump at the very beginning of the Windows loading procedure.

This choice has a twofold reason. Firstly, it aims at determining the first feasible moment for analyzing a memory dump with a forensic tool; in fact, these tools need the kernel to be loaded in order to work. Secondly, such initial dump can be used as starting point for a following monitoring of the memory; in fact, after the kernel has been loaded, most of the system areas remain fixed during the rest of OS execution.

Hence, this function should allow HyBIS to automatically generate a memory dump as soon as the Windows kernel process starts.

This objective has been chosen to demonstrate how, by means of introspection, the VM state monitoring can be effectively used for determining meaningful moments of the OS execution.

Smart Differential Dumping: besides the CPU, the monitoring functionality can check specific virtual machine memory areas for changes, in order to decide if an analysis operation is needed.

As stated above, a differential approach can be taken to perform this kind of monitoring. However, memory acquisition can be a very onerous task to perform, especially when it has to be repeated over time. So, it is important to do such an operation efficiently in order to not compromise the guest system performance. Since only some memory ranges need to be checked, there is no need to dump the whole memory at every checkpoint. Instead, it should be enough to acquire only the ranges we are interested in.

This function should allow HyBIS to update a previously created dump by acquiring selective ranges and overwriting them into the corresponding areas. Previous contents of such ranges should be backed up in separate files in order to allow the comparison between different checkpoints. With such an approach, it can be said that HyBIS uses "dynamic" dumps.

Dynamic dumps can also be used to improve the acquisition process necessary for the forensic analyses. In fact, since such analyses usually involve only some ranges of the whole dump, it is possible to use the update mechanisms described above, to perform the analyses of different checkpoints without needing to create multiple dumps of the whole memory.

This objective has been chosen to demonstrate how monitoring the VM memory can be both effective and efficient.

Detection of hidden rootkit processes: it is well-known that rootkits try to hide their processes to avoid detection. This is effectively obtained by implementing the DKOM technique [START_REF] Hoglund | Rootkits: Subverting the Windows Kernel[END_REF]. In particular, a rootkit that wants to hide a process, could remove the corresponding object from the active process list. In fact, Windows uses two lists of processes: one for scheduling, and one for tracking. A process whose object is removed from the tracking list, will be invisible while still active. As such, hidden processes can be detected by means of a cross-view analysis 5 . More specifically, this can be done by scanning memory for process objects, and comparing the results with the active process list. If a scanned process is not present in this list it is likely to be a hidden rootkit process. This function should allow HyBIS to detect hidden processes by creating a memory dump and scanning it for concealed process objects.

This objective has been chosen to demonstrate how FMA can help in detecting rootkits on running guest OSes.

Blocking of hidden rootkit processes: once a hidden process has been detected, it should be blocked to prevent it from keeping performing malicious activities. This action will not clean the infection but it could be a first step to defeat the rootkit.

A good idea for blocking a hidden process would be to exclude it from scheduling, thus preventing its execution. This can be done using the DKOM technique in a similar way as that used by rootkits. More specifically, we can block a hidden process by removing the corresponding object from the scheduling list. This function should allow HyBIS to manipulate the VM memory in order to prevent the rootkit process to be executed.

This objective has been chosen to demonstrate how the hypervisor capabilities allow an effective reaction to a rootkit infection by means of memory manipulation.

HyBIS -Design, Architecture and Implementation

This section shows how HyBIS was designed to extend the hypervisor capabilities for securing a guest Windows OS from the rootkit threat. First, we show the overall HyBIS operation from a high-level point of view. Next, we describe the HyBIS architecture. Finally, we describe and motivate the technologies chosen to build up the first HyBIS prototype, and the most relevant implementation details.

The high-level overview of the HyBIS operating mode is depicted in Figure 1a. The new functionalities are designed to work as a closed loop control system. The monitoring phase extracts information from a running machine and intercepts events which could reveal the presence of rootkits. The analysis phase examines the system in order to evaluate if a rootkit infection occurred. In such a case, it triggers the reaction phase, otherwise it returns to the monitoring phase. The reaction phase tries to remove the infection or block the rootkit for preventing further malicious activities.

The monitoring and reaction functionalities leverage the introspection and control capabilities of the hypervisor. The analysis functionality is based on forensic functions provided by external tools but needs some additional intervention to interpret the results and taking further actions. Since the complexity of such a task, some kind of intelligence is needed to take decisions. This is represented by the evaluator, which is an external component that can be inserted into the analysis phase. The evaluator functionality can be performed by a human examiner as well as an external plugin which implements advanced AI techniques, such as Machine Learning, Expert Systems, Human Expertise, and so on. The HyBIS architecture is shown in Figure 1b. As can be seen, on the guest side, there is a Windows OS running on a virtual machine (VM). On the host side, there is the hypervisor that controls the VM, which incorporates the HyBIS component. The HyBIS component extends the hypervisor with the new security functionalities. Such functionalities are implemented by three components, described below. Outside the hypervisor, on the same side, there is the memory forensic tool, which is used by HyBIS to provide advanced analysis capabilities.

HyBIS Components: HyBIS includes three components, running in parallel with the guest OS, without interrupting/suspending its execution:

-Smart Memory Dumper (SMD): this component allows creating the dynamic dumps described in the previous section; it leverages the hypervisor to read the VM's RAM contents and create or update dump files on the host disk; -Hidden Process Finder (HPF): this component allows detecting hidden processes running in the guest Windows OS; it leverages the external memory forensic tool to perform analyses on the dump files created by SMD;

-Rootkit Process Blocker (RPB): this component allows blocking a detected rootkit process on the guest OS by preventing it from being scheduled for execution; it receives from HPF the information on the detected process and leverages the hypervisor for manipulating the VM's RAM.

Technology Info

In this section we discuss the technologies selected for the development of the first HyBIS prototype. In particular, the target Windows version, the hypervisor and the forensic tool, have been chosen due to their effectiveness and wide deployment base.

The Target OS: most of the latest security-related work still focuses on Windows XP or Windows 7 OSes. However, Windows 8 introduced some internal changes (such as [START_REF] Ionescu | How control flow guard drastically caused windows 8.1 address space and behavior changes[END_REF]) and security mechanisms (see [START_REF] Technet | What's changed in security technologies in windows 8.1[END_REF]) which partially invalidate previous results. For instance, the removal of the KiFastSystemCall function makes all rootkit techniques based on this function unusable [START_REF] Tech | Intercepting all system calls by hooking kifastsystemcall[END_REF]. Furthermore, the latest Windows 10 OS appears to keep such changes, rendering previous work yet more obsolete.

At the time we started the development of HyBIS, Windows 10 was only available in its Technical Preview release. Hence, we selected Windows 8.1 (which is much more widespread then Windows 8) as the target of our experiments.

We initially decided to focus our tests on the 32-bit version since it is more efficient when performing extensive memory-related experiments. Furthermore, the 64-bit version which implements more advanced security mechanisms, would have limited our malware testbed. As such, extensive experimental activity on 64-bit OSes will be the target of future work.

The Hypervisor: most of the recent projects targeting Windows as guest OS, involve the qemu-kvm [1] or the Xen hypervisors [START_REF]The xen project[END_REF]. Although these ones represent valid tools, we decided to make use of the VirtualBox [START_REF]Oracle Corp. Oracle vm virtualbox programming guide and reference[END_REF] hypervisor. In VirtualBox, apart from being one of the mainstream virtualization technologies, has two main advantages over qemu-kvm and Xen: firstly, it fully supports all Windows versions, including the latest Windows 10; secondly, it includes various VM-debugging functionalities, that allow controlling and manipulating VM components [START_REF]Oracle Corp. Oracle vm virtualbox programming guide and reference[END_REF]. Such funcionalities can be very useful when implementating advanced introspection techniques. For the HyBIS prototype implementation the latest VirtualBox 5.0 version has been used.

The Memory Forensic Tool: among the available FMA tools, Volatility [3] is certainly the most widespread. It has a vast number of functionalities and it can count on a very active community. Nonetheless, it does not fully support all Windows kernel versions. In addition, its performance on memory analysis is quite low for our real-time usage requirement.

A derived project, named Rekall [START_REF]Rekall memory forensic framework[END_REF], overcomes these limits, while maintaining main Volatility features and advantages. Its novel kernel profiling system, enables Rekall to automatically upgrade its compatibility with new Windows versions [START_REF]Rekall profiles[END_REF]. Furthermore, thanks to some improved memory-scanning functions, it shows better analysis performances. This renders Rekall both more efficient and effective than Volatility. Moreover, it can be integrated as part of other software as a library. Finally, since Rekall is implemented in the Python language, it can be easily installed into a variety of host OSes (This is also an advantage of VBox over Kvm and Xen). For the HyBIS prototype implementation we made use of Rekall 1.4.

Implementation Details

We will now describe how the proposed architecture was implemented by making use of the previously-mentioned technologies. The HyBIS implementation details are depicted in Figure 1c. As before, on the guest side we have a Windows OS, running in a VM. On the host side, we have the VirtualBox hypervisor, with its internal components: the Execution Manager (EM), the Page Manager (PGM), and the Debug Facility (DBGF). The HyBIS component is implemented as a new VirtualBox component, interacting with the other ones to perform its tasks. In particular, the SMD component leverages PGM for the memory acquisition, and EM for the automatic boot dump generation. The RPB component uses DBGF to manipulate guest memory. The HPF component makes use of the external Rekall component to perform advanced analyses over memory dumps.

The interaction with the HyBIS components is provided through a set of new commands on the VirtualBox integrated Debug Console. These commands will be described later in this section.

Extending VirtualBox The following VirtualBox components have been involved for the HyBIS implementation:

-Virtual Machine Monitor (VMM): this is the core hypervisor; -Execution Manager (EM): it controls the execution of guest code; -Page Manager (PGM): it controls guest memory paging; -Debug Facility (DBGF): it provides a built-in debugger for the VM.

Most of the VM-related components are implemented in the VMM section. Therefore, this is the most suitable place where to insert the new HyBIS component. The EM component is leveraged to monitor the CPU operation mode in order to automatically generate the boot dump. The PGM provides all guest memory management functions and is used to implement the acquisition functionalities. The DBGF provides a lot of useful debugging functions, which are used for implementing the reaction functionality. Furthermore, it provides the console devoted to the interaction with the HyBIS component.

Integrating Rekall Since Rekall is written in Python, an interpreter must be present on the host system. For incorporating Rekall, it has been necessary to import the Python C++ library into the VirtualBox source code. The Rekall functionalities, instead, can be used by means of the provided API library, as mentioned in the previous section. In order to make use of the forensic analysis functions, a suitable session has to be set up. A Rekall session represents a specific combination of a dump file and a selected profile. When starting a session, if a valid profile for the current kernel version is found, every compatible Rekall plugin automatically becomes available to be used for a forensic analysis.

Further Details

HyBIS embodies a set of novel architectural and implementation-related features. In the following, a broad view and some relevant details are given.

Technically speaking, HyBIS is an hypervisor-based IDS which leverages Virtual Machine Introspection (VMI) to monitor a virtualized environment and exploits Forensic Memory Analysis (FMA) to bridge the semantic gap.

With respect to previous solutions, HyBIS uses a novel approach, whose differences are explained in the following.

Use of VMI: typical hypervisor-based IDSs reside on top of the hypervisor, in a Secure Virtual Machine (SVM) (see Figure 2).

Such an approach has the advantage of isolating the security functions so to avoid corruption. However, in such a case, the IDS requires an additional VM, and its capabilities are limited by the functionalities provided through the hypervisor APIs. HyBIS, instead, is integrated into the hypervisor, as shown in Figure 1b. As such, it is able to exploit all the hypervisor capabilities in order to have full control over the target VM.

An alternative VMI approach leverages advanced CPU features to interpose the security functions between the OS and the hardware [START_REF] Zhong | A virtualization based monitoring system for mini-intrusive live forensics[END_REF]. However, this kind of hypervisor does not have the control over all the machine components. Furthermore, this approach usually requires an in-guest agent to be installed into the OS kernel. Conversely, HyBIS does not require any addition to the guest OS kernel and does not rely on any CPU feature.

So, while current VMI-based solutions have limited possibilities to exploit the hypervisor capabilities, the HyBIS novel approach gives the ability to fully exploit them by integrating into the hypervisor. By working from below the VM, it has a full overview of the whole machine state, while still being isolated from the target machine, thus avoiding both OS-level and hardware-level attacks.

Use of Memory Forensics: FMA can be a valuable means for VMI-based systems to bridge the semantic gap. However, it has not yet been fully leveraged by current solutions. This is probably due to the slowness of the memory acquisition process. In fact, FMA tools usually operate on offline dump files, whose creation may take too long for a practical real-time usage. As such, memory acquisition, represents a critical step for the implementation of a real-time FMA-based solution. Furthermore, the soundness of the acquisition process is another serious concern, given that memory is usually dumped by tools installed into the guest OS (see [START_REF] Vömel | Correctness, atomicity, and integrity: Defining criteria for forensically-sound memory acquisition[END_REF]). Such tools have the drawback of altering memory contents and to be vulnerable to OS-level attacks which may corrupt acquired data. Alternatively, memory acquisition can be hardware-based, using techniques, such as DMA, that allow bypassing the OS. Such techniques, however, can still be bypassed by hardware-level rootkits, such as in [START_REF] Rutkowska | Beyond the CPU: Defeating Hardware-based RAM acquisition[END_REF] and [START_REF] Zhang | Now you see me: Hide and seek in physical address space[END_REF], which are able to alter acquired data for hiding their presence.

By leveraging the hypervisor, HyBIS is able to acquire memory using a novel dynamic approach, without being vulnerable to OS-level and hardware-level attacks. The chosen technologies for present HyBIS implementation was not only chosen for their useful features. All of them represent an element of novelty for security research. First of all, the chosen Windows kernel version has been poorly explored in previous work. Most recent Windows-related papers still refer to Windows 7 as the subject of their studies, or as the target for their experiments. Actually, we have not been able to find any kernel-related research on Windows 8 and Windows 8.1. Instead, in our HyBIS implementation and testing, Windows 8.1 was used.

Leveraging the Virtualbox hypervisor represents another relevant contribution of this paper. Most security and virtualization studies involved other common hypervisors, like KVM or Xen. Instead, besides a few performance analyses, we were able to find only a single work involving VirtualBox for its implementation [START_REF] Mulfari | How cloud computing can support on-demand assistive services[END_REF]. In the development of HyBIS, VirtualBox has proved to be a great tool for our purposes. In fact, its features and functionalities have been very helpful for the exploration of VMI techniques.

A similar discussion can be made about the Rekall forensic tool. To the best of our knowledge, Rekall was rarely used as part of a security research project. The only online reference found was in [START_REF]Windows Virtual Address Translation[END_REF], where Rekall was used to analyze Windows profiling. This is probably due to its relatively recent introduction (2007). Most studies and researches involved Volatility instead, from which Rekall was derived. In fact, Volatility has the advantage of being more widespread and supported. However, as previously described, Rekall presents almost the same features but introduce novel features that drastically improves performance and usability. As such, we found it a valuable tool for memory forensic research.

Evaluation

Experiments have been performed, testing the implemented prototype effectiveness, and the functionality of each HyBIS component described in Section 3.1. Some details of the evaluation are given below.

Boot Dump Generation: As previously described, this function should generate a memory dump as soon as the Window kernel has been loaded and begins to run. In order to prove the effectiveness of this function, the generated dump has been analyzed with Rekall. The analysis showed that the only running process found in memory was System, that is the Windows kernel image process. This proves that the dump generation actually occurs at the beginning of the Windows kernel execution. This dump also proved to be acquired in the very first moment the kernel loads. Dumps generated before this point failed to be analyzed by both Rekall and Volatility.

As for what stated above, we can claim that this function generates a dump at the very first suitable time for being analyzed by these kind of FMA tools. Moreover, we believe this functionality, if properly extended, can be helpful in detecting those rootkits that load during the very early stages of the Windows boot.

Dynamic Dumping: This function has been devised to explore new ways of making the dump creation phase faster for monitoring purposes. In order to test it, we identified a restricted memory area to update a previously created dump, while still allowing forensic analysis functionalities. In particular, we selected a range of 250MB, which empirically showed to always contain all kernel process objects. ASLR [START_REF] Gu | Derandomizing kernel address space layout for memory introspection and forensics[END_REF], does not to affect the results of our tests. In fact, the leveraged tools are able to find out the correct position for the kernel structures.

With the purpose of proving the usefulness of this functionality we first created a dump, then started a new process in the guest, and eventually updated the dump by acquiring the above mentioned memory range. Thereafter, we scanned the updated dump with Rekall, to retrieve the active processes list. As expected, the new process was correctly present in the list.

This demontrates that such a reduced memory acquisition speeds up the acquisition process, while not preventing Rekall to properly work, with respect to specific operations. This enables a new form of memory monitoring, which is not limited to single page changes, but involves larger areas. In fact, by leveraging FMA, it is possible to check memory for changes in the OS-level data (e.g. the presence a new process).

Detection and Blocking of Hidden Processes: In order to monitor guest OSes, HyBIS creates a monitoring thread for each VM. This thread periodically dumps the VM memory and analyze it with Rekall. In particular, we created an improved version of the psxview plugin, called pshview, in such a way that it could be automatically filter the suspected hidden processes. Specifically, it tries to distinguish among dead processes, which may remain in memory for a while after their termination, from those which are still present in the system lists, such as the thread list or the session list. In addition, this function avoid scanning the whole memory, as this seldomly proved to discover more processes than those found by reconstructing kernel object lists. The user also has the ability to enable or disable the scan function, as well as increment or decrement the scanning rate.

If after the analysis the pshview plugin returns a suspected hidden process, a pop-up message will be shown to the user, warning about the detected threat, and suggesting to block it through the .psblock function. This removes the hidden process object from the system scheduling list (as well as other system lists), thus preventing its execution. In order to prove the effectiveness of this action, we again dumped memory and fully analyzed it to verify the blocked process was not among the active processes lists anymore.

Testbed Setup: All experiments were conducted on a machine with 12 GB of memory and CPU Intel Core i7 2.4GHz. Each VM had 1 GB of memory (common size on AWS), and Intel VT-x, EPT, and PAE features enabled. As stated above, the target OS was Windows 8.1 32-bit. The OS was infected with different rootkit specimens, chosen among the most widespread and dangerous, such as ZeuS [START_REF] Wyke | What is Zeus? Technical report[END_REF] and ZeroAccess [START_REF] Wyke | Zeroaccess[END_REF].

Conclusion and Future Work

In this work we shed light on some security issues of the Windows OS. Our main contribution is the design of the novel HyBIS architecture, which successfully combines VMI and FMA to build up an anti-rootkit security system for Windows. VMI is used to examine the Windows status by means of hardware monitoring, while FMA is used to carve meaningful information from raw memory data. A rich experimental campaign was performed over most relevant malware specimens, allowing us to detect and block different hidden malicious processes. Given the architectural complexity of the Windows kernel security field, the results reported in this paper -other than being interesting on their own -also pave the way for further research.

Fig. 1 :

 1 Fig. 1: HyBIS Design, Architecture, and Implementation Details

Fig. 2 :

 2 Fig.2:A Typical VMI Architecture[START_REF] Win | Virtual machine introspection[END_REF]

It is worth noticing that malware able to infiltrate the task scheduling could be executed without being on process lists. Current HyBIS does not test for this. This is left as future work.


Jeffrey Avery
email: avery0@purdue.edu

Eugene H Spafford

Ghost Patches: Fake Patches for Fake Vulnerabilities

Offensive and defensive players in the cyber security sphere constantly react to either party's actions. This reactive approach works well for attackers but can be devastating for defenders. This approach also models the software security patching lifecycle. Patches fix security flaws, but when deployed, can be used to develop malicious exploits. To make exploit generation using patches more resource intensive, we propose inserting deception into software security patches. These ghost patches mislead attackers with deception and fix legitimate flaws in code. An adversary using ghost patches to develop exploits will be forced to use additional resources. We implement a proof of concept for ghost patches and evaluate their impact on program analysis and runtime. We find that these patches have a statistically significant impact on dynamic analysis runtime, increasing time to analyze by a factor of up to 14x, but do not have a statistically significant impact on program runtime.

Introduction

Software developers release programs to the public every day, but this code is not perfectly written. As stated by Mosher's Law of Software Engineering: "Don't worry if it doesn't work right. If everything did, you'd be out of a job." [START_REF] Mosher | s Law of Engineering[END_REF]. Thus developers release code that has flaws and subsequently provide the necessary patches to fix the flawed code.

These patches are released with varying frequency, depending on the severity of the flaw as well as developer resources. Software security patches have a higher severity rating than non-security patches because these vulnerabilities could negatively impact other programs and services present on the machine. Thus, when a security flaw is discovered, a patch to fix this flaw usually follows shortly after. This trend is shown by a report released in 2016 where the average time the top five most frequently exploited zero-day vulnerabilities remained undetected once an attack was released was 7 days and the average time to install a patch for these vulnerabilities once the patch was released was 1 day [23].

Despite the speed with which these flaws are detected and updated, patches also inherently have a negative impact on the software: revealing the location of vulnerabilities and the type of security vulnerability being patched. This provides a blueprint for attackers as they develop exploits for vulnerable systems. Exploit generation research shows that attackers can use patches to find vulnerabilities and use these results to develop exploits for unpatched code [START_REF] Brumley | Automatic patch-based exploit generation is possible: Techniques and implications[END_REF][START_REF] Coppens | Protecting your software updates[END_REF].

One solution to make this blueprint more difficult to understand is to obfuscate the traditional patch [START_REF] Mohd A Bashar | Low-threat security patches and tools[END_REF][START_REF] Collberg | Watermarking, tamper-proofing, and obfuscation-tools for software protection[END_REF][START_REF] Wang | The practical defending of malicious reverse engineering[END_REF]. This approach will make the patch more difficult to statically analyze, but dynamic analysis tools exist that can analyze obfuscated code [START_REF] Sharath K Udupa | Deobfuscation: Reverse engineering obfuscated code[END_REF] and the location of the patch is not masked. Therefore, additional techniques must be applied to software patching to enhance its security.

Thus, an additional technique we propose is to apply deception to software security patching to enhance its security. One method we propose to deceive attackers injects a faux patch, composed of one or more fake patches into traditional patches. These misleading updates could influence attackers' ability to identify a legitimate patch, making exploit generation using patches more resource intensive. While not an absolute solution to the problem of patch-based exploit generation, these misleading updates could increase the resources needed to reverse-engineer patches, which is the first step in exploit generation and along with other deceptive and detection techniques could make these attacks more cost intensive. We call the combination of a faux patch and a legitimate patch(es) for a single program a ghost patch.

Definition Ghost patches are composed of two components: a legitimate patch, made of traditional patches, and a faux patch, made of fake patches. The legitimate patch component fixes any vulnerability or vulnerabilities that may exist in the program. These traditional patches are actual fixes for vulnerable code. The faux patch component is additional code meant to mislead attackers. Each fake patch within a faux patch suggests a fake vulnerability.

Ghost patches provide the same level of security as traditional patches, but could confuse attackers analyzing the code. This extra time and effort attackers spend analyzing the code would increase the time between a patch release and an exploit release. This could provide end-users more time to patch their vulnerable systems, causing fewer attacks to succeed.

Related Work

Researchers have applied deceptive techniques to software patches, but we believe our work is the first full treatment that applies, implements and analyzes fake code to software security patches, specifically patches for input validation vulnerabilities. Araujo et. al [START_REF] Araujo | From patches to honey-patches: Lightweight attacker misdirection, deception, and disinformation[END_REF][START_REF] Araujo | Experiences with honey-patching in active cyber security education[END_REF] apply deception to security vulnerabilities such as Heartbleed and Conflicker. Their work focuses on fixing a patch by detecting an attack and diverting the runtime environment to a sanitized virtual environment that appears vulnerable. Researchers though have developed techniques to reliably distinguish sandbox environments from real user machines [START_REF] Yokoyama | Sandprint: Fingerprinting malware sandboxes to provide intelligence for sandbox evasion[END_REF]. Thus, an attacker can identify when they are being monitored and deceived. This technique also does not camouflage legitimate patches, thus, an adversary can easily identify these patches using a diff between a patched and unpatched program. Ghost patches do mask the location of legitimate patches among other plausible code updates, making an adversary's task of identifying the legitimate patch more resource intensive. Fake patches have also been mentioned by Bashar et. al [START_REF] Mohd A Bashar | Low-threat security patches and tools[END_REF] and Jeongwook Oh [START_REF] Oh | Fight against 1-day exploits: Diffing binaries vs anti-diffing binaries[END_REF] as ways to deceive attackers. Our work differs from these by implementing a compiler solution using LLVM [START_REF] Lattner | The LLVM Compiler Infrastructure[END_REF] to add fake patches to code and evaluating their impact on program analysis and runtime. Adding false code to improve code stealth and make reverse engineering of an entire program more difficult has been explored [START_REF] Kanzaki | Code artificiality: a metric for the code stealth based on an n-gram model[END_REF].

Work by Collberg et. al. also discuss bogus control flow statements [START_REF] Collberg | Surreptitious software[END_REF]. Bogus control flow statements are control flow statements that mislead reverse engineering techniques and static analysis tools. This technique focuses on making legitimate paths in a program more difficult to identify to prevent attackers from bypassing sections of code (i.e. registration, validation, DRM, etc.). This work is similar to our approach, as both attempt to add additional statements making code more difficult to understand. Bogus control flow mainly attempts to prevent bypassing critical code segments, while ghost patches attempt to increase the resources necessary to develop patch-based exploits. Our approach differs as dynamic and static analysis tools will be influenced by our approach (i.e. increase analysis runtime) while applying dynamic analysis to bogus control flows will expose the legitimate path in the code. Researchers also have presented the idea of inserting beaconing code traps where return-oriented-programming (ROP) gadgets would be expected by adversaries [START_REF] Crane | Booby trapping software[END_REF]. Our work differs as we implement an automated technique to enhance the security of patches for input validation vulnerabilities. Coppens et. al. suggest code diversification can be introduced using patches to increase the effort necessary for exploit generation [START_REF] Coppens | Protecting your software updates[END_REF]. This approach would force attackers to generate multiple exploits to achieve widespread compromise, increasing the effort and resources needed to exploit a program compared to everyone having the same code with the same vulnerability. This work though does not attempt to mask the legitimate patch, thus an attacker could easily identify and analyze legitimate patches to code that fix legitimate vulnerabilities.

Our contributions from this work are as follows:

-Presentation of a novel methodology to develop and insert fake patches.

-Implementation of a proof-of-concept to inject fake patches in code with input validation vulnerabilities that could result in integer over/under-flows. -Experimentation with dynamic analysis tool to analyze impact of fake patches.

The rest of this work is organized as follows: Section 2 discusses background information, Section 3 introduces our approach to applying deception to put validation patches, Section 4 explains how we evaluate a faux patch, Section 5 presents results from evaluating our proof of concept, Section 6 reviews limitations and challenges of ghost patches as well as discusses potential solutions, and Section 7 concludes this work.

Background

Deception Deception has been used in computing since the 1970s [START_REF] Dewdey | Computer Recreations, A Core War Bestiary of Virus, Worms and other Threats to Computer Memories[END_REF][START_REF] Kevin | The art of deception: Controlling the human element of security[END_REF][START_REF] Spafford | More than passive defense[END_REF][START_REF] Stoll | The cuckoo's egg: tracking a spy through the maze of computer espionage[END_REF]. Since its introduction, a variety of deceptive tools have been developed to bolster computer defenses. Examples of deceptive tools are those that generate decoy documents [START_REF] Malek | Decoy document deployment for effective masquerade attack detection[END_REF] and honeyfiles [START_REF] Yuill | Honeyfiles: deceptive files for intrusion detection[END_REF]. These documents are planted to attract attention away from critical data or resources and alert defenders of potential intrusions or exfiltration attempts.

Our research will use decoy document properties to develop fake patches. The definition of deception in computation states that any intentional act of misleading to influence decision making classifies an act as deception [START_REF] Mohammed | Planning and integrating deception into computer security defenses[END_REF][START_REF] Joseph | Defensive computer-security deception operations: processes, principles and techniques[END_REF]. Thus, ghost patches are intentionally placed in code to mislead attackers. Deception can also be broken into two components, simulation, showing the false, and dissimulation, hiding the real. Simulation and dissimulation are broken down into three separate components. Simulation is comprised of mimicking, inventing, and decoying and dissimulation is comprised of masking, repackaging, and dazzling [START_REF] Whaley | Toward a general theory of deception[END_REF].

Fake patches are an application of showing the false by mimicking and decoying and hiding the real by dazzling. They show the false by including characteristics of real patches, mimicking a real patch and attracting attention away from traditional patches as a decoy. Fake patches hide the real by reducing the certainty of which patches are real and which are decoys.

Exploiting Patches Attackers can use patches to develop exploits. One approach statically reverse-engineers the patched code to determine the vulnerability being fixed. Another approach dynamically analyzes patched code to determine new paths that have been added compared to unpatched code. These new paths suggest that a vulnerability can be exploited in the unpatched program by generating input that follows the new path in the patched program.

Using either approach, attackers can view the actual lines of code being changed among program versions. With our approach, fake patches will be presented along with traditional patches, forcing adversaries using static analysis to distinguish between each type of patch before generating malicious input. The fake patches that we add can be executed by benign input without altering the program's semantics, forcing adversaries using dynamic analysis to distinguish which paths are legitimate and which are deceptive. Research has also shown that exploits can be generated automatically and quickly based on detecting new "checks" in patched code [START_REF] Brumley | Automatic patch-based exploit generation is possible: Techniques and implications[END_REF].

Input Validation Vulnerabilities This work targets input validation vulnerabilities. A common patch to these types of vulnerabilities is to add boundary checks in the form of if-statements [START_REF] Brumley | Automatic patch-based exploit generation is possible: Techniques and implications[END_REF]. Thus, given a patch and unpatched program, a diff between the two programs will show additional branch statements in the patched version. These branch statements can be used to then determine input values that will exploit an unpatched program.

Approach

This research studies how a fake patch can be implemented in conjunction with a traditional patch and measures its impact on program analysis and runtime.

These fake patches should alter the control flow of a program, but not the data flow of information. Thus, given two programs, one with a ghost patch and the other with a traditional patch, the final output should be identical.

Our approach is based on the trend that input validation vulnerabilities are patched by adding conditional statements that validate the value of variables that can be tainted by malicious input [START_REF] Brumley | Automatic patch-based exploit generation is possible: Techniques and implications[END_REF]. Thus, to deceive attackers, we add fake patches to code that mimic these input validation conditional statements, making exploit generation using patches more resource intensive.

Threat Model

We consider attackers who are using patches to develop exploits and have access to both patched and unpatched versions of a program, and can control and monitor the execution of both as our threat model.

Ghost patching is designed for input validation vulnerabilities that have not been discovered by the public or do not have a widely available exploit. If there are scripts that already exploit a well known vulnerability, ghost patches can still be applied but with less effectiveness. Public exploit databases1 or "underground" forums could be monitored to determine if exploits have been developed.

We specifically look at input validation vulnerabilities that involve integers. These vulnerabilities can be exploited because of a lack of boundary checking and can cause subtle program misbehavior through integer overflows or underflows.

Finally, ghost patches target input validation vulnerabilities in enterprise scale systems. Due to performance constraints, embedded or real time systems do not present a suitable enviornment for ghost patches.

Properties of Ghost Patches

This work applies concepts from decoy documents to deceptive patches. Decoy documents are fake documents inserted into a file system or on a personal computer and are meant to intentionally mislead attackers. These documents also mimic real documents and are decoys meant to attract attention away from critical data. Bowen et al. and Stolfo et al. have conducted research on decoy documents [START_REF] Brian M Bowen | Baiting inside attackers using decoy documents[END_REF][START_REF] Malek | Decoy document deployment for effective masquerade attack detection[END_REF] and created a list of properties that decoy documents should embody. We slightly modify these properties and present in Table 1 our list of fake patch properties as well as whether the property is trivial to implement or requires further experimentation.

Implementation Properties

The implementation of fake patches applies deception to patching because it attracts attention away from a traditional patch, but does not impact the data flow of the function being patched. Fake patches should be designed such that they are not marked as dead-code and removed from the binary as a result of Property Explanation Implementation Effort Non-interfering Fake patches should not interfere with program output nor inhibit performance beyond some threshold determined on a case to case basis.

Experimentation

Conspicuous Fake patches should be "easy" to locate by potential attackers.

Easy

Believable Fake patches should be plausible and not immediately detected as deceptive.

Easy Differentiable

Traditional and fake patches should be distinguishable by developers.

Experimentation

Variability Fake patches should incorporate some aspect of randomness when implemented.

Easy

Enticing Fake patches should be attractive to potential attackers such that they are not automatically discarded.

Experimentation

Shelf-life Fake patches should have a period of time before they are discovered.

Experimentation

Table 1: Fake Patch Properties compiler optimization nor should they be trivial to identify by attackers. These patches should also address the properties outlined in Section 3.2. Implementation components of a fake patch should at a minimum include at least one randomly generated value and a conditional statement. Other implementation specifics depend on the actual program being patched.

Control Flow Fake patches having conditional statements that alter control flow will make them apparent to attackers using static and dynamic analysis tools. This addresses the conspicuous property. This also mimics the trend of patches for input validation vulnerabilities. Mimicking this trend could deceive attackers by showing changes that are expected but fake, addressing the enticing property. Experimentation will show how fake patches effect overall program runtime, addressing the non-interfering property. We implement fake patch conditional statements such that they include the destination or left-hand-side of an LLVM intermediate representation store instruction in the original program mathematically compared to a randomly generated value. The use of a random value address the variability property.

We form the body of if-statements by adding code that solves different mathematical expressions with the original program's value as input. These expressions do not alter the value of the legitimate variable; thus, data flow is preserved. The body of fake patch statements should be plausible for the program being patched. This suggests that the body of a fake patch should be developed based on the behavior of the program being patched.

Post Testing

After applying a ghost patch to software, further testing should be conducted for the following:

1. Evaluating ghost patch impact on software runtime and program memory (i.e. lines of code).

Verifying ghost patch does not introduce incompatibilities by applying unit testing.

A ghost patch should be evaluated for its impact on the program's performance to determine if it is feasible. This determination is dependant upon each program and the execution environment of the program. The memory impact of a ghost patch should also be considered. The size of a ghost patch should be reasonable for end-users to download and apply to vulnerable systems. Developers should establish an upper threshold such that the feasibility is measurable and can be validated. Conjectures about patch size and acceptable runtime are outside of the scope of this research. We do analyze the statistical impact of ghost patches on program runtime and program analysis.

LLVM Workflow

The workflow of our LLVM prototype begins with a traditionally patched file(we assume developers have previously created a traditional patch). First, this traditionally patched file is compiled using clang. This creates intermediate representation bytecode of the traditionally patched program. Next, this file is compiled a second time, applying our ghost patch LLVM pass. This pass adds one or more fake patches to the traditionally patched file. The fake patches are also implemented in intermediate representation bytecode. This stage creates a new ghost patched program. Next, this ghost patched program is compiled into binary using the clang compiler. If the file being patched is part of a larger project, the build tool for the project should be mapped to clang to ensure the project gets compiled with the correct flag(s). After the ghost patched code is compiled, the patched and unpatched (this file is before any traditional patch has been applied) binaries are supplied to a binary diff tool, such as bsdiff, to create a patch file that can be distributed and applied to unpatched programs. A work flow diagram of this process is shown in Figure 1.

Implementation

We implemented a proof of concept that addresses input validation vulnerabilities involving integer variables. We believe our approach can be extended to other variable types and data structures without loss of generality. Our implementation uses LLVM and is about 300 lines of C++ code.

Evaluation

The prototype of an LLVM program was developed on an Ubuntu 14.04 x86 64 virtual machine. We used LLVM (version 3.4) to develop our pass because its front end compiler allows optimizations to be developed that can be applied to programs agnostic of the language they are written in. We use KLEE [START_REF] Cadar | Unassisted and automatic generation of high-coverage tests for complex systems programs[END_REF] (version 1.3) to dynamically analyze our vulnerable code because it evaluates paths through a program using symbolic execution, which can efficiently analyze programs without enumerating every possible input value. Thus, results from Klee represent a best case scenario for attacker resource utilization. The VM has 2 cores and 4GB RAM. All experiments were also run on this virtual machine.

Simple Example

We evaluated our approach using the example below, which allows a user to enter two values and then copies each value into an integer variable and lacks input validation code. Then some, operations are performed and the results returned. Experimentation To evaluate our approach, we compare the length of time for Klee [START_REF] Cadar | Unassisted and automatic generation of high-coverage tests for complex systems programs[END_REF], a symbolic execution, dynamic analysis tool, to analyze a legitimately patched and faux patched version of the code. We use the runtime of Klee to measure the impact of a faux patch on exploit generation. We exploit the fact that each new branch will be analyzed because fake patches are indistinguishable from traditional patches from a software perspective.

To show the effect of our approach on program analysis, we evaluate whether the time to dynamically analyze traditionally patched code is significantly different statistically when compared to dynamically analyzing fake patched code using a t test. We also evaluated program runtime using this same experimental structure to determine fake patch's effect on program performance.

Results

Runtime Analysis

Using our simple code example, we collected runtime values using the time command for both the original program and a faux patched program. Figure 2 shows the difference in program runtime between a fake patched program and the unpatched program across 100 executions. Using this data, we determined the statistical significance of this difference in runtime using a t test. We concluded that there was no statistical significance between the runtimes for the original program and the faux patched program.

Program Analysis

We collected values for the runtime of Klee using the time command as it analyzed an unpatched, traditionally patched and faux patched version of our simple code example. Figure 3 represents the runtime for each program across 100 executions. A t test using these values reveled that there is a statistical significance in Klee's runtime between a traditionally patched program and a faux patched program. This suggests that it is more resource intensive to analyze a faux patched program compared to a traditionally patched program, thus analyzing ghost patches would also require more resources.

Discussion

Our proof of concept implementation shows that the application of deception, in the form of fake patches, to software patching is feasible. Our evaluation shows that a faux patch does have an impact on exploit generation, increasing the number of branches in a program, by increasing the resources necessary to analyze a program. These same patches also impact a program's runtime, but this effect is not statistically significant. This suggests that deception can be used to make exploit generation using patches more resource intensive, enhancing Fig. 3: Klee runtime analysis the security of software patches. We believe that with additional research and testing, this approach, either as a standalone technique or in conjunction with other deceptive and detection methods, could impose an exponential increase in program analysis, making exploit generation based on patches an expensive operation, while only adding a minimal increase in program runtime. Our proof of concept implemented and analyzed above supports this claim.

Patch Obfuscation There are limitations associated with ghost patches that could provide attackers an advantage in identifying fake patches or minimizing their impact on program analysis. Attackers could use exploit generation tools that perform analysis in parallel [START_REF] Brumley | Automatic patch-based exploit generation is possible: Techniques and implications[END_REF] to distribute the analysis load across multiple machines and optimize exploit generation. One solution is to develop fake patches that increase the length of each path in a program such that tools are unable to develop an exploit. Another solution is to implement polymorphic patches. Ghost patches can utilize randomization to create polymorphic patches that can be distributed based on different heuristics (i.e. based on region, OS version, or staggered by time). The non-deterministic nature of a polymorphic ghost patch could make exploit development more difficult because the same patch would not be applied to each end system. In this case, the traditional patch would also have to be altered for each patch instance to prevent attackers who utilize multiple instances of a patch to expose the legitimate vulnerability.

Based on our observations, traditional patches for input validation vulnerabilities detect malicious input and return gracefully from the function. This prevents a compromise, but when viewing a binary diff, searching for differences that add return commands could be an identification technique. Applying obfuscation to fake and legitimate patches or to the function being patched could increase the difficulty in distinguishing between each type of patch. Future work will explore obfuscation techniques to make code more difficult to understand [START_REF] Dolan | mov is turing-complete[END_REF] and control flow more difficult to evaluate [START_REF] Moser | Limits of static analysis for malware detection[END_REF].

Active Response Patches Based on the non-interfering property, faux patches should not alter the semantics of the program; the verify step will expose that fake patches do not alter program behavior. Thus, at worst, a brute force approach could expose the vulnerability by analyzing program behavior for each path in a program and identifying which change a program's behavior.

One solution is to use the active response technique for legitimate patches. Active response patches prevent a vulnerability from being exploited but respond to exploits using the same response as an unpatched program. The response could return sanitized data from the actual machine or transfer execution to a honeypot environment [START_REF] Araujo | From patches to honey-patches: Lightweight attacker misdirection, deception, and disinformation[END_REF]. This masking would increase the resources necessary for dynamic analysis tools to identify unpatched systems. Further research will develop techniques that hinder or prevent exploit verification.

Approach Limitation Another limitation is that based on our experiments, ghost patches only have a dynamic analysis impact when there are multiple store operations within a program's intermediate representation (i.e. operations that includes an = sign). Programs that use standard functions (i.e. memmov,memcpy) to assign values semantically perform the same operation, but are represented differently syntactically, and thus a fake patch cannot be applied.

Adding new lines of code also could add unexpected vulnerabilities. The faux patch code is like any other code that could have a vulnerability. Ghost patched code could also be attacked. Providing attackers with additional paths that could be attacked could result in a denial of service type of attack that slows overall program runtime which could impact the machine's performance.

Future work will extend our tool to compile and add fake patches to more complex code. Additional testing will give insight into the effectiveness of ghost patches. We believe because of the simplistic nature of our approach (i.e. adding conditional statements using the store instruction), its' statistically significant increase in program analysis time will not be lost. We also believe that because of the fake patch if-statement body's code, the difference in runtime will not be statistically significant.

Conclusion

This work proposed, implemented and evaluated ghost patching as a technique to mislead attackers using patches to develop exploits against input validation vulnerabilities. We discuss fake patch properties as well as analyze a proof of concept using LLVM. Through experimentation, we found that fake patches add latency to program runtime that is not statistically significant while adding a statistically significant amount of latency to program analysis. If used by program developers as they develop patches for security flaws, we believe faux patches could disrupt the exploit generation process, providing more time for end users to update their systems.

Fig. 1 :

 1 Fig. 1: Complete flow to create a Ghost Patch using LLVM and bsdiff

  int calculate(int alpha, int beta); int main(){ int a,b,c; int d = 9; printf("Enter a value: \n"); scanf("%d", &a); printf("Enter another value: \n"); scanf("%d", &b); c = calculate(a,b); printf("Value of C: %d\n",c); a = b + d; if(a > 27) c = c * d; else b = a -b; d += d; return a; } int calculate (int alpha, int beta){ if(alpha > 88) return (alpha + beta); else return (alpha * beta); }

Fig. 2 :

 2 Fig. 2: Difference in Faux Patched vs. Unpatched program runtime

https://www.exploit-db.com/

Acknowledgements The authors would like to thank the anonymous reviewers for their comments and suggestions and specially thank Breanne N. Wright, Christopher N. Gutierrez, Oyindamola D. Oluwatimi and Scott A. Carr for their time, discussion and ideas. The National Science Foundation supported this research under award number 1548114. All ideas presented and conclusions or recommendations provided in this document are solely those of the authors.