CN102521537B - Detection method and device for hidden process based on virtual machine monitor - Google Patents

Abstract

The present invention provides a method and device for detecting a hidden process based on a virtual machine monitor. The method includes: respectively obtaining process information in a user state, a kernel state, and a virtual machine monitor; comparing the process information in the user state with the process information in the virtual machine monitor. The process information in the kernel state is obtained to obtain the hidden process in the user state; the process information in the kernel state is compared with the process information in the virtual machine monitor to obtain the hidden process in the kernel state. The device includes: an obtaining module, a first comparing module and a second comparing module. The solution provided by the invention realizes the hidden process detection and identification technology of various views, and provides better security guarantee for the virtual machine.

Description

Method and device for detecting hidden processes based on virtual machine monitor

technical field

The present invention relates to virtual machine technology, in particular to a hidden process detection method and device based on a virtual machine monitor (Virtual Machine Monitor, referred to as: VMM), and belongs to the field of computer technology.

Background technique

The development of virtualization technology has promoted the emergence of virtual machine technology. A virtual machine is realized through virtual hardware, and a physical computer system is virtualized into one or more virtual computer systems, and each virtual computer system has its own virtual hardware (such as CPU, memory, and equipment, etc.). Various advantages of virtual machines have prompted the development of virtual computing environments. Of course, as the core of the computing environment, the security of the virtual machine must be better guaranteed, which has become an important issue to be studied in the current virtual computing environment. In addition, the development of virtual machine technology not only promotes the development of virtual computing environment, but also brings new opportunities for the development of security technology due to its own advantages. The virtual machine monitor is at the bottom layer of the client and the client system, and has a higher privilege level. Therefore, some problems of security can be solved more easily through the virtual machine monitor.

Among the various security problems that may occur in the virtual machine system, hidden objects in the system bring more and more serious security problems. The so-called "hidden" refers to "invisible to users". There is such a kind of malicious software, often called "Rootkit (kernel-level backdoor/Trojan horse)", they run in the system kernel state, can hide their own processes, services, logs and network connections, etc., and can attack normal hidden from the user program. Therefore, how to detect hidden objects in the system has become an important content to maintain the internal security of the system, and it is also an important content to ensure the internal security of the virtual machine in the virtual computing environment.

At present, there are three main methods on how to detect various hidden objects in the system: one is based on the research and implementation inside the system, the other is based on auxiliary hardware, and the other is based on some security mechanisms of the virtual machine controller. The hidden object detection mechanism based on the system level has the danger of tampering, disabling, and bypassing, while the one based on auxiliary hardware requires the support of special hardware, which increases the cost and realizes incomplete functions. VMM-based security technology has been greatly developed, and the security is increasing, but there are also some shortcomings: some are coarse-grained detection; some use the kernel data structure for semantic conversion, in the absence of verification , some information will be missed; some have sacrificed some complete semantic information in order to achieve higher security; more research has been placed on the research process, and there are fewer studies on files and network connections. If there is, only terminate In some cases, the scope of detection is limited due to the fact that hidden processes are ignored and hidden files left behind, or hidden network connections are not paid attention to, these connections are likely to be created by non-hidden processes, and so on. In addition, the research scope of some commercial systems that do not support open source is also limited.

Contents of the invention

A first aspect of the present invention provides a method for detecting hidden processes based on a virtual machine monitor, including:

Obtain process information in user state, kernel state, and virtual machine monitor respectively;

Comparing the process information in the user state with the process information in the kernel state to obtain the hidden process in the user state;

Comparing the process information in the kernel state with the process information in the virtual machine monitor to obtain hidden processes in the kernel state.

A second aspect of the present invention provides a method for detecting hidden processes based on a virtual machine monitor, including:

Compare the network connection information maintained by the user mode program inside the virtual machine with the network connection information maintained by the virtual machine monitor to obtain hidden network connections;

The virtual machine monitor is used to obtain the mapping information of the process and the port, and the hidden process is obtained according to the network port of the hidden network connection.

A second aspect of the present invention provides a virtual machine monitor-based hidden process detection device, including:

Obtaining a module for obtaining process information in user state, kernel state, and virtual machine monitor respectively;

The first comparison module is used to compare the process information in the user mode with the process information in the kernel mode to obtain the hidden process in the user mode;

The second comparison module is used to compare the process information in the kernel state with the process information in the virtual machine monitor to obtain hidden processes in the kernel state.

The technical effect of one aspect of the present invention is: utilize the technology of hardware virtualization, and as the module that Linux system can load, carry out modification in virtual machine monitor KVM, do not affect the normal operation of virtual machine monitor and produce acceptable The extra performance overhead realizes hidden process detection and identification technology of various views, and further discovers suspicious processes by detecting hidden network connections, realizes multi-angle and all-round process detection, and provides higher security for virtual machines.

Description of drawings

Fig. 1 is a flow chart of a method for detecting hidden processes based on a virtual machine monitor provided by an embodiment of the present invention;

Fig. 2 is the acquisition flow chart of the kernel mode process list provided by the embodiment of the present invention;

Fig. 3 is the flow chart of obtaining the VMM process list provided by the embodiment of the present invention;

FIG. 4 is a multi-view schematic diagram provided by an embodiment of the present invention;

5 is a flowchart of a hidden process detection method of a virtual machine monitor provided by an embodiment of the present invention;

6 is a schematic structural diagram of a virtual machine monitor-based hidden process detection device provided by an embodiment of the present invention;

FIG. 7 is a schematic structural diagram of an apparatus for detecting hidden processes based on a virtual machine monitor provided by an embodiment of the present invention.

Detailed ways

Aiming at the defects and deficiencies in the current hidden process detection mechanism, combined with the characteristics of the virtual machine environment, the present invention proposes a multi-view hidden process detection method and device based on a virtual machine monitor, using hardware virtualization technology, and as a (such as Linux) The module that can be loaded by the system can be modified in the virtual machine monitor KVM without affecting the normal operation of the virtual machine monitor and generating acceptable additional performance overhead. It realizes the hidden process detection of multiple views, and passes Detect hidden network connections to further discover suspicious processes, realize multi-angle and all-round process detection, and provide higher security for virtual machines.

Fig. 1 is a flow chart of a hidden process detection method based on a virtual machine monitor provided by an embodiment of the present invention. As shown in Fig. 1, the method includes:

Step 101, obtaining process information under the user state (User-level), kernel state (Kernel-level) and virtual machine monitor (VMM-level) respectively;

These can include:

(1) Obtain the User-level process list and corresponding process information from the user state application programming interface API provided by the system;

(2) Maintain a Kernel-level process list and corresponding process information by intercepting system calls;

Specifically, the Kernel-level process list can be obtained, but not limited to, through the following methods:

The acquisition of the Kernel-level process list is mainly realized by intercepting system calls. When the process is created and executed, it needs to call the system call to complete the operation. At this time, the fast system call instruction (SYSENTER instruction) will be executed, the system will transfer from the user state to the kernel state, and perform kernel initialization operations. Load the corresponding value into the relevant register, such as the code selector designation register (SYSENTER_CS_MSR) that executes the highest authority (Ring 0) code to save the selector of the kernel code segment, and the start address designation register that executes the highest authority Ring 0 code (SYSENTER_EIP_MSR) saves the linear address of the kernel entry point, and executes the stack pointer specified register (SYSENTER_ESP_MSR) of Ring 0 code to save the kernel stack pointer. Therefore, a non-existent address can be assigned to SYSENTER_EIP_MSR, so that a page fault (PageFault) error exception occurs when a system call occurs, forcing the virtual machine to exchange control of the CPU to the virtual machine monitor. At this time, the virtual machine monitor has obtained the CPU control right, and can obtain the current system call number by reading the EAX register, and judge the current system call type (execve of the process, exit exit_group) by the system call number, to the Kernel- level process list to add or remove members. The flow chart of obtaining the kernel state process list may be shown in FIG. 2 . Step 201, setting the SYSENTER_EIP_MSR of the virtual machine to an unavailable address 0xffffffff; Step 202, causing the virtual machine to be abnormal by the above address, and the CPU control right is controlled by KVM; Step 203, judging whether the above abnormality is a page fault, if so Go to step 204, if not continue step 201; Step 204, intercept the information of the current system call of the virtual machine and the process; Step 205, obtain the system call number from the information of the current system call of the virtual machine; Step 206, judge the system call number; If the system call number is 11, go to step 207; if the system call number is 252, go to step 211; step 207, if the system call number is 11, then go to step 208; step 208, query the current process in the Kernel-level process list information; step 209, judge whether the Kernel-level view has current process information, and if so, the process ends; no, proceed to step 210; step 210, add the process information to the Kernel-level view, then the process ends; step 211, the If the system call number is 252, go to step 212; step 212, delete the process from the Kernel-level view, and the process ends.

After obtaining the process list, it is also necessary to obtain process semantic information. The acquisition of process semantic information is mainly by reading the information in the data structure process descriptor task_struct maintained by the kernel for the process. The acquisition of the process descriptor task_struct is based on the mapping relationship between the process kernel stack address and the process descriptor address. In Linux, when the kernel allocates the process task structure space, it is allocated in units of 8KB, including two page spaces, one is the process information structure (thread_info structure) storage space, and the other is the process used for the system space stack storage. The thread_info structure stores the process descriptor task_struct and is located at the starting address of the address space, while the stack space grows from the high address of the memory space to the low address. Since the starting address of the process kernel space is an integer multiple of 8KB, that is, 213, the address of task_struct is the same as the first 19 bits of the process stack address. It is the kernel stack of the switched process, and the address of the task_struct structure is obtained by bitwise ANDing this value with 0xffffe000 (hexadecimal). At the same time, considering memory virtualization, two address translation mechanisms should be considered when reading process descriptors from memory, that is, guest virtual machine address (GVA, Guest Virtual Address) -> guest physical address (GPA, Guest Virtual Address) Physical Address)->Host Physical Address (HPA, Host Physical Address) conversion.

(3) Obtain the VMM-level process list maintained by the virtual machine monitor.

Specifically, the VMM-level process list can be obtained, but not limited to, through the following methods:

In the virtual machine environment, there is logical consistency between the processor and the system process, so although the system process with specific semantics is invisible to the virtual machine monitor, the address space used by the process is visible to the virtual machine monitor is visible. Therefore, if the virtual machine monitor wants to maintain the process list, it can intercept the CPU events of the process, such as the context switch of the process. Under the x86 architecture, the fourth control register (CR3 register) of the CPU holds the base address of the page directory table under the process address space. Once a new process uses the CPU, its corresponding page directory table base address is written to In CR3, its kernel stack address will be written to the ESP register at the same time. Therefore, an interception point insertion function is set in the CR3 register control operation of the system virtualization software KVM to determine whether a new process starts. Regarding the exit of the process, a fixed time interval is used to judge whether the process exits according to the process state of the kernel process linked list, and make corresponding operations. The flow chart of obtaining the VMM process list may be shown in FIG. 3 . Step 301, wait for the register update event to occur in the CPU; Step 302, the register event occurs in the CPU, KVM obtains the CPU control right, and KVM judges the current register event; Step 303, if the current register is that the CR3 register changes, then proceed to step 304; otherwise, from Step 301 starts. Step 304, the process function is ready to execute; Step 305, obtain the information of the current process; Step 306, query the VMM-level process list according to the obtained process information; Step 307, judge the result of step 306, if there is the process, then proceed to the step 309; otherwise, proceed to step 308; step 308, add the process information into the VMM-level process list; step 309, check the update time mark of the VMM-level list, and judge whether the last update time exceeds 2 seconds; if exceeded, Then proceed to step 310, if not, the flow process ends; step 310, prepare for an update operation to the list of VMM-level; step 311, take the next process from the list of VMM-level, judge whether there is still a process, if there is, carry out Step 312, if not, the process exits; Step 312, query the process data structure doubly linked list maintained by the kernel; Step 313, judge whether the process exists in the doubly linked list, if it exists, then proceed to step 311; otherwise, proceed to step 314; step 314 . Delete the process from the VMM-level list, and go to step 311.

After obtaining the process list, it also includes: obtaining process semantic information. As described in (2) above, details are not repeated here.

Step 102, comparing the process information of the User-level and the process information of the Kernel-level to obtain hidden processes in the User-level;

Step 103: Compare the process information of the Kernel-level with the process information of the VMM-level to obtain hidden processes in the Kernel-level.

Wherein, this embodiment does not limit the execution sequence between step 102 and step 103, and step 102 may be executed first, followed by step 103, or step 103 may be executed first, followed by step 102, or both steps may be executed simultaneously.

The technology in each step is specifically introduced in detail below.

First of all, the multi-view verification technology obtains different views by observing system objects from multiple angles, and there is no correlation between these views. In the hierarchy of the whole system, the higher the hierarchy, the lower the credibility of the view obtained. According to the ease of attack on the system, a hidden system object is more likely to appear in the lower level view. A hidden object can be detected when a system object appears in a higher-trusted view but not in a lower-trusted view.

For the process, the most untrustworthy view can be obtained from the user-level application programming API function (Application Programming Interface) provided by the system, such as using the system to view the commands ps and top to maintain a User-level process list . At the same time, if a process is created or executed, it is generally implemented by calling library functions and system calls in user mode. Therefore, by intercepting system calls, it can be found whether a process is created, activated or destroyed. Therefore, as shown in Figure 4 Multi-view schematic diagram, which can maintain a Kernel-level process list by intercepting system calls. By comparing this Kernel-level list with the User-level list just obtained, the hidden process can be obtained, and it can be seen that the process is hidden in the user mode, because it is invisible to the API of the user mode, but the system library of the kernel mode Functions can be intercepted. But the system call can be bypassed, such as directly executing the kernel function or modifying the system call table inside the kernel, etc., and the rootkit implemented by the loadable kernel module program (LKM, Loadable Kernel Module), hidden in the kernel state, Not only will it not be discovered by user-mode programs, but it will also not be discovered by system calls, so it becomes necessary to obtain the most credible view. In the virtual machine environment, the virtual machine monitor has the highest authority on the virtual machine, and any activity authority of the virtual machine cannot exceed the level of the virtual machine monitor. Therefore, it is convenient to maintain a real VMM-level process list from the virtual machine monitor. It is possible, and as shown in Figure 4, by comparing this list with the Kernel-level list, you can find rootkits hidden in the kernel state that cannot be found in the Kernel-level list.

The invention meets the following requirements: 1) It is transparent to the client. For the virtual machine, the entire detection activity is transparent, and the detection behavior will not affect the normal running state of the virtual machine. Moreover, due to its transparency, the malware inside the virtual machine is also unaware of the existence of the detection system, which is more The safety and accuracy of the detection system are improved. 2) Across semantics, user interaction. The detection function is realized from the outside of the virtual machine, but the system still needs to provide users with clear semantics and a friendly interface, so that users can grasp the status and information inside their virtual machines at any time. At the same time, good semantics facilitate the identification of hidden processes. 3) The view is more complete without omission. Through the multi-view detection mechanism, especially the process information provided by Kernel-level and hidden network ports, the detection of hidden processes inside the virtual machine is more complete. At the same time, it can distinguish the types of hidden processes more finely, for example, whether the process is hidden in the user state or the kernel state, and even detect and discover suspicious processes with hidden behaviors (such as hidden network connections), improve the detection level, and further Enhance the security of virtual machines. 4) Active detection. Since some scans for hidden processes are timed or even passive, and hidden processes may cleverly evade detection at inappropriate time intervals, it is very necessary to capture and detect processes once they are created or even run. 5) Functional ease of use. According to the requirements of the current host environment, the system should be dynamically loadable and removable without affecting the overall environment of the host.

FIG. 5 is a flowchart of a hidden process detection method of a virtual machine monitor provided by an embodiment of the present invention. As shown in FIG. 5, the method includes:

Step 501, comparing the network connection information (view) maintained by the user state program inside the virtual machine with the network connection information maintained by the virtual machine monitor to obtain hidden network connections;

Step 502, using a virtual machine monitor to obtain mapping information between processes and ports, and obtaining hidden processes according to the hidden ports connected to the network.

Wherein, the network port interception is based on the fact that the virtual machine monitor KVM is visible to the network card of the virtual machine, and the operation of packet capture and interception can be performed in the user state of the host machine. The embodiment of the present invention is mainly realized in this way. In particular, the network configuration of the virtual machine in this paper is configured in the form of a bridge, and each virtual machine has a corresponding test access port (tap port, Test AccessPort) to receive and send data packets. The host is visible to the tap port, and can control the network status by capturing packets on the tap port. The network port interception module listens to the tap port, and once a data packet is sent, it can be obtained.

The process-port mapping relationship can be obtained in the following manner: in Linux, a process establishes a network connection by creating a socket (socket) file, and when the process performs network communication, the corresponding socket file is opened. The Linux kernel maintains a list of open files for each process. Through this list, the directory corresponding to each file can be queried, and the real index file on the Linux file system can be searched according to this directory. In the Linux file system, an index data structure of a file index node (inode) is maintained for each real file, and the corresponding mode attribute field (i_mode) is set to represent it, and the built-in socket judgment macro (S_ISSOCK()) It can be used to determine whether i_mode is a socket type. When a file type structure (file) pointer of the process points to a socket file, the socket structure address corresponding to the file will be assigned to the private data attribute (private_data attribute) of the file, and the socket structure can be obtained through the previous judgment. In the Linux network protocol stack, the specific address information will not be stored in the socket structure. The socket structure is created based on the virtual file system and does not save specific network connection information. The specific network protocol information is stored in the extended socket data structure (sock data structure), but it belongs to the socket of the network layer, and more detailed network domain (INET domain) information, such as network address (IP address), port, etc., are stored in the inet_sock data structure. So through such an analysis, you can find the mapping relationship between the process and the port.

Specifically, the purpose of rootkits is mainly to control the target host through network connections, so hiding the relevant network connections is also an important means of attack. By detecting and discovering hidden network ports, and through the corresponding relationship between ports and processes, suspicious processes can be further discovered, preventing rootkits from using seemingly normal user processes to perform malicious network behaviors, such as remote access commands (ssh, telnet) wait. The hiding of the network connection cannot be discovered by user state programs (such as the network connection viewing program netstat program), but the existence of network activities can be discovered by intercepting the network activity of the network card. Implemented inside the virtual machine, there is a possibility of being bypassed, but since the virtual machine monitor is visible to the virtual network card, the virtual machine monitor naturally has the ability to obtain all views of the network activities on the network card. Therefore, hidden network connections can be discovered by comparing the view maintained by the user mode program (such as netstat) inside the virtual machine with the network connection list maintained by the virtual machine monitor. After discovering the hidden port, use the virtual machine monitor to obtain the mapping information between the process and the port, and find the possible process.

On the basis of the foregoing embodiments, the method may also include:

Obtain the process list and network view obtained from the client, obtain the two process lists obtained from the VMM and the corresponding information between processes and ports, obtain the network view obtained from the network port module, process the obtained network view and add the process content , which organizes three views of the process and two views of the network. Since it can be implemented in the form of a device, the interaction between the host kernel and the user mode is mainly realized through the device system device control function (ioctl), while other data transfers in the user mode are mainly through strings and caches.

Persistence processing is located in the user state of the host machine, and its main function is to store the obtained view information in a database, such as a Mysql database. For the process list and network connection views, every piece of information that needs to be stored has been organized.

The function to be realized by the display of the user interface is to dynamically display the detection results of the present invention to the user. The present embodiment adopts the mode based on browser/server (B/S) to carry out the demonstration of web client, and utilizes the agile development mode of the network framework Rails (Ruby On Rails) based on Ruby language, closely combines with Mysql database, captures dynamically Database changes, dynamic page display, that is, once a process is created, the page will be updated.

FIG. 6 is a schematic structural diagram of an apparatus for detecting hidden processes based on a virtual machine monitor provided by an embodiment of the present invention. As shown in FIG. 6 , the apparatus may include: an obtaining module 601 , a first comparison module 602 and a second comparison module 603 . Wherein, the obtaining module 601 is used to respectively obtain the process information in the user state, the kernel state, and the virtual machine monitor, and the first comparison module 602 is used to compare the process information in the user state and the process information in the kernel state to obtain the process information in the user state. The second comparison module 603 is used to compare the process information in the kernel state with the process information in the virtual machine monitor to obtain the hidden process in the kernel state.

In one implementation manner, the process information includes a process list and moral information of the process, and the obtaining module 601 may include: a first unit, a second unit, a third unit, and a fourth unit. Among them, the first unit is used to obtain the process list of the user mode from the user mode API provided by the system, the second unit is used to obtain the process list of the kernel mode by intercepting the system call, and the third unit is used to obtain the process list by intercepting the CPU event of the process For the process list of the virtual machine monitor, the fourth unit is used to obtain the semantic information of each process in each process list by reading the information in the data structure descriptor maintained by the kernel for the process.

On the basis of the above embodiments, the second unit may include: a first subunit, a second subunit and a third subunit. Wherein, the first subunit is used to obtain the currently occurring system call number if a system call occurs, the second subunit is used to determine the type of the currently occurring system call according to the currently occurring system call number, and the third subunit is used to If the type of system call currently occurring is the execution of a process, the process is added to the process list of the kernel state, and if the type of the system call currently occurring is the exit of the process, the process is deleted from the process list of the kernel state.

On the basis of the above embodiments, the third unit is used to: if a CPU event of a process occurs, add the process to the process list of the virtual machine monitor, and judge whether the process is Exit, which removes the process from the hypervisor's processes if it exits.

FIG. 7 is a schematic structural diagram of an apparatus for detecting hidden processes based on a virtual machine monitor provided by an embodiment of the present invention. As shown in FIG. 7 , the apparatus may include: a first module 701 and a second module 702 . Wherein, the first module 701 is used to compare the network connection information maintained by the user mode program inside the virtual machine with the network connection information maintained by the virtual machine monitor, to obtain hidden network connections. The second module 702 is configured to use the virtual machine monitor to obtain the mapping information of the process and the port, and obtain the hidden process according to the network port of the hidden network connection.

In one embodiment, the second module 702 includes a processing unit, configured to obtain a socket structure according to the socket file pointed to by the file pointer of the process, and the inet_sock data structure of the socket structure contains port to obtain the mapping information between the process and the port.

Those of ordinary skill in the art can understand that all or part of the steps for implementing the above method embodiments can be completed by program instructions and related hardware. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above-mentioned method embodiments; and the aforementioned storage medium includes: read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk and other various media that can store program codes.

Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present invention, rather than limiting them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: It is still possible to modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the technical solutions of the various embodiments of the present invention. scope.

Claims (1)

1., based on a hidden process detection method for monitor of virtual machine, it is characterized in that, comprising:

Obtain the network connection information that User space, kernel state and monitor of virtual machine are safeguarded respectively;

The relatively network connection information of virtual machine internal User space program maintenance and the network connection information of virtual machine kernel state program maintenance, the network hidden obtained in User space connects;

The network connection information that the network connection information of more described virtual machine kernel state program maintenance and described monitor of virtual machine are safeguarded, the network hidden obtained in kernel state connects;

Connect the port be connected with the network hidden in kernel state according to the network hidden in described User space, and monitor of virtual machine obtains the map information of process and port, obtain the hidden process in User space and the hidden process in kernel state respectively;

Wherein, described virtual machine to be received packet by corresponding test access port and sends.