Capable of loading the kernel module: new area of Intrusion Response Analysis

Article title: loadable kernel module: new area of intrusion response analysis. 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.
　　
　　 Preventive methods
Blocking LKM corruption is obviously the best solution. We have several ways to prevent lkm in advance. We can prevent most malicious lkm by protecting the system call table. We can construct a simple lkm, timed or monitoring system call table when loading other modules. If the system call table changes, you can notify the system administrator to change the call table back to the original value. The following example works well on linux 2.2 and 2.4. If your machine has more than one processor, use the following command to compile: gcc-D _ SMP _-c syscall_sentry.c. For a single processor, remove-D _ SMP. After compilation, use insmod to load.
　　
/*
* This LKM is designed to be a tripwire for the sys_call_table.
*/
# Define MODULE_NAME "syscall_sentry"
/* This definition is the time between periodic checks .*/
# Define TIMEOUT_SECS 10
# Define MODULE
# Define _ KERNEL __
# Include
# Include
# Include
# Include
# Include
# Include
# Include
# Include
# Include
/* This function is a simple string comparison function */
Static int mystrcmp (const char * str1, const char * str2)
{
While (* str1 & * str2)
If (* (str1 ++ )! = * (Str2 ++ ))
Return-1;
Return 0;
}
/* This function builds a timer struct for versions of linux
* Less than linux 2.4. It is used to set a timer
*/
# If LINUX_VERSION_CODE <KERNEL_VERSION (2, 4, 0)
/* Initializes a timer */
Void init_timer (struct timer_list * timer)
{
Timer-> next = NULL;
Timer-> prev = NULL;
}
# Endif
/* This is our timer */
Static struct timer_list syscall_timer;
/* This is the system's syscall table */
Extern void * sys_call_table [];
/* This is the saved, valid syscall table */
Static void * orig_sys_call_table [nr_syscils];
/* This function is needed to protect yourself */
Static unsigned long (* orig_init_module) (const char *, struct module *);
/* This function checks the syscallfor changes
* And changes them back to the original if it has
* Been changed.
*/
Static int check_syscils (void)
{
Int I;
/* Add a new timer for our next check */
Del_timer (& syscall_timer );
Init_timer (& syscall_timer );
Syscall_timer.function = (void *) check_syscils;
Syscall_timer.expires = jiffies + TIMEOUT_SECS * HZ;
Add_timer (& syscall_timer );
For (I = 0; I <nr_syscils-1; I ++)
{
If (orig_sys_call_table [I]! = Sys_call_table [I])
{
Printk (KERN_INFO "SysCallSentry-sys_call_table has been
Modified in entry % d! ", I );
Sys_call_table [I] = orig_sys_call_table [I];
}
}
Return 1;
}
/* Check sys_call_table anytime a new module is loaded .*/
Static int long sys_init_module_wrapper (const char * name, struct
Module * mod)
{
Int I;
Int res = (* orig_init_module) (name, mod );
For (I = 0; I <nr_syscils-1; I ++)
{
If (orig_sys_call_table [I]! = Sys_call_table [I])
{
Printk (KERN_INFO "SysCallSentry-sys_call_table has been
Modified in entry % d! ", I );
Sys_call_table [I] = orig_sys_call_table [I];
}
}
Return res;
}
/* Module Init Code */
Static int init_module (void)
{
Int I;
Printk (KERN_INFO "SysCallSentry Inserted ");
/* Initiate the periodic timer */
Init_timer (& syscall_timer );
/* Save the old values of the sys_call_table */
Orig_init_module = sys_call_table [SYS_init_module];
/* Wrap the init_module syscall. This will check to see
* If any callhave been altered when a new module loads.
*/
Sys_call_table [SYS_init_module] = sys_init_module_wrapper;
For (I = 0; I <nr_syscils-1; I ++)
{
Orig_sys_call_table [I] = sys_call_table [I];
}
/* Start our first check */
Check_syscils ();
Return (0 );
}
/* Module Cleanup Code */
Static void cleanup_module (void)
{
/* Return system status to the original */
Sys_call_table [SYS_init_module] = orig_init_mo