KR101064164B1 - Kernel integrity inspection and the recovery method on linux kernel based smart platform - Google Patents

Abstract

The present invention relates to a kernel integrity check and a modulated kernel data recovery method in a Linux kernel based smart platform; A first step of checking whether the compressed original kernel image of the ROM partition area is modified through an md5 hash checksum; A second step of decompressing and storing the original kernel image stored in the ROM partition if the original kernel image is not modified by performing the first step; A third step of accessing data in kernel memory running through the / dev / kmem device, which is a kernel virtual memory mapping file, after the second step; A fourth step of checking whether the memory has been tampered with by comparing the contents of the running kernel memory with the contents of the original kernel image after the third step; And a fifth step of restoring the kernel memory to the same data as the original kernel image if it is determined that the kernel memory is modulated through the fourth step. According to the present invention, through the virtual memory mapping file kmem device access, it is possible to detect the rootkit installed in the kernel perfectly without the system call hooking process through the dynamic loadable kernel module under the general administrator authority. In addition, according to the present invention, since the original kernel image stored in the ROM partition area in a compressed form is an area difficult to be tampered by the rootkit except for firmware update, the original kernel image is first examined by checking the md5 hash checksum value of the original kernel image. After inspecting the integrity of the image, it can be compared with the original kernel image with guaranteed integrity to detect and recover tampered kernel memory without having to build a separate kernel source database.

Description

Kernel integrity inspection and the recovery method on Linux kernel based smart platform}

The present invention relates to a kernel integrity check and a modified kernel data recovery method in a Linux kernel-based smart platform, and more particularly, a kernel in a smart platform such as a smartphone or a tablet PC based on the Linux kernel. Based on the rootkit prevention technology, it is possible to detect malicious rootkit installed in the form of dynamically loadable kernel module in smart platform kernel without any kernel module driver installation process before and after and recover kernel data modulated by rootkit. It is about a method.

After analyzing the attack paradigm on Linux systems that occurred in the last decade, Trojan rootkits such as binary replacement at the application level became popular, but around 96, kernel-based rootkits using the Dynamic Loadable Kernel Module (LKM) began to be used. .

These Linux kernel-based rootkits operate by dynamically loading module drivers into the runtime kernel, intercepting normal system calls and causing the attacker's system call functions to be called, thus making system call hooking or system call wrapping. Also called).

Linux systems with these kernel-based rootkits can be easily attacked by an attacker and can hide specific processes and files, or manipulate relevant log data, which cannot be detected using system-level analysis using application-level commands. exist.

Therefore, the kernel-based rootkit detection technology is designed to prevent accidents caused by the kernel-based rootkit.

As such kernel-based rootkit detection techniques, Patent Registration No. 10-0456512, 'Kernel Backdoor Detection System, Kernel Backdoor Detection Method and Kernel Data Recovery Method', and Patent Publication No. 10-2004-0003221 'Unix Kernel Mode. Kernel backdoor detection and countermeasure apparatus and method thereof 'and Patent No. 10-0745640' Method and apparatus for protecting kernel memory 'have been presented.

At this time, the conventional kernel-based rootkit detection techniques described above use a method of preparing an original database in the kernel and backing up the module driver name and kernel original data to allow installation. Therefore, after the installation of the security module driver, in order to block the installation of the rootkit, the module driver installation related function is blocked and the installation of the malicious kernel-based rootkit is blocked by prohibiting installation other than the authorized module driver.

However, the conventional kernel-based rootkit detection technology as described above has various disadvantages as described below, and thus there is a problem that the applied rootkit technology cannot be blocked.

First, in case of prevention technology that hooks kernel module driver installation related function and prohibits installation other than authorized module driver, it blocks the bypass attack that installs by changing the name of malicious rootkit with the module driver name which is allowed. The disadvantage is that it is difficult to do. In other words, an attacker who has obtained administrator privileges can easily obtain the information of the module driver currently loaded on the system, and there is a problem of bypass installation by changing the malicious rootkit to an authorized name.

In addition, the conventional kernel-based rootkit detection technology commonly performs an operation of storing the original kernel memory value in a safe state by building a kernel source database. There is a technical loophole that detection and memory recovery are impossible. Since this assumes that a kernel-based rootkit has already been installed by an attacker, it must assume that data information modified by the attacker can be stored in the kernel source database. Therefore, in a system with rootkits already installed, it is not only difficult to detect manipulated kernel memory or recover tampered system call table (sys_call_table) or exception vector table to original data values, but also to store the entire original data of the kernel. Since there is no data storage space limitation, there is no way to recover the code or data information other than the original data stored in the database.

In addition, since the existing kernel-based rootkit detection technologies were developed for general-purpose operating systems such as Linux, Unix, and Windows, there is a fundamental problem that it is difficult to apply the technology to the smart platform that provides different kernel versions for each manufacturer. That is, the conventional Linux kernel-based rootkit detection technology has a problem that it is difficult to apply a module driver compiled in another environment to a general-purpose server environment because the kernel module driver depends on the compiled kernel environment and operates depending on the kernel version. In particular, in the case of smart platform environment using various kernel versions, there is a technical limitation that the module driver compiled for each manufacturer's kernel version must be distributed separately during installation.

Therefore, the present invention solves the problems of the conventional kernel-based rootkit detection techniques in view of these points, and was invented for the new smart platform to access the kernel without the installation process of the dynamic loadable kernel module and the hooking process to intercept system call calls. Its purpose is to provide a kernel integrity check and a modified kernel data recovery method within Linux kernel-based smart platform.

It is also an object of the present invention to provide a kernel integrity check and a modulated kernel data recovery method capable of inspecting the Linux kernel without installing new modules or changing kernel memory contents.

In addition, the present invention can detect the presence or absence of a kernel-based rootkit by utilizing the original kernel image stored in a compressed form in a ROM (Read Only Memory) partition area in a smart platform without building a kernel source database. Even after the installation is performed, the kernel integrity check and tampered kernel within the Linux kernel-based smart platform can accurately detect the location of the tampered memory and recover the normal code and original data if the tampered data is present. Its purpose is to provide a data recovery method.

The present invention to solve this technical problem;

A first step of checking whether the compressed original kernel image of the ROM partition area is modified through an md5 hash checksum; A second step of decompressing and storing the original kernel image stored in the ROM partition if the original kernel image is not modified by performing the first step; A third step of accessing data in kernel memory running through the / dev / kmem device, which is a kernel virtual memory mapping file, after the second step; A fourth step of checking whether the memory has been tampered with by comparing the contents of the running kernel memory with the contents of the original kernel image after the third step; A fifth step of restoring the kernel memory to the same data as the original kernel image if it is determined that the kernel memory is tampered with the fourth step; kernel integrity check in the Linux kernel-based smart platform And a modulated kernel data recovery method.

In this case, a sixth step of checking whether the original kernel image has been modified through the first step and recording a warning log when the firmware has been hacked and the ROM partition area has been tampered with is further included.

The method may further include a seventh step of recording an error log and terminating the program if decompression of the original kernel image fails while the second step is performed.

The fourth step may include a data integrity check module that checks data of the kernel memory and a code integrity check module that checks a code of the kernel memory, but an exception vector of an interrupt implementation unit through the data integrity check module. Step 4_1 of performing integrity check of the table; 4_2 step of checking whether the code handler vector_swi function code is modified through the code integrity check module; Checking whether a system call table address has been modified through the data integrity check module; 4_4 checking the integrity of a system call processing function code through the code integrity checking module; And a step 4_5 of detecting the modulated code or data during the inspection of the network protocol handler through the data integrity check module and the code integrity check module.

In the fifth step, the original kernel image is retrieved from a secure memory location in which the code and data at the physical address location of the original kernel image are stored, and the original kernel image is restored to the virtual address location of the modulated kernel memory by 1 byte data unit. It is characterized by that.

According to the present invention, through the virtual memory mapping file kmem device access, it is possible to detect the rootkit installed in the kernel perfectly without the system call hooking process through the dynamic loadable kernel module under the general administrator authority.

In addition, according to the present invention, since the original kernel image stored in the ROM partition area in a compressed form is an area difficult to be tampered by the rootkit except for firmware update, the original kernel image is first examined by checking the md5 hash checksum value of the original kernel image. After inspecting the integrity of the image, it can be compared with the original kernel image with guaranteed integrity to detect and recover tampered kernel memory without having to build a separate kernel source database.

In addition, the kernel memory integrity detection module and recovery module, which are divided into five stages, can be used to detect kernel tampering, change the memory in the kernel, or compile modules for each kernel version provided by each manufacturer. There is an advantage in that the rootkit can be detected more reliably because there is no need to burden the operating kernel by installing the driver separately.

In addition, the present invention is not limited to only the smart platform such as smart phones, tablet PCs, IP TV, kernel integrity check and modulated kernel data recovery, and is applicable to all operating system platforms based on the Linux kernel. It is possible to develop innovative security solutions that apply the technology.

1 is a block diagram of a kernel-based rootkit detection system according to the present invention.
2 is a flowchart illustrating a kernel-based rootkit detection process according to the present invention.
3 is a flowchart illustrating an execution process of a kernel memory integrity check module according to the present invention.
4 is a diagram illustrating the detection of a modulated system call table in the kernel memory integrity check module according to the present invention.
5 is a diagram illustrating the detection of a modulated system call function in the kernel memory integrity check module according to the present invention.

With reference to the accompanying drawings, a kernel integrity check and a modulated kernel data recovery method in the Linux kernel-based smart platform according to the present invention will be understood by the embodiments described in detail below.

The present invention relates to a kernel-based rootkit prevention technology, which can be performed automatically in a batch check mode during online banking or electronic commerce, or in a real-time monitoring mode by executing as a background process in the form of a daemon service.

As shown in FIG. 1, the present invention first checks whether the contents of an original kernel image of a ROM partition provided by each platform manufacturer are modified, and the original kernel image stored in a compressed form in the ROM partition. Release kernel source access module 110 to obtain the source code or data information of the kernel by releasing, and kernel memory access module that attempts to directly access the memory in the running kernel through the kmem device which is a virtual memory mapping file ( 120), the kernel memory integrity check module 130 for detecting whether the kernel memory has been tampered with, even if the malicious kernel rootkit of the attacker is already installed, and the integrity check proceeds through the kernel memory integrity check module 130. The contents of the tampered memory when it is detected Kernel memory recovery module 140 for.

At this time, the kernel memory integrity check module 130 detects whether the kernel memory has been tampered with and unidirectional hash of each code and data necessary for the check to improve performance and speed, md5 hash checksum (Message Digest-One Way Hash Algorithm). It is desirable to have a fast integrity check module that checks using an algorithm.

Hereinafter, each configuration module according to the present invention will be described in more detail.

First, since the firmware inspection module 100 for detecting the kernel rootkit obtains the contents of the original kernel image from a ROM partition provided by each smart platform manufacturer, it checks whether the compressed original kernel image is not tampered with.

At this time, the firmware check module 100 stores the md5 hash checksum value for each kernel version distributed by each manufacturer and checks whether it is the correct original kernel image. Therefore, when the hacked firmware is stored in the ROM partition, the firmware check module 100 uses the modified firmware. Can detect facts

When it is determined that the normal firmware is not tampered by performing the firmware inspection module 100, the original kernel image access module 110 for releasing the compressed original kernel image stored in the ROM partition is performed.

The original kernel image access module 110 stores a md5 hash checksum value separately to decompress the compressed original kernel image and then decodes the original kernel image to be stored on the disk, and randomly changes a temporary file name every time. To save it to disk.

In this case, the original kernel image access module 110 preferably processes data in units of 1 byte in order to correspond to a rootkit having a feature of modulating a value when accessing data of a specific pattern.

Meanwhile, a kernel memory access module 120 is executed to secure memory data of a running kernel through a / dev / kmem device, which is a kernel virtual memory mapping file, to compare with the original kernel image.

The kernel memory access module 120 allocates kernel memory data to be read and written in an arbitrary memory area in a basic page unit (4096 bytes) and accesses it in 1 byte data units.

In particular, the kernel memory access module 120 is composed of an ELF format binary that can be executed in a general administrator authority, not a dynamic loadable kernel module type, so that a specific module driver is not installed in the running kernel or changes are not made to the memory. You can get data in kernel memory by the size.

After detecting whether the original kernel image access module 110 decompressing the original kernel image and the kernel memory access module 120 securing the data of the kernel memory operate normally, the modulated memory may be detected. The kernel memory integrity check module 130 may be executed.

The kernel memory integrity check module 130 compares the original kernel image contents with the kernel memory contents and detects the modulated memory.

In this case, the kernel memory integrity checking module 130 refers to the exception vector table 150 and the system call table 152 that are referenced when an interrupt occurs to check the integrity of the kernel memory, and processes the system call function vector_swi function code. It detects code and data that the rootkit has tampered with by examining kernel critical information such as system call tables, system call function code, network protocol handler tables, and handler code.

The kernel memory integrity check module 130 includes a data integrity check module 132 for checking data and a code integrity check module 134 for checking code.

The data integrity check module 132 is a module for checking whether data is modified in kernel memory and checks a descriptor table, an exception vector table, a system call table, a network protocol handler table, and the like having a data size of 4 bytes.

In addition, the code integrity check module 134 calculates the address range of the exported symbol functions based on the / proc / kallsyms kernel symbol table information that manages the symbols used in the kernel to obtain the size of each function, and then the original kernel image. And check whether the vector_swi function code, system call function code, network protocol handler code, etc. in kernel memory have been tampered with by 1 byte unit.

In addition, when detecting the code and data modulated in the process of performing the kernel memory integrity check module 130, the kernel memory recovery module 140 corresponds to the original data of the kernel memory modulated in the original kernel image It finds the value and restores the data in 1 byte unit.

In this case, since the original kernel image uses a physical address system unlike the kernel memory consisting of the virtual address system, the kernel memory recovery module 140 operates when the kernel memory recovery module 140 operates because the virtual address differs from the virtual address by 0xc0008000. The data of the original kernel image secured by the kernel memory integrity check module 130 is restored to the virtual address location of the modulated memory.

Meanwhile, the kernel memory integrity check module 130 sequentially processes the process as shown in FIG. 2 using the data integrity check module 132 and the code integrity check module 134. According to this, a total of five checks are performed, starting with the interrupt implementation check of the processor (for example, ARM 9). In general, in the case of an ARM processor used in a smart platform, when an interrupt or an exception occurs, the branch to the address of the hardware-specified exception vector table 150 is branched to the exception vector table 150. Exception handlers 151 are implemented.

The process of checking the integrity of the interrupt implementation unit through the data integrity check module 132 determines whether the addresses of the exception vector table 150 and the exception handler 151 have been tampered with. First, to check the location of the vector to check the exception vector table 150, a process of checking whether a low vector (0x0) implemented at a low address or a high vector (0xffff0000) implemented at a high address is performed. Find the location of the exception vector table 150. After checking the 4-byte code branching from the retrieved exception vector table 150 to the exception handler 151 located at offset 0x8, the address of the vector_swi function, which is the exception handler 151 that handles the software interrupt, is correct. In this case, the first inspection process for the interrupt implementation of the ARM processor is completed.

After performing the step (S100), the integrity check of the vector_swi function code through the code integrity check module 134, the function is stored in the system call table by referring to the system call number contained in the r7 register as an index It is responsible for calling the call function. As such, by performing a check on the vector_swi function that directly handles the system call table 152 immediately after the interrupt implementation part check, it ensures the safety of the section from the interrupt occurrence until the processing function in the system call table 152 is called. (S102)

After performing the step (S102), it is checked through the data integrity check module 132 whether address modification of the system call processing functions 153 stored in the system call table 152. In the Linux kernel using 2.6 kernels, there are more than 320 system call functions. Therefore, the number of system call functions is checked for the processing function addresses stored in the table. However, in case of smart platform using ARM processor, unlike Linux kernel running on other processor, the unused system call address such as empty system call is included in the table. By performing the process of obtaining the address of an empty system call in advance during the inspection, it is possible to reduce the false positive rate and improve the inspection speed.

When the check is completed by performing the step (S104), the integrity check of the system call function code 153 is performed through the code integrity check module 134. At this time, the code integrity check module 134 calculates the address range of the exported symbol function through the / proc / kallsyms kernel symbol table information mapped at boot or calculates the address range between the prolog and epilog of the function. After obtaining the size of the call function 153, a detailed inspection is performed to compare the function code of the original kernel image with the function code in the kernel memory by 1 byte. Since the original kernel image data is secured by the size of the symbol function in the integrity check process, it is possible to quickly recover the memory contents modified in the kernel memory in the future (S106).

After performing step S106, the network protocol handler table and the network located in the structure are mixed with the data integrity check module 132 and the code integrity check module 134 to check the integrity of the network protocol handler 154. Integrity check is performed on the protocol handler code (S108). In the process of checking the network protocol handler 154 through the data integrity check module 132 and the code integrity check module 134, the modulated code or data is detected. In this case, the kernel memory recovery module 140 performs recovery with the same data content as the original kernel image.

Hereinafter, a kernel integrity check and a modulated kernel data recovery process in a Linux kernel-based smart platform according to the present invention will be described with reference to FIGS. 1 to 5.

After the kernel-based rootkit detection solution that detects the kernel-based rootkit through the present invention is executed, the firmware inspection module 100 is first executed (S10), and whether the original kernel image data of the ROM partition area provided by each manufacturer is modified. Check through the md5 hash checksum (S12).

At this time, if the firmware is hacked and the ROM partition area is tampered with during the process of checking whether the original kernel image data has been tampered with (S12), a separate warning log is recorded and the inspection continues.

If it is determined that the original kernel image data is normal firmware unmodulated by performing the above step S12, the original kernel image stored in the ROM partition is decompressed through the original kernel image access module 110 (S16).

In this case, when performing the step S16, the ROM partition includes the original kernel image zImage and the RAM file system initramfs. Therefore, if the original kernel image access module 110 fails to extract the error log, Record and exit the program.

On the other hand, if the normal kernel image is decompressed by performing the step S16, the kernel memory access module 120 checks whether data in the kernel memory is accessible through the / dev / kmem device, which is a virtual memory mapping file. (S18)

 By performing the step (S16) to confirm that the normal operation (S20), if the device is not accessible, write an error log and terminate the program (S22), while if it is confirmed that the normal operation of the kernel memory integrity check module ( 130) to check the integrity of the kernel memory (S24).

If it is assumed in step S24 that the kernel-based rootkit is installed, the attacker can manipulate the 4-byte code value of the exception vector table 150 that exists due to the characteristics of the ARM processor, so that the manipulated exception handler is called instead of the normal exception handler. It can be made as possible. Also, by modifying the exception handler address located near the exception vector table, the manipulated exception handler can be induced to be called.

Therefore, the kernel memory integrity check module 130 performs the integrity check of the exception vector table of the interrupt implementer first through the data integrity check module 132.

Subsequently, in the second checking process, the code integrity check module 134 checks whether the vector_swi function code, which is the exception handler 151, has been tampered with. The exception handler function is a function that is responsible for calling each system call processing function stored in the system call table 152 and is one of functions that are commonly tampered with by an attacker.

After the second check process is completed, a third check process is performed to check whether the system call table address has been modified through the data integrity check module 132. For reference, the system call table 152, which stores addresses of system call processing functions, is known as data that kernel-based rootkits most frequently manipulate.

Thereafter, in the fourth step of checking, the code integrity checking module 134 checks the integrity of the system call processing function code. In the past, attackers have developed and used an attack method that directly modifies the code area of the system call processing function without accessing the system call table to bypass the secured solution for the system call table. This made it possible for an attacker to hook a system call without modifying the system call table.

After the fourth checking process for detecting such an operation is completed, the operation of the kernel memory integrity checking module 130 is completed by checking the integrity of the network protocol handler table and the code in the last fifth checking process.

As a result of comparing the modulated data by performing the step S24 (S26), if the modulated code or data is found, the kernel memory recovery module 140 restores the same data contents as the original kernel image. That is, the process of retrieving the original kernel image data from the secure memory location where the code and data at the physical address location of the original kernel image are stored and restoring the data at the virtual address location of the modulated kernel memory by 1 byte data unit is performed. After the last run, we will terminate the kernel-based rootkit detection solution.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments, but, on the contrary,

100: firmware check module
110: original kernel image access module
120: kernel memory access module
130: kernel memory integrity check module
140: kernel memory recovery module

Claims (5)

A first step of checking whether the compressed original kernel image of the ROM partition area is modified through an md5 hash checksum;
A second step of decompressing and storing the original kernel image stored in the ROM partition if the original kernel image is not modified by performing the first step;
A third step of accessing data in kernel memory running through the / dev / kmem device, which is a kernel virtual memory mapping file, after the second step;
A fourth step of checking whether the memory has been tampered with by comparing the contents of the running kernel memory with the contents of the original kernel image after the third step;
And a fifth step of recovering the kernel memory to the same data as the original kernel image if it is determined that the kernel memory is modulated through the fourth step.
A sixth step of checking whether the original kernel image has been tampered with, and writing a warning log if the firmware has been hacked and the ROM partition area has been tampered with. How to check kernel integrity and recover kernel data that has been tampered with.
The method of claim 1,
A seventh step of recording an error log and terminating the program when the decompression of the original kernel image fails while performing the second step; and kernel integrity checking and tampering in the Linux kernel-based smart platform further comprising: Kernel data recovery method.
The method of claim 1, wherein the fourth step,
A data integrity check module that checks data of the kernel memory and a code integrity check module that checks code of the kernel memory,
Step 4_1 of performing an integrity check of the exception vector table of the interrupt implementer through the data integrity check module;
4_2 step of checking whether the code handler vector_swi function code is modified through the code integrity check module;
Checking whether a system call table address has been modified through the data integrity check module;
4_4 checking the integrity of a system call processing function code through the code integrity checking module;
Kernel integrity check and modulation within the Linux kernel-based smart platform, characterized in that consisting of; 4_5 step that detects the code or data modulated in the process of the network protocol handler through the data integrity check module and the code integrity check module Kernel data recovery method.
The method of claim 1, wherein the fifth step,
Linux kernel-based, characterized in that the step of retrieving the original kernel image from the secure memory location that stores the code and data in the physical address location of the original kernel image in 1 byte data unit at the virtual address location of the modulated kernel memory Kernel Integrity Checking and Modulated Kernel Data Recovery Methods in Smart Platforms.
delete

Images