VM escape: 101

In this article I will try to talk about the obvious (and not so) methods of escape from VMware WorkStation and VirtualBox, and also consider a few interesting special cases.

VMware WorkStation, VirtualBox (Oracle VM VirtualBox) - virtualization software products that allow you to run multiple operating systems on your computer at the same time.
')

Instead of intro

VM escape stirs the minds of many security researchers. Among hackers, these exploits are considered highly advanced and complex. There are such examples, but there are quite a few of them (some of the most interesting are: VMware CloudBurst , Advanced Exploitation of Xen Hypervisor Sysret VM Escape Vulnerability ). But not always in order for your code from a virtual machine to hit the real one (or vice versa) you need to invent something such. So, in the case of an attack on an ordinary user, we can take our ax and hack on the most banal things. Without further ado - let's go.

Infection of shared folders

The easiest and most effective method at all times. There is nothing special to write about this banality, I can only note that the spread of malicious code through shared network resources has already been historically implemented in many worms under NT systems.

Shared Folder Options for VMware Workstation


Shared Folder Settings for VirtualBox

Infection of captured USB devices

Not inferior in efficiency to the previous method considered option. There are also quite implemented ITW-malware (as a historical example - Flame ) with built-in watchdogs that monitor the connection of USB devices that automatically propagate by infecting executable files, forwarding the malicious autorun.inf file, LNK vulnerability, etc.

Naturally, the main condition for this method is the presence of a USB controller device with a specific configuration in the virtual machine.

In VMware Workstation, it seems to me, the settings of the USB controller are implemented incorrectly: the filter is applied to all devices at once, and these dangerous settings are set by default when creating a new virtual machine.

USB controller options for VMware Workstation



VirtualBox, on the contrary, is more flexible, allows us to install a controller filter on certain devices, although at the same time it is possible to install an empty filter to capture any USB, which is bad in terms of security.

USB Controller Settings for VirtualBox

Attack on shared clipboard

VMware Workstation

Virtual Machine Settings

To begin with, let's take a general look at the DnD (Drag'n'Drop) architecture and the shared clipboard. Data transfer between the guest and the host is implemented through the GuestRpc mechanism, which is essentially a (0x1E) BackDoor I / O command (for those who do not know or have forgotten what VMware BackDoor I / O is: https://sites.google.com/ site / chitchatvmback / backdoor ).

DnD, a common clipboard model based on a class hierarchy (taken from OpenTools sources):



In turn, GuestRpc also has a table of commands, the whole list of which can be obtained only after a thorough reversing of VMware (by the way, the standard set of guest utilities includes RpcTool, with which you can send GuestRpc commands accordingly). In the case of DnD and the general clipboard, the following commands are used (also referred to as "transport interfaces"):
dnd.transport
copypaste.transport

Each transport interface has its own set of commands that are already transmitted in the service headers of the data packet.

So, for example, the command set for copypaste.transport looks like:

typedef enum { CP_CMD_REQUEST_CLIPBOARD = 2000, CP_CMD_REQUEST_FILES, CP_CMD_RECV_CLIPBOARD, CP_CMD_SEND_CLIPBOARD, CP_CMD_GET_FILES_DONE, CP_CMD_SEND_FILES_DONE, } CopyPasteCmdV4; 

Package CP_CMD_SEND_CLIPBOARD, the clipboard directly highlighted in red
Cross-platform format:



So, possible scenarios for replacing VMware shared clipboard:

• When a user copies any executable file from guest to host;
• When a user copies any executable file on a host with intermediate focus in the guest machine.

Accordingly, this is realized either by writing your clipboard monitor (send requests directly through BackDoor I / O), or by installing a number of hooks plus injecting your malicious code into the guest utility vmtoolsd.exe (under the NT system).

Obviously, instead of an executable file, there can be any office exploit document, etc.

A simple demonstration of this attack (directly injecting into the guest utility is used):

Virtualbox

Unfortunately (for an attacker), VirtualBox does not officially support the transfer of executable files in DnD and the general clipboard.



But I can not fail to mention the third-party project VMTransferFiles , located on the official VirtualBox forum.

With it, you can extend the functionality to transfer any files at your own risk, of course.

Attack on software indirectly related to virtualization

It is no secret that many diverse researchers in the field of information security somehow use virtual machines in their work. For example, malware analysts often analyze the traffic or behavior of malware using the virtues of virtualization.
Hence the roots of this sub-topic: to beat the software they use in this or that work.

Wireshark

It has long been the habit of using blacklists for various research software in various kinds of Malvaris, and Wireshark is actually one of the most popular candidates on this list.

An example of a Rovnix bootkit blacklist:



Therefore, very often I observed a simple and lazy solution to bypass Wireshark detection: simply run it on my host, analyzing virtual machine traffic. In addition, many sandbox systems automatically generate traffic pcp files, which, in turn, are usually analyzed on the host using Wireshark. It would be a good idea to use various remote and local bugs in Wireshark dissectors for VM-escape purposes.

As an example of a vulnerability, I decided to use CVE-2014-2299 - a buffer overflow in the MPEG parser. There is already an exploit source code, a module under MetaSploit .

Video demonstration with combat calculators:

Virtualkd

Before you begin, I draw your attention to an old, but interesting article on how you can attack a host from a virtual machine using the remote kernel debugging protocol with the WinDbg debugger enabled.

VirtualKD is an open-source project designed to improve kernel debugging performance under VMware or VirtualBox. This is implemented by a very custom method (I will consider the implementation with VMware) - on the host side, the dm process is injected into the vmware-vmx process (our virtual machine process), which in turn patches / adds new commands and its handlers to the GuestRpc table. From the guest’s side, a number of Kd * functions (KDCOM.DLL) are intercepted by their implementation in the KDVM.DLL driver.

In fact, a simple scheme is obtained - the KDCOM protocol is tunneled through VMware BackDoor I / O (GuestRpc) to the host and then deployed directly to the pipe channel that WinDbg listens on.

VirtulKD architecture (VMware specific):



And everything would be fine, the utility really works, but I decided, in view of my theme, to go through its sources in search of quick bugs. And indeed, within an hour, a trivial integer overflow was found.

So, in the header file rpcdisp.h, in the KdRpcDispatcher :: SendPacket method, the data of the KDCOM-package wrapped with additional service information is processed.
Some of this data is not validated correctly.



As we see in the figure, the result of the addition of pParams [1] and pParams [2] can be easily overflowed (for example, pParams1 == 0xFFFF0000 and pParams2 == 0x18000 as a result will give us 0x8000). And further on, the pParams [1] code will be used as an offset to the data, which will result in a common read error.

Let me remind you that the processing of this data is in the context of the injected module.dll in the process of the vmware-vmx virtual machine, an exceptional situation in which leads to a drop in the process of the VMware virtual machine.

Naturally, I wrote the sysprogs team about this bug, to which they replied in the style: “Thank you, but we will not patch it, since we don’t see the impact”. In addition, for some reason they thought that the bug was only used in kernel-mode under the guest, although in reality everything is just the opposite and even better - exploitation does not need any privileges at all! In fact, the exploit sends our evil packages directly to BackDoor I / O, the size of the concept is in principle very small, and it can be easily, if desired, implemented in any malware.

I also want to note that this VM DoS bug was found very quickly, and who knows - maybe, in VirtualKd, more significant vulnerabilities have been buried leading already to a real VM-escape. For those who want to get acquainted with the exploit, here is its source code .

And a small demonstration of this attack:

Use of obsolete vulnerable technologies

VMGL

This particular case, although it relates more to KVM and Xen, it seems to me, perfectly characterizes this under the topic.

VMGL is a long-abandoned project on front-end OpenGL 3d hardware acceleration, which, however, still has links - for example, on the official page of the KVM project .

Project site where you can get the source code.

Roughly speaking, VMGL is a client-server technology that tunnels through the TCP / IP protocol stack from a GL virtual command sent directly from a guest virtual machine to a host GPU.

VMGL architecture

After examining the deeper implementation and looking at the source code, I saw that the Chromium project was at the heart of VMGL. So, this very Chromium project also underlies the 3D-acceleration of VirtualBox virtual machines and has already been studied quite successfully for the presence of bugs.

So, with the installation of VMGL you get not just acceleration, but also at least three known vulnerabilities (CVE-2014-0981; CVE-2014-0982; CVE-2014-0983) of the Chromium engine design.

Despite the fact that the vulnerabilities do not give us direct code execution, a theoretical VM escape is still possible, which should definitely excite you if, for some strange reason, you still use this abandoned project.

Fragment of patched Chromium (util \ net.c) in VirtualBox (now vulnerable command handlers simply do not physically exist on the host):

Conclusion

These simple and fairly simple methods of operation bring results and have been encountered in practice in some attacks. So VM escape is not only hardcore exploitation of binary vulnerabilities with circumvention of various security mechanisms, but also well forgotten old ones.