KR20150017925A - A detect system against malicious processes by using the full path of access files - Google Patents

Abstract

The present invention relates to a system for checking malicious programs through absolute path management, which converts a relative path for a malicious program, which is generated by using the relative path based on system call hooking, into an absolute path, and which checks the malicious program, warns a user of the same and blocks the same. The system includes: a system call hooking control unit configured to hook a system call of an operating system for a computer terminal; a process processing unit configured to store and update an absolute path of a process (hereinafter referred to as an execution process) executed in the computer terminal; an absolute path determining unit configured to determine whether a path of a file requesting access in the system call is absolute or relative, and to determine whether an absolute path of the access file has been stored when it is determined that the path of the access file is relative; an absolute path combining unit configured to combine an absolute path of a process (hereinafter referred to as a request process) requesting the system call with the relative path of the access file to obtain an absolute path of the access file; and a malicious code checking unit configured to determine whether the access file is malicious by using the absolute path of the access file. The system for checking malicious programs as described above converts a relative path for a malicious program into an absolute path even when the malicious program is generated by using the relative path based on kernel system call hooking, thereby efficiently blocking new malicious programs from being generated. As a result, the system may be safely protected from the threat of new malicious programs.

Description

[0001] The present invention relates to a malicious program detection system using absolute path management,

The present invention relates to a malicious program inspecting system for converting an malicious program generated by a relative path into an absolute path based on system call hooking, and inspecting and warning and blocking the corresponding program.

In particular, the present invention identifies a malicious program and a harmful program by system call hooking, and when a file is generated, if the called path of a specific system call of the system used is a relative path, the relative path is automatically converted to an absolute path And a malicious program checking system through absolute path management for checking whether a newly created file is a normal file or a malicious program.

With the rapid development of Internet technology and the spread of the Internet, harmful programs that threaten the security of Unix and Linux servers are also increasing. Such a malicious program is a program that infiltrates into a system and processes an unrelated task or performs an unusual function, and collects programs such as a virus, a worm, a Trojan horse, and a backdoor.

Malicious programs exist in various forms depending on their type. Such a malicious program may be a program that accesses another program or an operating system to change a code or extract information, an abnormal network packet transmission or reception, or a general program such as a concealment operation for hiding its presence from a security program It has a common characteristic that it performs other abnormal behavior (action).

Generally, the existing antivirus security program periodically checks the harmful program and operates the harmful program. However, since such a conventional security program periodically uses a method of inspecting malicious programs for all files, there is a problem in that the load on the system is large, and during the periodic inspection time, that is, There is a problem in that it can hardly cope with the program.

To solve these problems, there is a method of protecting a computer through real-time monitoring and a computer and its system protected by the method described in Korean Patent Laid-Open No. 10-2004-0083409 [Patent Document 1]. The document is structured to intercept and analyze interrupts or events related to file handling to discard change requests for unauthorized executable files. As a result, it proposes a computer protection method through real-time monitoring that can protect the computer from viruses and the like.

However, the above-described prior art can protect the computer only when the operating system itself provides an absolute path. This is because the prior art computer protection method does not have the path of the currently executing process separately. Therefore, there is a problem that the security function for the harmful program generated by the relative path is limited in the operating system operating in the relative path.

[Patent Document 1] Korean Published Patent Application No. 10-2004-0072633 (published on October 1, 2004)

In order to solve the problems of the background art described above, the present invention is to identify a malicious program and a harmful program, and when a file is generated, Is automatically converted to an absolute path, and an absolute path management is performed to check whether a newly created file is a normal file or a malicious program by using an absolute path.

According to an aspect of the present invention, there is provided a system for inspecting a malicious program through an absolute path management method for inspecting a file accessed by a process executed in a computer terminal to determine whether the process is malicious, A system call hooking control unit for hooking a system call of the system call; A process processing unit for storing and updating an absolute path of a process executed by the computer terminal (hereinafter referred to as an execution process); An absolute path determination unit for determining whether a path of a file requested to access in the system call (hereinafter referred to as an access file) is an absolute path or a relative path, and determining whether an absolute path of the access file is stored in the case of a relative path; An absolute path combining unit for obtaining an absolute path of the access file by combining an absolute path of a process requesting the system call (hereinafter referred to as a request process) and a relative path of the access file; And a malicious code checking unit for determining whether or not the access file is a malicious program by using the absolute path of the access file.

In addition, the present invention relates to a malicious program checking system through absolute path management, wherein the system call hooking control unit hooks only a system call for generation of a process, a path change, a termination, or a system call for accessing a file .

According to another aspect of the present invention, there is provided a system for inspecting a malicious program through absolute path management, wherein the process processor determines an absolute path by using directory information of a parent process to be inherited when the execution process is generated.

According to another aspect of the present invention, there is provided a system for inspecting a malicious program through absolute path management, wherein when the execution process is generated, an attribute of a current directory of the parent process is inquired through an ID of the obtained parent process, And determines the absolute path of the execution process to the inquired directory.

According to another aspect of the present invention, there is provided a system for inspecting a malicious program through absolute path management, wherein the absolute path determination unit stores an absolute path for a predetermined frequently used file, and when the access file is a relative path, Determining whether an absolute path of the access file is stored; and if the absolute path of the access file is stored, converting the relative path of the access file into an absolute path.

According to another aspect of the present invention, there is provided a system for inspecting a malicious program through absolute path management, wherein the absolute path determination unit changes an absolute path to a frequently used file when the file path is changed.

As described above, according to the malicious program checking system through the absolute path management according to the present invention, even when a malicious program is generated as a relative path by kernel system call hooking, the malicious program is converted into an absolute path, Thereby effectively protecting the system from the threat of a new malicious program.

In addition, according to the malicious program checking system through the absolute path management according to the present invention, when a new installation of a malicious process is checked in real time at the kernel level of the operating system, It is possible to fundamentally block the generation of a malicious process that may be newly generated before the second inspection.

In addition, according to the malicious program checking system through the absolute path management according to the present invention, malicious programs are inspected only for newly created files, so that unnecessary files are inspected as compared to existing malicious program inspection systems that inspect all files Thereby reducing the waste of system resources.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram of an entire system for implementing the present invention. FIG.
2 is a table of types of monitored system calls according to an embodiment of the present invention;
3 is a block diagram of a configuration of a malicious program checking system according to an embodiment of the present invention;
4 is a block diagram of a configuration of a system call hook control unit according to an embodiment of the present invention;
5 is a block diagram of a configuration of an absolute path determination unit according to an embodiment of the present invention;
6 is a block diagram of a configuration of an absolute path transforming unit according to an embodiment of the present invention;
7 is a block diagram of a configuration of a process processing unit according to an embodiment of the present invention;
8 is a block diagram of a configuration of a malicious program checking unit according to an embodiment of the present invention;

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

In the description of the present invention, the same parts are denoted by the same reference numerals, and repetitive description thereof will be omitted.

First, examples of the configuration of the entire system for carrying out the present invention will be described with reference to Fig.

1, the present invention is implemented in a conventional computer system. That is, the overall system for implementing the present invention comprises hardware 25, an operating system (OS) 20, a process 10 performed on the operating system, and a malicious program checking system 30 on a computer system. A database 40 for storing data can be additionally configured.

The hardware 25 refers to physical resources of the system such as an input / output device, a storage device (hard disk, etc.), a network device (a network card, etc.) The operating system 20 is a system program for operating a computer system, which is also commonly referred to as a kernel layer. Typically, user computer programs run as a process at the user level.

The process 10 refers to a state in which the computer program is executed on the operating system, and is also referred to as a program (program) code. Therefore, malicious code, malicious programs, and malicious processes are used in combination.

The process 10 calls an application programming interface (API) function of the system dynamic library 21 (Win32.dll, etc.) to utilize the resources (hardware resources) of the computer system. At this time, calling the API function is called a system call.

The kernel layer 20 of the operating system is composed of a system processing module 22, a driver 23, and the like. The driver 23 is a system program for directly controlling the hardware device 25. Therefore, the called API function is processed in the system processing module 22 of the kernel layer, and the system resource is accessed by the driver 23 when necessary.

The malicious program checking system 30 hooks the system call of the process 10 and checks the file (or access file) requested by the process 10. [ That is, by checking the access file, it is checked (or judged) whether or not the file is malicious. At this time, in order to hook a system call, a system call hooking module is included. The malicious program checking system 30 hooks the system dynamic library 21 through the system call hooking module in a normal hooking manner.

First, the malicious program checking system 30 checks whether the hooked system call is a system call (or an API function) to be monitored (or an analysis target). If the hooked system call is not a monitoring target, To run it. In order to confirm whether or not to be monitored, API functions (or system calls) to be monitored are stored in advance in a list and managed.

The monitored API function is shown in FIG. As shown in FIG. 2, it is largely divided into a process-related system call and a file-related system call. Process-related system calls include forking of processes, and file-related system calls are API functions related to file creation, opening, and renaming.

If the system call (API function) is to be monitored, the malicious program inspection system 30 analyzes the hooked system call and detects the absolute path to the file requested by the process 10. [ Then, using the absolute path, the actual stored file is checked. That is, the contents of the file, the type and position of the file, and the like are inspected according to predetermined inspection rules. Through such inspection, it is determined whether the process 10 is malicious or whether a newly created file is a file related to a malicious program.

At this time, a judgment condition for judging whether or not the malicious action is performed is provided in advance. The criterion is empirically created by analyzing past malicious processes.

On the other hand, if the system call is a function related to the process, the malicious program inspection system 30 obtains the absolute path of the process and stores it in the database 40.

Next, the malicious program inspection system 30 determines whether the request is a malicious action, and blocks the system call if malicious action is detected. In other words, the system call is not passed to the system dynamic library 21. Furthermore, the malicious program inspection system 30 may stop and / or request the user to stop the process (or malicious process) or to stop the process.

If it is determined that the request (or system call) is not a malicious action, the malicious program checking system 30 passes the system call to the kernel layer 20. That is, it stores only the absolute path of the process, and the system calls are handled by the kernel.

The database 40 comprises an absolute path DB 41 for storing an absolute path of a file or processes, and a judgment condition DB 42 for storing a judgment condition for judging whether or not the file is malicious. However, the configuration of the database 40 is only a preferred embodiment. In the development of a specific device, the database 40 may have a different structure in consideration of ease of access and retrieval, efficiency, and the like.

Next, the configuration of the malicious program checking system through the absolute path management according to an embodiment of the present invention will be described in more detail with reference to FIG.

3, the malicious program inspection system 30 according to the present invention includes a system call hook control unit 31, an absolute path determination unit 32, an absolute path conversion unit 33, a process processing unit 34, , And a malicious program checking unit 35. [

The system call hooking control unit 31 hooks the system call of the operating system of the computer terminal. To this end, the system call hooking control unit 31 replaces the address of the system call table of the operating system with its own table address. At this time, the table address of the user refers to the memory address of the module (or the system call hooking module) that processes the hooked system call. Therefore, when the system call is called, the system call processing module of the system call hook control unit 31 is called and executed. A specific implementation method is shown in Fig.

As shown in FIG. 4, when the hooking controller 31 is loaded on the system (or on the memory), it is initialized and allocated to the kernel memory, and accesses the system call table of the operating system. If access to the system call of the operating system is successful, the hooking controller 31 substitutes the system call processing module of the operating system for the monitored system call in the system call table of the operating system.

As described above with reference to FIG. 2, the system call to be monitored is classified into a process-related system call or a file-related system call.

Next, the process processor 34 will be described with reference to Fig.

The process processing unit 34 stores and updates the absolute path of a process (hereinafter referred to as an execution process) executed in the computer terminal. In particular, the process processor 34 manages the current path of the execution process and always updates with the latest absolute path.

As shown in FIG. 5, the process processing unit 34 is performed by a system call related to a process. In other words, a process related system call includes a system call (sys_fork, sys_execve) related to process creation, a system call (sys_chdir) that changes the path of the process, and a system call (sys_kill) to terminate the process.

That is, when the system call is hooked by the hooking control unit 31, the process processor 34 performs a task related to the absolute path of the process using the hooked system call.

First, when a new process is created, that is, when a system call for creating a process is called, it is confirmed whether or not the current path of the process exists. That is, it is confirmed whether the absolute path of the current position of the process can be obtained by the system call. If the absolute path of the current location can be obtained, the absolute path is stored in the path database of the process as the path of the corresponding process.

If the process absolute path of the execution process can not be obtained by the system call, the absolute path of the execution process is extracted using the parent process. To do this, first, it is checked whether a parent process of the execution process exists. It then looks up the properties of the current directory of the parent process. And stores the inquired directory in the path database (or process path table) of the process.

That is, when the process is created, the identification information (or ID) of the parent process can also be inquired. Therefore, it accesses the parent process with the parent process ID (or identification information) and reads the property. At this time, the current directory property has the absolute path of the current directory of the parent process. And stores the property value of the current directory of the parent process in the absolute path of the generated process.

The process that is created and executed inherits all the properties of the parent process in the same way as the operating system (OS). Therefore, it is preferable to use the absolute path of the parent process as the absolute path of the process, because the executed process is basically executed in the same path as the parent process.

Next, when the current path of the process is changed, the changed path is transmitted by the system call hooking control unit 31, and at this time, the changed path is updated in the process path table. If there is no modified path, it inherits the changed path from the parent process, as in the case of the creation of the process. Thus, the inherited path (changed process) is updated in the process path table.

Next, when the process is terminated, that is, when the process is terminated by a kill or the like, the current path to the process is deleted from the process table (or the absolute path DB).

That is, the process processor 34 always updates and maintains the current path to the execution processes. The process processing unit 34 analyzes all the system calls in which the absolute path of the process can be changed and maintains the current state of the path of the process (particularly, the absolute path) and stores the current state in the database.

Next, the absolute path determination unit 32 will be described in detail with reference to FIG.

When the system call hooking module 31 inserts the system call hooking module by the system call hooking module 31, the absolute path deciding module 32 determines whether the path of the requested file is < RTI ID = 0.0 > Whether an absolute path or a relative path is determined.

First, the absolute path determination unit 32 stores an absolute path for a frequently used file. Frequently used files are executable files in the operating system's executable file folder (for example, bin folder).

For such frequently used files, the absolute path is stored using the file index (inode) as the identification information. That is, the file index and the absolute path are stored in a database. File indexing, such as inodes, refers to indexing of files used by the operating system. Since the file index (inode) gives each file a unique ID, it can be used as identification information.

Frequently used files are automatically updated when files are changed or deleted.

Next, a case where a file (or an access file) is created or opened will be described. That is, when a system call that creates or opens a file, for example, Sys_create, sys_open, etc., is called, determines the path of the file to be created or opened at this time. The file path is passed as an argument of the system call, and the file argument is determined.

If the path of the file is not a relative path, that is, if it is an absolute path, the absolute path determination unit 32 directly transmits the path to the malicious program checking unit 35.

If the file path is relative, check that the absolute path to the file is stored in the database. That is, it inquires the database whether there is an absolute path stored in the path of the file.

If the absolute path of the file exists, the absolute path of the stored file is transmitted to the malicious program checking unit 35. If the absolute path of the file does not exist, the path of the file is transferred to the absolute path converting unit 33.

The case where the absolute path of the file exists is a case where the file index (inode) and the absolute path are stored in a database for the above-mentioned "frequently used file ". At this time, the index of the file is compared with each other to search the stored file index. The absolute path of the searched file index is selected as the absolute path of the file.

That is, the absolute path determination unit 32 stores an absolute path for a predetermined frequently used file and determines whether the absolute path of the access file is stored if the access file is a relative path. Thus, if the absolute path of the access file is stored, the relative path of the access file is converted into an absolute path.

On the other hand, when the system call makes a request such as a file name change of the file, if the path of the file is an absolute path, the absolute path of the previously stored file is changed to the corresponding path. Also, even if the path of the transferred file is a relative path and an absolute path is stored for the corresponding file path, the path is changed (or updated) to the stored absolute path.

Since the file index (inode) is passed as an argument of the system call even when the file name is rename, it can be updated in the absolute path of the file which is databaseized through the file index.

In addition, when processing a system call such as deleting a file (for example, a system call such as unlink), if the file is deleted, it is desirable to delete the absolute path data of the file also in the absolute path database.

Next, the absolute path converting unit 33 will be described in detail with reference to FIG.

As shown in FIG. 7, the absolute path conversion unit 33 combines the absolute path of the process (or request process) requesting the system call and the relative path of the access file to obtain the absolute path of the access file.

That is, the relative path transmitted by the absolute path determination unit 32 is combined with the process absolute path stored in the process processing unit 34 by the absolute path conversion unit 33. That is, in order to obtain the path (or the access file path) of the access file transferred in the relative path, the absolute path determination unit 32 requests the absolute path of the stored process based on the identifier (ID) of the current process, And sends the harmonized absolute path to the malicious program checker 35 by combining the absolute path and the relative path of the file.

Next, the malicious program determining unit 35 will be described with reference to FIG.

As shown in FIG. 8, the malicious program determining unit 35 determines whether or not the access file is a malicious program by using the absolute path of the access file.

That is, the malicious program determining unit 35 determines whether the malicious program is malicious using the absolute path from the absolute path determining unit 32 or the absolute path converting unit 33. The judgment of whether or not the file is malicious is made by judging the content of the conventional file and the characteristics of the absolute path of the file according to a predetermined rule.

For example, it is a file that should not be accessed by a normal user program (or a process), and it is determined whether it is malicious by receiving an access request or reading a file stored in an absolute path and storing a specific pattern in the file.

If it is judged to be malicious, it blocks the requested system call. In other words, the system call is not passed to the system dynamic library 21. Further, the process (or a malicious process) may be interrupted or the user may be warned and interrupted.

Although the present invention has been described in detail with reference to the above embodiments, it is needless to say that the present invention is not limited to the above-described embodiments, and various modifications may be made without departing from the spirit of the present invention.

10: Process 20: Kernel Hierarchy
21: system dynamic library 22: system processing module
23: Driver 25: Hardware Device
30: Inspection system 31: System call hooking control unit
32: absolute path determining unit 33: absolute path converting unit
34: Process Processor 35: Malicious Program Inspector
40: Database 41: Absolute path DB
42: Judgment condition DB

Claims (6)

1. A malicious program checking system through absolute path management for checking a file accessed by a process executed in a computer terminal to determine whether the process is malicious,
A system call hooking control unit for hooking a system call of an operating system of the computer terminal;
A process processing unit for storing and updating an absolute path of a process executed by the computer terminal (hereinafter referred to as an execution process);
An absolute path determination unit for determining whether a path of a file (hereinafter referred to as an access file) requested to access in the system call is an absolute path or a relative path;
An absolute path converting unit for obtaining an absolute path of the access file by combining an absolute path of a process requesting the system call (hereinafter referred to as a requesting process) and a relative path of the access file; And
And a malicious code checking unit for determining whether or not the access file is a malicious program by using an absolute path of the access file.
The method according to claim 1,
Wherein the system call hooking control unit hooks only a system call for creation of a process, a path change, an end system call, or a file access.
The method according to claim 1,
Wherein the process processor determines an absolute path using directory information of a parent process to be inherited when the execution process is generated.
The method of claim 3,
Wherein the process processor inquires the attributes of the current directory of the parent process through the obtained ID of the parent process when the execution process is created and sets the absolute path of the execution process to the inquired directory. Malicious program inspection system through management.
The method according to claim 1,
Wherein the absolute path determiner comprises:
You can store absolute paths for predefined frequently used files,
Determining whether the absolute path of the access file is stored if the access file is a relative path,
And if the absolute path of the access file is stored, converting the relative path of the access file into an absolute path.
The method according to claim 1,
Wherein the absolute path determination unit changes the absolute path to the changed path when the file path is changed for the frequently used file.

Images