This application claims priority from both PCT Application PCT/RU2013/000249, filed Mar. 27, 2013, which claims the benefit of earlier filed Russian Application RU 2012113963, filed on Apr. 11, 2012, the entire contents of which are incorporated herein by reference.
The present invention relates to computer engineering and to providing information security of automated information systems, in particular, to means for detecting malware.
Basic methods of detecting malware in application software, which have been developed and are presently used, rely on:
Rootkit Profiler LX is a conventional application software package for detecting malware [1].
Rootkit Profiler LX checks:
Therefore, said known tool has a deficiency in that it does not provide for the integrity check of the entire kernel code, or for the dynamic check of execution of the kernel code, so interceptions in OS data structures, as well as interceptions and code modifications in the kernel (except for virtual file system structures) cannot be detected.
Another conventional method for detecting malware [2] that is implemented in a computer with an operating system, according to one embodiment, comprises the steps of:
setting a break point when a user application makes a system call requesting to modify a data structure of the loaded operating system;
checking the data structure of the loaded operating system by performing the steps of:
In this context, the term “data structure” refers to tables of executed processes (including user applications) generated by the operating system, links to the system registry and files, etc.
Prior to implementing the method, read and write access is provided to random-access memory areas having the loaded OS kernel and kernel modules therein, and the operating system is downloaded into the computer. The method can be implemented in computers running a general-purpose operating system, such as Unix, Linux, Microsoft Windows, etc.
The method can be directly implemented using the following preliminarily created application software:
kernel debugger facilities operative to obtain data from data structures generated by the operating system by setting a break point;
an integrity checker operative to determine whether the data obtained by the kernel debugger facilities when the break point has been set contains inconsistencies typical to malware;
a detection module for coordinating the obtained data generated by the operating system, and for providing data to the integrity checker.
These software tools are not unique and can be created by a skilled person (programmer) familiar with the functions executed by the tools.
The latter known method is the most relevant prior art for the present invention.
However, said known method has a drawback of low probability of malware detection, since actions can be monitored only when an OS data structure is modified. Therefore, the known method is unable to detect malware directly in the OS kernel and kernel modules.
The present method involves the dynamic check of execution of the OS kernel code to detect illegal interceptions and code modifications in the kernel and loadable kernel modules (drivers).
The technical result relates to the increased probability of malware detection by enabling to detect illegal interceptions and code modifications in the OS kernel and loadable kernel modules.
Another technical result relates to enabling to check integrity of the executable kernel code.
To this end, a method is provided, the method comprising the steps of:
setting a break point when a user application makes a system call requesting to transfer control to an address in a kernel of a loaded operating system;
checking a data structure of the loaded operating system by performing the following steps:
Therefore, in contrast to the conventional method in which the check is performed only in the case of a modification in a data structure of the loaded operating system, the present method checks the entire plurality of addresses of commands executed during the system call.
This allows all the commands and address transitions to be controlled, including the ones generated by malware within the kernel and operating system modules, rather than only by malware in user applications.
Furthermore, integrity of the executable kernel code is verified as well.
The method (100) of detecting malware in a kernel of an operating system installed on a computer according to the present invention is generally described with reference to
A break point is set (110) when a user application makes a system call requesting to transfer control to an address in the kernel of the loaded operating system. Then a data structure of the loaded operating system is checked by performing the following operations,
An address of a command, to which the control will be transferred during the system call, in a random-access memory (RAM) of the computer is determined (120), and addresses of commands to be executed during the system call are checked (130) for belonging to a normal range of addresses of the operating system kernel and kernel modules in the RAM. Presence of malware is identified (140) if a command address does not belong to the normal range of addresses.
A prerequisite for implementing the present method (100) is to provide read and write access to random-access memory areas in which the kernel of the loaded operating system and kernel modules reside. This prerequisite can be most easily realized under Linux.
Implementation of the present method will now be described for a computer having:
Similarly to the prior art method, for automated execution of the method (100) a kernel debugger routine should to be preliminarily created for:
The routine can be created by a person skilled in operating systems (programmer).
Before the actual implementation of the present method, it is advisable to build a trusted image of the operating system kernel for further comparison.
To do this, an image of the operating system kernel is built first, e.g. in the computer's hard disk, and then the kernel image is unpacked. Generally, the kernel code is packed using a conventional archiver program, and Gzip, Bzip algorithms and the like can be used for packing/unpacking.
The unpacked kernel code is in the ‘elf.’ file format. Code segments are determined in the resulting file.
Correction of modified addresses of the kernel code is performed in the code segments, as done by a kernel loader typical to this operating system:
The result is the trusted (reference) image of the operating system kernel and the normal range of addresses of the kernel code residing in the random-access memory.
Thus, the normal range of kernel addresses is a set of random-access memory address ranges that hosts the trusted (reference) image of the kernel code and OS kernel modules upon booting the trusted (reference) operating system image in a regular operation mode in the absence of malware.
The trusted image of the OS kernel is built using standard means for handling OS files.
To obtain the normal range of addresses of the OS kernel and kernel modules, an auxiliary routine should be also created for:
Advisability of creating the auxiliary routine is dictated by the fact that malware may modify standard OS tools to conceal its presence in the computer.
Creation of such an auxiliary routine is also within the skills of operating system programmers.
After the above preparatory steps, integrity of the kernel code of the operating system downloaded into the computer random-access memory is first checked by consecutive comparisons with the trusted kernel code.
Where a modification of an address is detected, the check is performed for whether or not the address belongs to a trusted module in the kernel. If not, a decision is taken that malware is detected.
If modified commands are detected, then a decision is also taken that malware is detected.
Upon detecting malware, any conventional method can be applied to neutralize it, for example, by sequentially completing a process associated with the malware; removing the malware and deleting a file containing the code of a program performing actions of the malware [2].
Upon successful verification of kernel code integrity, execution of the kernel code is dynamically checked.
To do this, a list of addresses is formed that correspond to code portions of the kernel and kernel modules.
Then, the kernel debugger locks switching of processes.
The processor is switched to the debug mode, and the trace flag TF=1 is set for all kernel threads.
Maskable interrupts are disabled by the CLI instruction.
Kernel entry point hookers are set (SYSENTER, int80h).
Maskable interrupts are enabled by the STI instruction.
The process switching is then unlocked.
When a debug interrupt is performed responsive to a transfer, the transfer address is checked.
If the address does not belong to the kernel code or kernel module code, the module that contains this address is identified as malicious.
Then the BTF=1 flag is set in the processor, and the debug interrupt handler is quitted.
Subsequently, the detected malicious kernel module can be neutralized using actions similar to those described above.
[1] Klein T. Rootkit Profiler LX. Overview and Documentation [electronic resource] (http://www.trapkit.de/research/rkprofiler/rkplx/RKProfilerLX_v0.12—20070422.pdf, Apr. 22, 2007)
[2] U.S. Pat. No. 7,571,482, Automated rootkit detector, Aug. 4, 2009.
Number | Date | Country | Kind |
---|---|---|---|
2012113963 | Apr 2012 | RU | national |
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/RU2013/000249 | 3/27/2013 | WO | 00 |
Publishing Document | Publishing Date | Country | Kind |
---|---|---|---|
WO2013/154459 | 10/17/2013 | WO | A |
Number | Name | Date | Kind |
---|---|---|---|
7571482 | Polyakov et al. | Aug 2009 | B2 |
7647636 | Polyakov et al. | Jan 2010 | B2 |
7673137 | Satterlee et al. | Mar 2010 | B2 |
8099785 | Pavlyushchik | Jan 2012 | B1 |
8104089 | Guo et al. | Jan 2012 | B1 |
8572729 | Lowe et al. | Oct 2013 | B1 |
8677492 | Rusakov | Mar 2014 | B2 |
9009823 | Ismael et al. | Apr 2015 | B1 |
20080022406 | Clift et al. | Jan 2008 | A1 |
20090187763 | Freericks et al. | Jul 2009 | A1 |
20090288167 | Freericks et al. | Nov 2009 | A1 |
20100122343 | Ghosh et al. | May 2010 | A1 |
20100199325 | Raleigh | Aug 2010 | A1 |
20110289308 | Sobko et al. | Nov 2011 | A1 |
20120079596 | Thomas et al. | Mar 2012 | A1 |
20120159630 | Wang | Jun 2012 | A1 |
20120255015 | Sahita et al. | Oct 2012 | A1 |
20130091318 | Bhattacharjee et al. | Apr 2013 | A1 |
20130097355 | Dang et al. | Apr 2013 | A1 |
20130263270 | Cote et al. | Oct 2013 | A1 |
20140047544 | Jakobsson | Feb 2014 | A1 |
20150033227 | Lin et al. | Jan 2015 | A1 |
20150067763 | Dalcher et al. | Mar 2015 | A1 |
20150089645 | Vandergeest | Mar 2015 | A1 |
Number | Date | Country |
---|---|---|
107619 | Aug 2011 | RU |
107620 | Aug 2011 | RU |
Entry |
---|
International Search Report for PCT/RU2013/000249, mailed Aug. 29, 2013. |
Klein, T., “Rootkit Profiler LX: Overview and Documentation—Version 0.12”, available online at http://www.trapkit.de/research/rkprofiler/rkplx/rkprofilerlk—v0.12—20070422.pdf, Apr. 22, 2007. |
Levine, John G., “A Methodology for Detecting and Classifying Rootkit Exploits”, Gerogia Institute of Technology, Feb. 2004, available online at https://smartech.gatech.edu/bitstream/handle/I 853/5139/john—g—levine—200405—phd.pdf?sequence= I″, c. 22-23, 53, 64-67, Feb. 2004. |
Number | Date | Country | |
---|---|---|---|
20150096028 A1 | Apr 2015 | US |