Use gdb in Linux to check the kernel rootkit

 

The technical principles involved in this article are not new, and there is no special value for researchers. However, it is a new method for engineering personnel to respond to emergencies.

Understanding attack vectors

The kernel rookit is usually targeted at system calls for two reasons:

A. in kernel mode hijacking, system calls can control the entire system at a small cost, without requiring too many things;

B. Most functions at the application layer are encapsulated in different forms by one or more system calls. Modifying system calls means that all functions at the upper layer will be spoofed;

In kernel-2.4.27, there are more than 230 system calls, And in kernel-2.6.9, there are more than 290 system calls. The number of system calls depends on the kernel version. The complete system call list can be obtained in the/usr/include/asm/unistd. h header file.

In addition, it should be noted that intruders do not change all system calls, but are useful to replace some of them. As shown in table 1, these system calls can be monitored by system administrators and intrusion detection systems (OS kernel-level IDS). You can use man commands to get a complete description of each system call.

System call name Short description ID --------------------------------------------------------------------------------------- sys_read used for reading from files 3 sys_write used for writing to files 4 sys_open used to create or open files 5 sys_getdents/sys_getdents64 used to list a content of directories(also /proc) 141/220 sys_socketcall used for managing sockets 102 sys_query_module used for querying loaded modules 167 sys_setuid/sys_getuid used for managing UIDs 23/24 sys_execve used for executing binary files 11 sys_chdir used to change the directory 12 sys_fork/sys_clone used to create a child process 2/120 sys_ioctl used to control devices 54 sys_kill used to send signal to processes 37

Note that the system call numbers in the preceding table are all for kernel-2.4.18-3.

All examples in this article are tested on Redhat7.3 kernel-2.4.18-3. We can also use similar steps in other versions, including the latest 2.6.x, the difference may be in some internal structures of 2.6. For example, the address of the system call table is originally included in the system_call routine of the system call processing routine and is now changed to the syscall_call function.

Change System Call table

The current system call address is saved in the system call table, which is located in the memory space reserved by the operating system for the kernel (the virtual address is up to 1 GB ), the system call entry address is stored in the same order as/usr/include/asm/unistd. h.

Before the 0x80 Soft Interrupt occurs, the corresponding system call number is pushed to the eax register. For example, when sys_write is called, the corresponding system call ID: 4 is pushed to eax.

The first method used by intruders is to change the system call address in the system call table, so that when a system call occurs, the system jumps to the function compiled by the attacker for execution. By observing the system call entry address in the system call table, we can easily detect such attacks using gdb.

The original system call address is specified in the kernel compilation phase and will not be changed. By comparing the original system call address and the system call address in the current kernel state, we can see whether the system call has been changed. The original system call address is written into two files during compilation:

A. System. map this file contains all the symbolic addresses and System calls;

B. the kernel image file vmlinux-2.4.x that is first read into the memory during system initialization;

Vmlinux-2.4.x files are usually stored in the/boot directory in a compressed format, so you must extract the file before comparison, another problem is: the premise of our comparison is to assume that the system. map and vmlinuz image are not modified by intruders. Therefore, it is safer to create a trusted copy of the two files and create the md5 hash of the files when the system is clean.

The original Article also lists a kernel module [gcc-c scprint. c-I/usr/src/'uname-R'/include/] use this module to print the system call address and automatically write syslogs. This allows real-time comparison.

In most cases, the kernel is changed only after system initialization, the change occurs after the module loaded with rootkit or the on-the-fly kernel patch implanted with direct read/dev/kmem. In general, rootkit does not change vmlinuz and system. map these two files, so print the symbolic addresses in these two files to know the original system call address, the system call address currently running in the system (may be changed) it can be obtained from the kcore file in/proc. You can obtain the result by comparing the two files.

1. First, find the address of the system call table:

[root@rh8 boot]# cat System.map-2.4.18-13 | grep sys_call_table c0302c30 D sys_call_table

2. Run the nm command to print all the symbolic addresses in the image file that has not been strip:

[root@rh8 boot]# nm vmlinux-2.4.18-13 | grep sys_call_table c0302c30 D sys_call_table

You can use gdb to print out all the system call entry addresses, which are defined in the entry. S file of the kernel source code. For example:

Entry 0 (0xc01261a0) is sys_ni_syscall System Call entry 1 (0xc011e1d0) is sys_exit System Call entry 2 (0xc01078a0) is sys_fork system call # gdb/boot/vmlinux-2.4. * (gdb) x/255 seconds passed <sys_call_table>: 0xc01261a0 0xc01078a0 0xc013fb70 hour <sys_call_table + 16>: 0xc013fcb0 0xc013f230 hour passed <sys_call_table + 32>: 0xc013f180 0xc014cb10 0xc014c670 0xc0107940 0xc030260< sys_call_table + 48>: 0xc013e620 0xc011f020 0xc014bcd0 0xc013e9a0...

You can also print the system call address by using the system call name:

(gdb) x/x sys_ni_syscall 0xc01261a0 <sys_ni_syscall>: 0xffffdab8 ((gdb) x/x sys_fork 0xc01078a0 <sys_fork>: 0x8b10ec83

 

To print the system call address in the current running system, we must add two parameters to gdb:

A. the first parameter is the kernel image file vmliux-2.4.x

B. The second parameter is the/proc/kcore binary file.

#gdb /boot/vmlinux-2.4.* /proc/kcore (gdb) x/255x 0xc0302c30 0xc0302c30 <sys_call_table>: 0xc01261a0 0xc011e1d0 0xc01078a0 0xc88ab11a <<-- 0xc0302c40 <sys_call_table+16>: 0xc013fcb0 0xc013f0e0 0xc013f230 0xc011e5b0 0xc0302c50 <sys_call_table+32>: 0xc013f180 0xc014cb10 0xc014c670 0xc0107940 0xc0302c60 <sys_call_table+48>: 0xc013e620 0xc011f020 0xc014bcd0 0xc013e9a0 ...

We noticed that the address 0xc88ab11a at the end of the first line is obviously abnormal. This is a system call with system call number 3, that is, sys_read (the system call starts from 0 ).

We can say that it is abnormal because its address is higher than 0xc8xxxxxx. Linux uses a 4 GB linear address by default. The maximum 1GB0x00000000-0xffffffff is reserved for the kernel. When a module is inserted into the kernel