Reveal how malicious Linux kernel modules work

Article Title: reveal how malicious Linux kernel modules work. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

What should you do if traditional tools are completely ineffective in intrusion investigation? When I was dealing with the kernel modules that had been loaded by intruders, I got into this dilemma. Since the upgrade from the user space to the kernel space, the LKM intrusion method has changed the previously used Intrusion Response technology. Once the kernel space is damaged, the impact will cover the entire user space, so that intruders can control their behavior without modifying the system program. Even if you upload trusted toolkit to the compromised host, these tools are no longer trusted. Next I will reveal how the malicious kernel module works and provide some tools I developed to deal with such intrusion.

LKM Overview

The existence of LKM is a good news for system administrators and a nightmare for intrusion detection. LKM was initially designed to change the running kernel without restarting to provide some dynamic functions. The dynamic Kernel provides additional support for devices such as new file system types and network adapters. In addition, because the kernel module can access all the calls and storage areas of the kernel, it can change all parts of the entire operating system unlimitedly, therefore, all calls and memory resident structures may be modified by malicious kernel modules.

A notorious example of LKM is knark. Once the knark is compiled and loaded to the intrusion host, the system call table is changed to change the operating system behavior. The system call table is resident in the kernel space and is basically an entry for user-level programs to access the operating system. In the second part of the Manual, most Unix systems provide the formal definition of syscils. Once the kernel runs as a user space, the OS sends all the commands and call images running on the command line to the system call table. Therefore, when knark changes the system call table, it also changes the execution of user commands. Knark has changed the following important system calls.

* Getdents-get the contents of the directory (that is, files and subdirectories) in the target path ). By modifying this call, knark can hide files and directories in user programs.

* Kill-sends a signal to a process, usually killing the process. The modified call will use useless signal 31 and trigger the setting process to the "hidden" status. When a process is in the hidden state, its records in/proc are deleted, thus achieving stealth of ps commands. Signal 32 is used to unlock the hidden state.

* Read-read the content of the target file. Knark uses this call to hide the connection of intruders to netstat.

* Ioctl-changes the file and device status. By modifying this call, knark can hide the mixed bits of the NIC and insert a function for hiding the file in the call.

* Fork-derives a new process. The knark modification is used to hide all child processes derived from a hidden parent process.

* Execve-execute a program. It is called every time you enter a command in the command line. Once this call is hijacked, the kernel module can control the selection and running of commands. Knark allows intruders to direct one program to another, just like a symbolic connection, without any evidence. After knark controls execve, any program you want to execute may be a substitute for intruders.

* Settimeofday-set the system time. Knark is used to monitor the specified time. When one of these scheduled times is sent to this system call, knark can trigger some management tasks or immediately grant the root user and group id to the current user. In this way, the root permission is directly obtained without changing to the suid shell.

Because system calls are changed, the functions of those management tools are also changed. Netstat will never report the network adapter's hybrid mode, and connections from specific locations will also be hidden. The ps and top commands do not report hidden processes because/proc has no information. Ls skips hidden files and directories. All of this is because such tools rely on the operating system to provide information, and intruders can report false intelligence to requests from the user space after controlling the operating system, without modifying netstat, ps, the binary files of the top and ls programs. Therefore, file system verification tools such as tripwire will be ineffective and cannot guard against the redirection function of knark. If the hacker connects hackme to cat, each time the cat is called, hackme is actually executing. In this way, cat is retained on the system, and the md5 verification code is not changed, but the execution function is changed.

Even worse, uploading a new tool to a host hacked by knark does not help. Even trusted tools use system calls, so they become untrusted. At present, it is impossible to bypass intruders at the kernel level unless we also enter the kernel space. Based on this, I developed a tool to check whether the system has installed malicious LKM.

As we did not mention before, lsmod will report that the knark. o module is loaded. Unfortunately, intruders can easily erase this information. Knark also includes another LKM called modhide, which can hide itself and the previous module. Once the module is hidden, it cannot be uninstalled without restarting the machine, and there is no simple method to detect the module loading. All related information is lost. As mentioned earlier, all the features of knark make it the ultimate secret weapon.

 

[1] [2] Next page