RU98613U1 - HIDDEN RESOURCE DETECTION SYSTEM IN THE SYSTEM - Google Patents

Abstract

 1. A system for detecting rootkits by detecting hidden resources, which contains: the kernel of the operating system is intended to provide a list of resources using the available set of API functions, while the kernel of the operating system is associated with a comparison tool; the kernel capabilities tool is intended to provide a list of resources using the available set of API functions, after authentication is confirmed by the access means; the access means is also associated with a means of providing core capabilities and a means of comparison, wherein the access means is intended to control access to the means of providing core capabilities using authentication; the mentioned comparison tool is intended to compare resource lists from the kernel of the operating system and from the means of providing the capabilities of the kernel and, if a discrepancy is found in these lists, it concludes that a rootkit has been detected. ! 2. The system according to claim 1, in which the access means is intended to authenticate the means of comparison with the aim of further transferring the list of resources to the means of comparison from the means of providing kernel capabilities. ! 3. The system according to claim 1, in which the resource contains at least one of the following computer system resources: files, drivers, processes, registry, dynamic libraries loaded into memory. ! 4. The system according to claim 1, which also further comprises: a device driver is designed to provide access to the hardware capabilities of the device in a computer system, the device driver is also associated with a comparison tool; a means of using driver functionality also with

Description

Technical field

The utility model relates to systems for detecting hidden resources in a computer system, and more particularly, to detecting rootkits by detecting hidden resources in a system.

State of the art

Currently, a wide variety of malicious programs have become widespread, many of which are already running not only for Microsoft Windows operating systems (OS), but also for less popular platforms. It is worth noting that the professionalism of the creators of malicious programs that use ever new ways to exploit vulnerabilities in the OS and applications has also grown. But besides this, they create ways to bypass the methods of operation of antivirus programs, which created a real "arms race" in the modern antivirus industry. Therefore, in addition to the usual detection methods, such as signature verification and the use of a program emulator, the use of, for example, intrusion prevention systems (HIPS) for monitoring programs and whitelists (whitelists, i.e. lists of trusted applications) has come into use.

However, there are also classes of malware that continue to be one of the biggest threats to computer security. We are talking about the so-called "rootkits" (rootkit), i.e. about programs that hide traces of their presence in the system, using, for example, administrator mode (you can read in more detail, including on Wikipedia - http://en.wikipedia.org/wiki/Rootkit). Such programs can be difficult to detect due to the fact that the antivirus application may not be able to determine the presence or use of any hidden resources in the system, for example, files or registry branches. To conceal their presence, rootkits use various intercepts of system functions (i.e., software interceptors), which they modify so that the returned results do not contain hidden resources (for example, hiding registry branches).

It is worth noting that in addition to the traditional concept of rootkits as malware, some of them are legitimately used applications, such as protection against unauthorized copying.

The traditional methods for detecting rootkits are that each of them develops its own detection procedure in order to detect it or remove the intercepts that it uses, which increases the time it is detected and added to the anti-virus database. For this purpose, you can use various programs, such as Sophos Anti-Rootkit (http://www.sophos.com/products/free-tools/sophos-anti-rootkit.html) or AVZ (http: //www.z- oleg.com/secur/avz/). Systems for detecting hidden resources in a system are also described in patents and applications, such as US 20070078915, WO 2007044498, JP 2008004064, US 20050229250. However, all these systems are not able to detect new types of rootkits that use other methods of hiding resources in the system. Thus, it is required to create a system that would allow to determine the presence of a rootkit in the system when finding hidden resources in the system.

An analysis of the prior art and the possibilities that arise when combining them in one system allows you to get a new result, namely a system for detecting rootkits by detecting hidden resources in a computer system.

Utility Model Essence

The technical result of this utility model is to detect rootkits by detecting hidden resources in a computer system.

According to one implementation option, a rootkit detection system by detecting hidden resources is provided, which comprises: an operating system kernel that is intended to provide a list of resources using an existing set of API functions, while the operating system kernel is associated with a comparison tool; means for providing core capabilities, which is designed to provide a list of resources using the available set of API functions, after confirming authentication from the access means; the access means is also associated with a means of providing core capabilities and a means of comparison, wherein the access means is intended to control access to the means of providing core capabilities using authentication; the mentioned comparison tool, which is intended to compare resource lists from the kernel of the operating system and from the means of providing the capabilities of the kernel and when detecting discrepancies in these lists, concludes that a rootkit has been detected.

In a particular embodiment, the access means is intended to authenticate the means of comparison with the aim of further transferring the list of resources to the means of comparison from the means of providing kernel capabilities.

In a particular embodiment, the resource contains at least one of the following computer system resources: files, drivers, processes, registry, dynamic libraries loaded into memory.

In a particular embodiment, it also further comprises: a device driver, which is intended to provide access to the hardware capabilities of the device in a computer system, the device driver is also associated with a comparison tool; means for using the driver’s functionality is also associated with the device in the computer system and means of access, while the means for using the driver’s functionality is intended to provide access to the device’s hardware capabilities after authentication is confirmed from the access means; further, the access means controls access to the means for using the driver functionality using authentication; Additionally, the comparison tool is intended to compare access to the device’s hardware capabilities from the device driver and from the means of using the driver’s functionality and, if they differ, makes a conclusion about the presence of a rootkit.

In one of the private embodiments of the device in a computer system is a hard disk.

In one of the private embodiments, the access means is intended to authenticate the means of comparison in order to further transfer the list of resources to the means of comparison from the means of using the kernel functionality.

Brief Description of the Drawings

Additional objectives, features and advantages of the present utility model will be apparent from reading the following description of the implementation of the utility model with reference to the accompanying drawings, in which:

Figure 1 illustrates the operation of the system of the present utility model.

Figure 2 shows the separation of processes in a computer system.

Figure 3 shows the fact of rootkit detection in determining hidden resources in the system.

Figure 4 depicts the initialization process of the core capabilities engine and the kernel mode driver.

5 illustrates the operation of the present utility model with a device at a low level.

6 shows an embodiment of the present utility model.

Description of Embodiments of a Utility Model

The objects and features of the present utility model, methods for achieving these objects and features will become apparent by reference to exemplary embodiments. However, the present utility model is not limited to the exemplary embodiments disclosed below, it can be embodied in various forms. The essence described in the description is nothing more than the specific details provided to assist the specialist in the field of technology in a comprehensive understanding of the utility model, and the present utility model is determined only in the scope of the attached formula.

The basis of this utility model is the use of a separate kernel of the operating system, which can be implemented as a separate means of providing kernel capabilities. In addition to the means of providing kernel capabilities, there is also a native kernel of the operating system (OS kernel), which works as usual, processing requests from user applications. The kernel capabilities tool includes most of the interprocess communication mechanisms and applications accessing OS system calls and provides correct access to resource types such as files, drivers, processes, the registry, dynamic libraries (DLLs) loaded into memory, and other types of computer system resources.

Figure 1 shows the operation scheme of this utility model, which is used to detect hidden resources by bypassing interceptions that rootkits can use. As can be seen, user applications 130, which operate in user mode, will have to access the kernel of the operating system to gain access to a specific resource of the computer system. However, rootkit 160, which has access to the intercepted API function 140a, can be embedded in the kernel of OS 120, to which such requests usually go. Thus, if the user's application tries to request, for example, a list of files, then rootkit 160 can easily hide the files it needs by returning the modified list of files through the intercepted API function 140a. In the same way, a rootkit can hide the files or registry branches it needs, which allows it to successfully hide its presence in the system.

However, by utilizing the core capabilities engine 110 with unchanged API functions 140, such intercepts can be circumvented. For this, a kernel-mode driver 150 is used, which provides access to the kernel capabilities tool 110. Thanks to this approach, it is possible to bypass interceptions and obtain data, which may also include resources hidden by rootkits. It is worth noting that in the tool 110 for providing kernel capabilities, only the thread that requested information is executing (for example, it may be a request for a list of files). At this point, it is worthwhile to dwell in more detail.

As you know, each process spawns threads in the system. In order to determine those threads that can access the kernel-mode driver 150, a separate mechanism for accessing this driver is required, i.e. The authentication step must be completed. In one embodiment, these threads can be generated by an anti-virus application process that has information about the authentication method of the kernel-mode driver 150. Thus, all threads in the system can be divided into two parts — those that have access to the kernel-mode driver 150 and other. All other threads work as if the operating system contains only one core of OS 120, which serves all their requests. It is the kernel mode driver 150 that determines which thread can be used in the kernel capabilities tool 110. Figuratively speaking, the driver allows you to "forward" these threads to the kernel capabilities tool 110, while all other threads work with the OS kernel 120. Additionally, we note that the OS kernel 120, as well as the kernel capabilities tool 110, can be 32 -bit, and for 64-bit.

Figure 2 shows the separation of processes in a computer system. The anti-virus application process 210 starts the threads of the anti-virus application 220, which can access the kernel mode driver in step 230 after authentication. Then they begin to work with the tool 110 providing core capabilities at step 240. Any other processes 250 run their own threads 260, which work only with the kernel OS 270, which does not lead to a decrease in the speed of the system as a whole.

Figure 3 shows the detection of a rootkit when determining hidden resources in the system as one of the options for implementing this utility model. For example, at step 310, one of the antivirus application threads requests a list of processes. The kernel capabilities tool 110 will return a more complete list to it than the OS kernel 120, since rootkit 160 uses the intercepted API function 140a to modify the returned list of processes (while excluding its own process). Having found a mismatch between the lists, we can conclude that a hidden process was detected at step 320. Then the antivirus application can request a hidden process file at step 330 for its antivirus scan at step 340. If the antivirus scan detects the presence of a rootkit, it will be removed from the system.

Using a similar system, you can bypass interception methods such as splicing of any kind (used to intercept a call to an API function; the essence of the method is to replace the first few bytes of a function with an instruction that transfers control to the intercept code), SSDT (System Service Descriptor Table) and Shadow SSDT intercepts, INT 2E interrupts for the Windows 2000 version (by creating adapters for Zw-functions, that is, those functions that are performed before performing the security check (user rights) action, while functions with the Nt prefix - em) and MSR (special registers of x86 architecture processors, the availability and purpose of which varies from model to processor model), any callbacks and notifications that will not work when functions are called in the kernel capabilities tool 110 (for example , callbacks to registry changes).

FIG. 4 depicts the initialization process of the core capabilities engine 110 and the kernel mode driver. At block 410, the kernel mode driver is initialized, then the path to the file of the kernel capabilities tool 110 is loaded at block 420. In one embodiment, the path is read from the undocumented KeLoaderBlock variable. Such a variable exists only for some time during the initialization of the kernel capability providing means 110, so initialization at step 410 should occur as early as possible. At step 430, the kernel enabler 110 is read from the disk after the file path to the kernel enabler 110 has been downloaded in the previous step. At step 440, the means for providing core capabilities 110 is located in memory: sections are aligned, global variables will point to the OS kernel 120, and the imported functions will be in the required modules. Then, at step 450, it is configured as needed: it creates its own SSDT table, the necessary adapters for functions, removes callbacks and notifications (notify).

Figure 5 illustrates the operation of the present utility model with devices at a low level. It is possible to obtain more detailed information about hidden resources due to the fact that rootkit hooks are located in the kernel image of OS 120 of the system, but they can also be found in the system driver image.

As noted above, the technology of a single kernel (for example, in the form of a tool 110 providing core capabilities, as described above) can be applied not only to the image of the kernel of the system, but also to various system drivers. In particular, system-supplied storage port drivers are used to access the disk. For example, in the Windows operating system there are two types of them:

- SCSI Port Driver (scsiport.sys), Storport Driver (storport.sys)

- ATA Port Driver (ataport.sys / atapi. Sys)

For example, in Fig. 5, rootkit hooks can be located both at the partition management level of the hard drive 520 (for example, partmgr.sys), the disk driver 530 (disk. Sys), and even at the level of the port driver 540 (atapi.sys) . Thus, if it is not known in advance at what level the rootkit intercepts can be, then it becomes impossible to detect it.

Typically, equipment manufacturers create so-called port drivers based on the provided system drivers. The port driver is integrated into the device driver stack and provides additional device functionality. Port drivers themselves provide a universal mechanism for accessing physical media data by unifying the access interface.

Thus, it is possible to initialize the tool 560 to use the functionality of the port driver in the same manner that was used for the tool 110 to provide kernel capabilities to access the extended functionality of the hard disk 510. Using port drivers in this way allows you to bypass hooks of rootkits that prohibit access to certain sectors of the disk or return false content when reading at the lowest level. Authentication of the driver mode port driver 550 occurs in the same way as for the kernel mode driver 150 in figure 2.

6 shows an embodiment of the present utility model. The OS kernel 120 sends the processed query results (for example, to provide a list of resources) to the comparison tool 630, which is also connected to the kernel capabilities tool 110 through the access tool 620. The access means is responsible for authenticating the means 630 for access to the means for providing core capabilities so that the means for providing core capabilities 110 are not accessed by other applications or devices in the system. The kernel capabilities tool 110 itself implements the functions of the OS kernel 120. In one embodiment, the access tool 620 is implemented using the kernel mode driver 150. After receiving the results of requests from the OS kernel 120 and the kernel capabilities tool 110, the comparison tool 630 concludes that rootkits in the system when the results differ.

The device may have 640 device drivers that provide access to 660 devices, such as, for example, a hard drive. Means 650 for using the driver functionality also provides access to devices 660, but only through access means 620 for the same purpose as for means 110 for providing kernel capabilities, i.e. to restrict access. After receiving the results of access requests from device drivers 640 and from means 650 for using driver functionality, comparison tool 630 compares the results. In the event that the results diverge, it is concluded that the rootkit is in the system.

In conclusion, it should be noted that the information given in the description are only examples that do not limit the scope of this utility model defined by the formula. The person skilled in the art will understand that there may be other options for implementing this utility model, consistent with the nature and scope of this utility model.

Claims (6)

1. A system for detecting rootkits by detecting hidden resources, which contains: the kernel of the operating system is intended to provide a list of resources using the available set of API functions, while the kernel of the operating system is associated with a comparison tool; the kernel capabilities tool is intended to provide a list of resources using the available set of API functions, after authentication is confirmed by the access means; the access means is also associated with a means of providing core capabilities and a means of comparison, wherein the access means is intended to control access to the means of providing core capabilities using authentication; the mentioned comparison tool is intended to compare resource lists from the kernel of the operating system and from the means of providing the capabilities of the kernel and, if a discrepancy is found in these lists, it concludes that a rootkit has been detected. 2. The system according to claim 1, in which the access means is intended to authenticate the means of comparison with the aim of further transferring the list of resources to the means of comparison from the means of providing kernel capabilities. 3. The system according to claim 1, in which the resource contains at least one of the following computer system resources: files, drivers, processes, registry, dynamic libraries loaded into memory. 4. The system according to claim 1, which also further comprises: a device driver is designed to provide access to the hardware capabilities of the device in a computer system, the device driver is also associated with a comparison tool; means for using the driver’s functionality is also associated with the device in the computer system and means of access, while the means for using the driver’s functionality is intended to provide access to the device’s hardware capabilities after authentication is confirmed from the access means; further, the access means controls access to the means for using the driver functionality using authentication; Additionally, the comparison tool is intended to compare access to the device’s hardware capabilities from the device driver and from the means of using the driver’s functionality and, if they differ, makes a conclusion about the presence of a rootkit. 5. The system of claim 4, wherein the device in the computer system is a hard disk. 6. The system according to claim 4, in which the access means is intended to authenticate the means of comparison with the aim of further transferring the list of resources to the means of comparison from the means of using kernel functionality.