Dangerous 3rd-party drivers on your system or LOLDrivers

Did you know that a completely legitimate driver can give an attacker the opportunity to register in your system for a long time, remaining inside even after reinstalling it? Or turn your computer into a brick? For example, some seemingly harmless trusted (signed) drivers are incidentally tools for overwriting the BIOS. After such an attack, only the programmer will save.

In Windows, there are trusted applications / scripts / libraries with additional interesting dangerous functionality like executing arbitrary code, downloading files, bypassing UAC, etc. If such additional functionality is found in a kernel component, it becomes even more interesting.

Starting with Windows Vista x64, the Driver Signature Enforcement (DSE) policy applies - all kernel-level drivers must be signed. If an attacker (with user / administrator rights) after penetrating the system wants to get the maximum level of access (install kernel rootkit / bootkit / SMM-rootkit / BIOS-rootkit), he will have to somehow bypass the signature requirement for the driver. The ability to call some functions or instructions from kernel mode in kernel mode can give an attacker a tool to elevate privileges, disclose information or cause a denial of service. We call this functionality a dual-purpose functionality (in some cases, this may be called vulnerabilities or backdoors, however, the discussion on the correct definition is beyond the scope of this article).

DSE workarounds

Let's look at what options an attacker generally has to bypass DSE (you must somehow penetrate ring0). The table below summarizes the ways to bypass DSE with their advantages and disadvantages (for the attacker, and security guards take note). It is worth noting that this information applies to Windows x64, starting with Vista.

As you can see from the table, a signed driver with dual-purpose functionality is the most attractive way to bypass DSE for an attacker.

Dangerous or dual purpose functionality

Let's look at examples of malicious capabilities that an attacker appears in the presence of a driver with dangerous dual-purpose functions.

• Privilege escalation to admin level / SYSTEM. Read / write physical memory required. This attack can be accomplished, for example, using the ASMMAP driver from ASUS. To do this, read the physical memory and find the EPROCESS structure (it is an element of a linked list), then go through the list in search of the process whose privilege level we want to increase, as well as some well-known process with the SYSTEM level (for example, lsass, wininit). Then copy the value of the Token field of the system process structure to the structure of the target process. A more detailed description of the attack is given here .
• Disabling SMEP. To do this, you need to write to the control register cr4 (more precisely, reset its 20th bit). For example, the bandainamcoonline.sys driver not only disables SMEP, but also helpfully executes the code according to the pointer passed to it from the user. For those interested, there is an article with a detailed description of the driver.

• Execution of arbitrary code in kernel mode. Read / write physical memory and MSR required. The point is to replace the address (located in one of the MSRs), to which the transition will be made when making a system call, to the address of the location of the attacker code. Here you can find more information about this. PatchGuard will interfere along the way, but you can figure it out if you wish.

  
  
  
  
  
  
  

  Since the driver and PatchGuard both run in Ring 0, nothing prevents the driver from disabling PatchGuard checks (until, of course, until Microsoft listens to Intel and goes beyond the model with two protection rings). The kernel developers at Microsoft are well aware of this fact and perform various actions to hide the location of this code, obfuscate its actions and the internal structures used. In other words, because of the inability to prevent you from modifying the PatchGuard code, they try their best to hide it.
  
  
  
  - Blunden B. The Rootkit arsenal: Escape and evasion in the dark corners of the system.

  
  
  
  Original

  Given that driver code and PatchGuard code both execute in Ring 0, there's nothing to prevent a KMD from disabling PatchGuard checks (unless, of course, Microsoft takes a cue from Intel and moves beyond a two-ring privilege model). The kernel engineers at Microsoft are acutely aware of this fact and perform all sorts of programming acrobatics to obfuscate where the code resides, what it does, and the internal data-structures that it manipulates. In other words, they can't keep you from modifying PatchGuard code, so they're going to try like hell to hide it.
  
  
  
  - Blunden B. The Rootkit arsenal: Escape and evasion in the dark corners of the system.

  
  
  
  
  
  

• BIOS entry. An example in the wild is Lojax . Attackers took the well-known RwDrv.sys and used it for their dirty purposes: they read the BIOS, modified and wrote back. Reinstalling Windows will not help here, since the malicious code sits in the firmware on SPI-flash. If the BIOS overwrite is unsuccessful (or specially overwritten), then it will also be unpleasant. In any case, you will have to drive for the programmer to fix the annoying consequences.
• Call SMI handler. Firstly, not all BIOSs are equally defenseless against code in ring0 mode: there are various mechanisms for reading / writing protection, so there may be a situation where you need to go lower - into SMM mode (the most privileged). One way to get there from kernel mode is to pull the SMI handler (quite often there are vulnerable ones among them). To call the SMI handler, you must be able to write to the I / O port, and this can only be done with ring0 privileges. That is, a driver with the ability to write to I / O ports is able to detect a vulnerable SMI handler that can allow an attacker to execute code in SMM mode. In the example, the author uses the RwDrv.sys driver.
• Information about the system. Reading kernel memory (through reading physical memory), reading BIOS, information about system settings, connected devices and enabled / disabled protection mechanisms (through reading MSR, control registers, access to input / output ports), in some cases, a known hypervisor can be detected ( like VirtualBox via MSR ). For this task, even a driver that can only read, not necessarily write, is most often suitable. For example, RamCaptureDriver64.sys from Belkasoft is suitable for reading physical memory.

If we analyze various articles and notes about CVE, we can distinguish some classification of potentially dangerous functions when accessing from ring3 functions in drivers. The table below lists the hazardous functions and sources of information about them.

And this is not the whole list of possible dangerous functions. You can also talk about reading / writing kernel virtual memory, reading / writing MMIO, access to PCI devices, etc.

The first three functions are of the greatest interest, as well as the greatest danger (and the most likely to detect a driver with such functions): read / write MSR registers, read / write I / O ports, read / write physical memory. Using control registers, you can bypass some protection mechanisms, writing to the flag register allows you to enable read / write input / output ports in ring3 (by the way, it is mentioned in this article on Habré), the success of attacks on third-party channels (by accessing the cache, monitoring counters performance / cycles) is most likely unlikely.

In the process of creating this material at the DEFCON 27 conference in Las Vegas, researchers Jesse Michael and Mickey Shkatov presented the work “Get off the kernel if you cant drive” , which also discusses this problem, and we recommend that you study this material to complete the picture. The scenarios for using such drivers are very simple and clear, and examples of code sections responsible for the most critical functionality are presented. And also provides code for working and finding similar drivers.

In general, it is worth noting that this topic has long been concerned about security researchers. Back in 2018, researcher Alexander Matrosov in his article "What makes OS drivers dangerous for BIOS?" raised this question and demonstrated how simple it is to exploit BIOS.

Dual-Function Drivers

Below are the most famous representatives of drivers with dual-purpose functions.

• RwDrv.sys is a very popular driver (comes with the RWeverything utility). Reads and writes physical memory, I / O ports, MSR and control registers. It was repeatedly used in different PoCs, and then in the previously mentioned Lojax rootkit. An interface is written for it in C ++, and it is also used in chipsec .

  
  
  
  
  
  
  

• cpuz / gpuz

  
  
  
  
  
  
  
  
  
  

  Reads and writes physical memory, ports, and MSR. There are several PoC utilities using it ( here and here ).

  
  
  
  
  
  
  

• pcdsrvc_x64 - driver from Dell, for more information contact this post. Allows you to read / write physical memory in I / O ports.

  
  
  
  
  
  
  

• AsIO64.sys
  
  
  
  It provides the ability to read / write physical memory and I / O ports, and also comes with a convenient dll for performing these requests.

  
  
  
  
  
  
  

• Asmmap64.sys is another driver from ASUS that allows you to read / write physical memory, I / O ports and MSR. It would be especially pleasant for an attacker, since access to the driver can be made from a regular user without administrator rights. Curious people can turn to the source .

  
  
  
  
  
  
  

• ntiolib_x64.sys / winio64.sys - drivers from MSI, they are described in detail in the previously mentioned article . Using ntiolib_x64.sys you can read / write physical memory, I / O ports and MSR, winio64.sys provides all these functions except MSR.

  
  
  
  
  
  
  

Usually, the described dangerous functions are recognized as vulnerabilities if the driver is accessible to the user without administrator rights (incorrect ACL) or when it allows executing arbitrary code directly (as in bandainamcoonline.sys). In other cases, this is just functionality, and since the user has administrator rights, he can use all the driver functions and this is the norm.

If you think that there are no more than a dozen such drivers, then you are greatly mistaken. You can see this selection of interesting drivers. This list contains drivers from ASUS, AVAST, Razer, LG, American Megatrends and other well-known companies. So there are a lot of them, you just need to search. So, they pose a real threat.

This threat is also understood by Microsoft employees. And they will be grateful for information about such drivers;)

Recommendations

For users:

• You should not sit unnecessarily under the administrator account and disable UAC (although it is not difficult to get around it).
• You can install the detector trying to install drivers (for example, here ).
• If it is necessary to use utilities with such drivers (diagnostic, for updating the BIOS, etc.), remove the drivers after use.
• Set up Device Guard (if you are a happy owner of Windows 10). Using this technology, you can create your own code integrity policy and add white lists of programs and certificates. For example, add to the policy the requirement that any kernel-mode driver must have a Microsoft WHQL signature. In this post, you can better familiarize yourself with setting Device Guard for this purpose.

Manufacturers are better off not signing such drivers. If the user needs to update the BIOS, check the system for vulnerabilities (hi, chipsec), measure the performance or perform some other manipulations that require the installation of such drivers, then he may well go into Test Mode, do all this, and then exit. Usability will then fall, but security will increase.

findings

If something is signed, then you can’t trust this anyway. Firstly, you can sign something like that, and secondly, an attacker can take advantage of this signed one (even if it is from a trusted manufacturer).

Information security specialists should not exclude from the threat model situations where an attacker requires a driver with dangerous functionality to perform an attack. There are enough drivers like that, it's quite simple to do. If the attack is not carried out with such a pop driver as RwEverything, but with some less widely known one, then it will be even more difficult to detect. So you need to be on the alert, monitor such things and not allow each driver to boot into the system.

Author: Elizaveta Khomenko