Anti-rootkit hypervisor: how it works
Recently, our company has been developing a rootkit detector based on hardware virtualization. The project was conceived in order to figure out how to use the new features of Intel and AMD processors for information security. After several iterations, we stopped at a fully functional method of detecting rootkits. About him and will be discussed.
The method is based on the technology of hardware memory virtualization (nested paging or hardware assisted paging, there is no generally accepted Russian-language term). This technology has appeared in the latest models of Intel and AMD processors. The Intel version is called Intel Extended Page Table (EPT) and is supported by processors starting with the Nehalem family (Intel Core i3, i5, i7). AMD is called AMD Rapid Virtualization Indexing (RVI) and has been present on processors since the AMD K10 generation. The technologies are similar, so everything that is described further on Intel EPT is applicable to AMD RVI.
So, we have a hypervisor and a guest operating system (guest) under its control.
')
The transition control from the hypervisor to the guest OS is called VM Entry, the reverse transition is VM Exit. All work is a sequence of VM Entry and VM Exit, replacing each other. The hypervisor works in an isolated address space and is “invisible” by the guest OS. At the same time, it can change the state of the guest OS (virtual processor, memory, virtual hardware, etc.).
It makes sense for the reader to get acquainted with our previous article , where it was a question of a method based on a shadow paging table of pages. The method described here is its further logical development.
Hardware memory virtualization, as opposed to software virtualization in shadow paging, dramatically simplifies the hypervisor and, as a result, makes it more reliable. In addition, performance is greatly increased and memory consumption is reduced.
Under normal processor operation, any access to a physical address immediately leads to its setting on the processor’s address bus (except in such cases as access to APIC, but we omit them for simplicity). In the case of nested paging, any guest addressing to a physical address (it is called “guest physical address”) is first transmitted through a special page table. The physical address obtained from the guest physical address is set on the address bus, after which the memory is accessed.
The transformation of guest physical addresses for Intel EPT is similar to the usual page conversion:
The page table is four-level and resembles a page table for converting virtual addresses in Intel 64 64-bit mode. The main difference is the structure of the table entries. The figure shows the entry structure for the lower level of the table (PTE):
We are interested in the three lower bits of records that define access to physical memory. If the R, W, X bits (bits 0 ... 2) are cleared, then access to the described PTE memory, respectively, for reading, writing and execution causes an output to the hypervisor (EPT Violation in Intel terminology).
This makes it possible to control the execution of the code on the processor and writing to the memory with the code.
Full virtualization is not a goal in our case. To control the execution and modification of the code, we just need to virtualize the memory and the processor.
To virtualize the memory, we need to build an EPT page table with the mapping of guest physical addresses to real physical addresses “identity mapping”. At the same time, in the records at the lower level of the table (PTE), we reset the W and X bits. Each such record describes access to a 4 KB memory page.
Further, there are two possible exits to the hypervisor (VM Exit) with EPT Violation:
Thus, a memory page can be either only executable or only recordable. Recording and execution, respectively, entails going out to the hypervisor (VM Exit) and translating the page from one state to another.
By processing these events, the hypervisor can intercept writing to non-paged code, as well as executing outside the limits of system modules. When each of the events occurs, you can analyze the code that caused it.
We implemented the Hypersight Rootkit Detector rootkit detector using the method described above. It is designed so that it can be loaded and unloaded at the user's request. This allows it to be used in conjunction with virtualization programs such as VMware and VirtualBox.
Our rootkit detector can detect the following core activity:
The drop in performance when monitoring is on is within one percent and almost imperceptibly "by eye". Memory consumption by the hypervisor is about 40 MB for a quad-core processor. This makes it possible to use the method on computers with memory from 1 GB intended for office tasks and development.
The capabilities of the hypervisor are not limited to the detection of rootkits. It is also possible to block malicious activity. We are conducting research in this area and we hope to present the results in the near future. Also on the agenda is porting to the 64-bit architecture and AMD RVI processors.
Recently, antivirus companies have paid attention to hypervisors and began to hire their developers. However, it is worth noting that the development of a hypervisor from scratch is quite a laborious and expensive process, despite its apparent external simplicity. Our company can offer its experience in this area, as well as a working solution.
Intel Processor Documentation: www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
AMD processor documentation: developer.amd.com/documentation/guides/Pages/default.aspx
The method is based on the technology of hardware memory virtualization (nested paging or hardware assisted paging, there is no generally accepted Russian-language term). This technology has appeared in the latest models of Intel and AMD processors. The Intel version is called Intel Extended Page Table (EPT) and is supported by processors starting with the Nehalem family (Intel Core i3, i5, i7). AMD is called AMD Rapid Virtualization Indexing (RVI) and has been present on processors since the AMD K10 generation. The technologies are similar, so everything that is described further on Intel EPT is applicable to AMD RVI.
Theory
So, we have a hypervisor and a guest operating system (guest) under its control.
')
The transition control from the hypervisor to the guest OS is called VM Entry, the reverse transition is VM Exit. All work is a sequence of VM Entry and VM Exit, replacing each other. The hypervisor works in an isolated address space and is “invisible” by the guest OS. At the same time, it can change the state of the guest OS (virtual processor, memory, virtual hardware, etc.).
It makes sense for the reader to get acquainted with our previous article , where it was a question of a method based on a shadow paging table of pages. The method described here is its further logical development.
Hardware memory virtualization, as opposed to software virtualization in shadow paging, dramatically simplifies the hypervisor and, as a result, makes it more reliable. In addition, performance is greatly increased and memory consumption is reduced.
Under normal processor operation, any access to a physical address immediately leads to its setting on the processor’s address bus (except in such cases as access to APIC, but we omit them for simplicity). In the case of nested paging, any guest addressing to a physical address (it is called “guest physical address”) is first transmitted through a special page table. The physical address obtained from the guest physical address is set on the address bus, after which the memory is accessed.
The transformation of guest physical addresses for Intel EPT is similar to the usual page conversion:
The page table is four-level and resembles a page table for converting virtual addresses in Intel 64 64-bit mode. The main difference is the structure of the table entries. The figure shows the entry structure for the lower level of the table (PTE):
We are interested in the three lower bits of records that define access to physical memory. If the R, W, X bits (bits 0 ... 2) are cleared, then access to the described PTE memory, respectively, for reading, writing and execution causes an output to the hypervisor (EPT Violation in Intel terminology).
This makes it possible to control the execution of the code on the processor and writing to the memory with the code.
The essence of the method
Full virtualization is not a goal in our case. To control the execution and modification of the code, we just need to virtualize the memory and the processor.
To virtualize the memory, we need to build an EPT page table with the mapping of guest physical addresses to real physical addresses “identity mapping”. At the same time, in the records at the lower level of the table (PTE), we reset the W and X bits. Each such record describes access to a 4 KB memory page.
Further, there are two possible exits to the hypervisor (VM Exit) with EPT Violation:
- Access to the memory page to write. When this occurs, the hypervisor exits, after which it enables writing to the page (sets the W bit), but prohibits execution (clears the X bit).
- Access to the memory page for execution. In this case, the hypervisor permits execution on the page (sets X), but prohibits writing to it (resets W).
Thus, a memory page can be either only executable or only recordable. Recording and execution, respectively, entails going out to the hypervisor (VM Exit) and translating the page from one state to another.
By processing these events, the hypervisor can intercept writing to non-paged code, as well as executing outside the limits of system modules. When each of the events occurs, you can analyze the code that caused it.
Practical implementation
We implemented the Hypersight Rootkit Detector rootkit detector using the method described above. It is designed so that it can be loaded and unloaded at the user's request. This allows it to be used in conjunction with virtualization programs such as VMware and VirtualBox.
Our rootkit detector can detect the following core activity:
- Attempts to switch to hypervisor mode.
- Modification of control registers with non-kernel code and HAL.
- Modifications of non-paged kernel code, HAL and drivers in memory, modifications of SSDT. Including modification by displaying virtual memory.
- Executing code outside of the executable sections of the driver, kernel, and HAL. The so-called “hidden code”, the trump card of rootkits, is now easily detected.
The drop in performance when monitoring is on is within one percent and almost imperceptibly "by eye". Memory consumption by the hypervisor is about 40 MB for a quad-core processor. This makes it possible to use the method on computers with memory from 1 GB intended for office tasks and development.
Further work
The capabilities of the hypervisor are not limited to the detection of rootkits. It is also possible to block malicious activity. We are conducting research in this area and we hope to present the results in the near future. Also on the agenda is porting to the 64-bit architecture and AMD RVI processors.
Conclusion
Recently, antivirus companies have paid attention to hypervisors and began to hire their developers. However, it is worth noting that the development of a hypervisor from scratch is quite a laborious and expensive process, despite its apparent external simplicity. Our company can offer its experience in this area, as well as a working solution.
Literature
Intel Processor Documentation: www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
AMD processor documentation: developer.amd.com/documentation/guides/Pages/default.aspx
Source: https://habr.com/ru/post/133906/
All Articles