RU2585978C2 - Method of invoking system functions in conditions of use of agents for protecting operating system kernel - Google Patents

Abstract

FIELD: information security.

SUBSTANCE: invention relates to antivirus technologies, and more specifically to a method of creating handler system calls. According to one version, method of system function call, during which following steps are performed: loading hypervisor for interception of handler system calls. Modifying structure of operating system kernel, connected to system function call, said structure operating system kernel includes at least: a) a system call; b) system call table in which address of call is replaced with at least one system function call address on other function with maintaining original address system function call; intercepting system call handler call by hypervisor; calling another function at any replacement address in system call; calling system function on stored original address.

EFFECT: technical result consists in a system function call in conditions of use of operating system kernel protection means.

1 cl, 7 dwg

Description

Technical field

The invention relates to antivirus technologies, and more particularly to a method for invoking system functions under the conditions of using kernel protection means of the operating system.

State of the art

Currently, modern anti-virus products use interception of system calls in order to detect malware, for example, already at the stage of their execution. For example, using such interceptions, the System Watcher technology was built (http: //support.kaspersky.eom/us/8057#block1). Intercepting system calls that lead to suspicious actions (for example, writing an executable file to the Windows folder), you can block even unknown malware, which is one of the key advantages of modern antiviruses.

However, the ability to intercept system service calls in 64-bit versions of the Windows operating system (OS) is limited by the Microsoft-implemented Patch Guard security system (http://msdn.microsoft.com/en-us/library/windows/hardware/dn613955 (v = vs.85) .aspx), which prevents the use of classical interception methods. Patch Guard tracks changes in a number of important objects of the OS kernel (as malicious changes resulting from the operation of rootkits or due to modifications by third-party software such as antiviruses), for example, a system call table or an interrupt vector table (Eng Interrupt Descriptor Table, IDT) , and upon detection of changes in them causes a system crash.

Currently, technologies are described that circumvent protection similar to PatchGuard. For example, US7996836 describes an approach for using a hypervisor to bypass Patchguard. When using a hypervisor, it becomes possible to create interceptors of the mentioned kernel objects without crashing the system.

Thus, bypassing PatchGuard protection is possible using hardware virtualization. However, the creation of interceptors for kernel objects (for example, to control SSDT) requires knowledge of their internal structure, which varies depending on the version of Windows, which requires the release of an adapted version of the interceptor to support the next version of the OS.

An analysis of the prior art allows us to conclude about the inefficiency and, in some cases, the impossibility of applying the previous technologies, the disadvantages of which are solved by the present invention, namely, by calling system functions in the conditions of using the operating system kernel protection means.

Disclosure of invention

The technical result of the present invention is to provide a call to system functions in terms of using means of protection of the kernel of the operating system.

According to one implementation option, a method for calling system functions is proposed, during which the following steps are performed: loading a hypervisor to intercept a system call handler; modify the structure of the kernel of the operating system associated with calls to system functions, while these structures of the kernel of the operating system include at least: a) a processor of system calls; b) a system call table, in which the call address of at least one system function is replaced by the call address of another function, while maintaining the original call address of the system function; intercept a call to the system call handler using a hypervisor; call another function at the replaced address in the system call table; call the system function at the stored original address.

Brief Description of the Drawings

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

FIG. 1a provides an example of a modification to a system call.

FIG. 2 illustrates an example of loading a handler.

FIG. 3 provides a way to use the hypervisor to bypass the Patch Guard.

FIG. 4 illustrates a method for handling system calls.

FIG. 5 illustrates an example implementation of a computer system on which the present invention may be implemented.

FIG. 6 shows an example of executing an API function in a Windows operating system.

FIG. 7 provides an example of a system service call.

Description of Embodiments

The objects and features of the present invention, methods for achieving these objects and features will become apparent by reference to exemplary embodiments. However, the present invention 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 necessary to assist the specialist in the field of technology in a comprehensive understanding of the invention, and the present invention is defined in the scope of the attached claims.

For a better understanding of the present invention, first of all, a description will be given of the operation of the mechanisms for invoking system functions in Windows.

FIG. 6 shows an example of executing an API function in a Windows operating system. WriteFile was chosen as an example of an API function. At step 610, the Windows application (for example, Microsoft Word or Notepad) attempts to write data to the file by calling the corresponding Win32 API function WriteFile in Kernel32.dll. Then, at step 620, the NtWriteFile is called in Ntdll.dll (i.e., all related system functions are called sequentially), which in turn leads to a system interrupt at step 630 and the search for the corresponding handler (which is done by the KiSystemService function in Ntoskrnl.exe ) when calling NtWriteFile. Note that this process occurs in user mode, and after the interrupt is called, it switches to kernel mode. At 640, NtWriteFile is called directly in Ntoskrnl.exe and directly writes to the file at 650 (details related to the operation of the file system driver are also hidden here).

Let us examine in more detail step 630 associated with calling the SYSCALL instruction. Currently, in modern x86 architecture processors, to switch from user mode (English user mode) to kernel mode (English kernel mode), you need to call the SYSCALL / SYSENTER instruction (hereinafter we will use only SYSCALL). On the x64 architecture, the address of this processor is stored in the LSTAR (Long System Target-Address Register) register, which refers to the MSR (Machine Specific Registers) registers.

7 is an example of a system service call. When switching to kernel mode, the 710 System Services Manager (on Windows, it is KiSystemService) copies the system call arguments from the user-mode thread stack to its kernel-mode stack (so that the user cannot change the arguments when the kernel accesses them), and then executes the 720 system service from the system services table 730 (on Windows, this is the System Service Dispatch Table, SSDT).

Thus, within the framework of working protection methods such as Patch Guard, to modify the system service 720, it will be necessary to modify table 730 itself, which will lead to the system crash. In order to circumvent this limitation, you need to create your own copy of table 730, but in addition, use your own SYSCALL call handler (hereinafter we will use the abbreviation handler for simplification) in order to use your own system services table (we will consider this an operating system structure, associated with calls to system functions). Further in FIG. 2 and 3, an example of creating and using a SYSCALL call handler will be considered.

In FIG. Figure 1a shows an example of modifying a system call (for example, a handler for a specific file operation). In the address space of the kernel 100 at a specific address the original handler 110 is loaded, which must be modified to suit your needs. Modification of the code can be based on the use of a number of such techniques as address spoofing (for example, by modifying SSDT / IDT tables), directly changing the handler (for example, using splicing), or modifying the body of the system function itself. By changing the address of the processor 110 to the address of another processor 120, it is possible to implement the necessary functionality, for example, by turning on anti-virus scanning of a number of file or registry operations. However, note that, since Patch Guard checks the values of the MSR register, it is impossible to change the value of this register (more about this register below) using the techniques described above.

You can use virtualization to bypass the Patch Guard using a hypervisor. In FIG. Figure 3 shows an example of using a hypervisor to bypass Patch Guard. Hypervisor 300 has a higher privilege to execute (level 1, while the kernel has 0, and user application level 3), it can be loaded at any time, both at the OS startup and during its operation. Upon initialization of the hypervisor 300, a list of instructions is set that can be intercepted using it. To intercept the SYSCALL instruction, just specify the interception of the RDMSR (read MSR) and WRMSR (write to MSR) instructions.

Thus, using the hypervisor 300, it is possible to control the MSR register (in particular, LSTAR, we will use only MSR for summarization), writing down the necessary value 320a and preserving the original value 3206. This makes it possible to substitute the original value 3206 for reading by such protection tools as Patch Guard (and without causing a system crash), but at the same time use the necessary address 320a to use the modified handler.

An example of handler loading is shown in FIG. 2. At step 210, the address in the code memory of the original handler 110 is determined — the size and position in the memory of the downloaded image are determined. Then, at step 220, a copy of the handler 110 is created in the form of an image 120. The size of the memory for the copy should be allocated taking into account possible changes. The preferred option is to allocate memory in the memory of the already loaded driver 130, which will facilitate the modification of the processor code. Such changes are the modification of relative links at step 230, the replacement in the handler code 120 of the addresses of service tables (for example, SSDT) at step 240, and the initialization of the exception table at step 250. The latter is necessary in order to correctly handle exceptions associated with the execution of the handler code 120. All of the above changes can be made using the disassembler, which is necessary for parsing the processor 110 instructions and their subsequent modification (steps 230 - 250). These changes are necessary in order to correctly replace the handler 110. Other changes may relate to various areas of computer security related to the analysis of intercepted calls.

After the handler 120 has been initialized, it can be used to intercept system calls. As calls of interest, you can consider file and registry operations, operations related to taking screenshots. It can be noted that in the latest versions of Windows, you can use the interception of file and registry operations using the OS API itself.

Within the Windows operating system, in order to combat a certain class of malicious programs that take screenshots (screenshots, English screenshots) in order to highlight important user information (for example, passwords), it is necessary to provide control over intercepts of functions related to taking screenshots. There are a number of techniques that allow you to get the window descriptor (descriptor) of the desired application and copy the raster (English bitmap) from it or use Direct3D surfaces (Direct3D surface) to convert them into a raster directly in memory and then save them to disk for analysis. In order to be able to track down malicious applications that use similar techniques, it is necessary not only to provide SYSCALL call interception, but also to modify the SSDT table to intercept the necessary calls.

It should be noted that the hypervisor 300 does not have to always be loaded and kept in memory while the OS is running. Hypervisor 300 can also be loaded while the OS is running when one of the following conditions is true:

- Downloading a critical application (for example, a banking application), for which it is necessary to provide protection against taking screenshots.

- The user went to the website of the bank or payment system (for example, PayPal), which also requires protection from taking screenshots.

- The anti-virus application requires self-protection (i.e. protection against attempts to terminate the anti-virus application process or stop the anti-virus driver), which leads to the need to track the corresponding system calls.

- More flexible management of the application control system (English application control) by replacing system calls, implementation of an isolated environment (English sandbox).

- Implementation of deep verification of a suspicious application as part of emulating its behavior. In this case, not real kernel service function handlers are called, but special functions of the OS behavior emulator are called. At the same time, no changes are made in this OS, however, the application considers that it is running on a real system. Based on the emulator protocols, the degree of danger of the application is determined. This check can be carried out both on the user's machine and on a dedicated cloud service.

When one of these conditions is met, at step 410 of FIG. 4 (which illustrates how to handle system calls) a hypervisor will be loaded. The SSDT table will be modified in step 420. The SYSCALL function handler will be loaded in step 430 (the download is illustrated in FIG. 2). At step 440, the call is intercepted, using the modified SSDT table, the call context (for example, which process made the call) is transmitted at step 450 for antivirus analysis (i.e., another function was called), within which, for example, it can be determined Is the process that made the call malicious? Since, after calling another function (for example, for anti-virus scanning) at the replaced address in the system call table, it is necessary to ensure the correct execution of the system call code, then the system function is called at the stored original address.

It is also worth noting that in some cases, it may be necessary to synchronize the original and modified SSDT tables. The original SSDT table can be updated as part of the hot patching procedure.

In addition, the proposed interception scheme using a hypervisor can be implemented in such a way as not to reduce the level of OS protection provided by PatchGuard technology, since all loadable modules on x64 systems undergo signature verification and protection of a copy of an interceptor and a copy of service can be implemented using a hypervisor tables against modification, providing an even more robust equivalent of PatchGuard protection.

FIG. 5 is an example of a general purpose computer system, a personal computer or server 20 comprising a central processor 21, a system memory 22, and a system bus 23 that contains various system components, including memory associated with the central processor 21. The system bus 23 is implemented as any prior art bus structure comprising, in turn, a bus memory or a bus memory controller, a peripheral bus and a local bus that is capable of interacting with any other bus architecture. The system memory contains read-only memory (ROM) 24, random access memory (RAM) 25. The main input / output system (BIOS) 26 contains the basic procedures that ensure the transfer of information between the elements of the personal computer 20, for example, at the time of loading the operating system using ROM 24.

The personal computer 20 in turn contains a hard disk 27 for reading and writing data, a magnetic disk drive 28 for reading and writing to removable magnetic disks 29, and an optical drive 30 for reading and writing to removable optical disks 31, such as a CD-ROM, DVD -ROM and other optical information carriers. The hard disk 27, the magnetic disk drive 28, the optical drive 30 are connected to the system bus 23 through the interface of the hard disk 32, the interface of the magnetic disks 33 and the interface of the optical drive 34, respectively. Drives and associated computer storage media are non-volatile means of storing computer instructions, data structures, software modules and other data of a personal computer 20.

The present description discloses an implementation of a system that uses a hard disk 27, a removable magnetic disk 29, and a removable optical disk 31, but it should be understood that other types of computer storage media 56 that can store data in a form readable by a computer (solid state drives, flash memory cards, digital disks, random access memory (RAM), etc.) that are connected to the system bus 23 through the controller 55.

Computer 20 has a file system 36 where the recorded operating system 35 is stored, as well as additional software applications 37, other program modules 38, and program data 39. The user is able to enter commands and information into personal computer 20 via input devices (keyboard 40, keypad “ the mouse "42). Other input devices (not displayed) can be used: microphone, joystick, game console, scanner, etc. Such input devices are, as usual, connected to the computer system 20 via a serial port 46, which in turn is connected to the system bus, but can be connected in another way, for example, using a parallel port, a game port, or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface such as a video adapter 48. In addition to the monitor 47, the personal computer can be equipped with other peripheral output devices (not displayed), for example, speakers, a printer, etc. .

The personal computer 20 is capable of operating in a networked environment, using a network connection with another or more remote computers 49. The remote computer (or computers) 49 is the same personal computer or server that has most or all of the elements mentioned earlier in the description of the creature the personal computer 20 of FIG. 5. Other devices, such as routers, network stations, peer-to-peer devices, or other network nodes may also be present on the computer network.

Network connections can form a local area network (LAN) 50 and a wide area network (WAN). Such networks are used in corporate computer networks, internal networks of companies and, as a rule, have access to the Internet. In LAN or WAN networks, the personal computer 20 is connected to the local area network 50 via a network adapter or network interface 51. When using the networks, the personal computer 20 may use a modem 54 or other means of providing communication with a global computer network such as the Internet. The modem 54, which is an internal or external device, is connected to the system bus 23 via the serial port 46. It should be clarified that the network connections are only exemplary and are not required to display the exact network configuration, i.e. in reality, there are other ways to establish a technical connection between one computer and another.

In conclusion, it should be noted that the information provided in the description are examples that do not limit the scope of the present invention defined by the claims.

Claims (1)

1. A method of calling system functions during which the following steps are performed:
• load the hypervisor to intercept the system call handler (SYSCALL function) in order to bypass the Patch Guard, while the hypervisor is loaded while the operating system is running when at least one of the following conditions is met:
- downloading a banking application, for which it is necessary to provide protection against taking screenshots;
- the requirement to protect the anti-virus application from attempts to terminate the anti-virus application process or stop the anti-virus driver;
- verification of a suspicious application as part of emulating its behavior;
• modify the kernel structure of the operating system associated with calls to system functions, while the specified kernel structure of the operating system includes:
a) system call handler;
b) a table of system calls, in which the address of the call to the system function is replaced by the address of the call of another function, while maintaining the original address of the call to the system function;
• intercept the call of the system call handler using the hypervisor, using the interception of the RDMSR and WRMSR instructions;
• call the function for anti-virus scanning at the replaced address in the system call table;
• call the system function at the stored original address.

Images