Use gdb in Linux to detect the kernel rootkit

Source: Hacker defense

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


[Understanding attack vectors]

The first two paragraphs of nonsense pass directly... it's a waste of feelings -_-!

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 in the application layer are encapsulated in different forms by one or more system calls. Changing system calls means that the upper-Layer
All functions are spoofed;
In kernel-2.4.27, there are more than 230 system calls, while in kernel-2.6.9, there are more than 290 system calls.
The number of calls depends on the kernel version. The complete list of system calls 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 simply replace some of them with useful ones. These system calls
As shown in table 1, they can be monitored by system administrators and intrusion detection systems (OS kernel-level IDS ).
The complete description of each system call.

System call name Short description ID
Bytes -------------------------------------------------------------------------------------------
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 the examples in this article pass the test on Redhat7.3 kernel-2.4.18-3. We can also use other versions including the latest 2.6.x.
Using similar steps, the difference may be some internal structures of 2.6. For example, the address of the system call table is originally included in the System Call
In the system_call processing routine, it is now changed to the syscall_call function.

[Change System Call table]

The current system call address is stored 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 Calling entry address is stored in the same order as in/usr/include/asm/unistd. h, and is incremented by the system call number.

-_-! Given that the original article is a lot of nonsense, I will skip the translation or summarize the translation. If you are interested, you can find a book on the Linux kernel (e. g: ULK2)

Before the 0x80 Soft Interrupt occurs, the corresponding system call number is pushed into the eax register. For example, when sys_write is called, its corresponding system call
ID: 4 is pushed into 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, it jumps to the attacker's own
Write the function to execute. By observing the system call entry address in the system call table, we can easily detect this attack using gdb.
Attacks.

The original system call address is specified in the kernel compilation phase and will not be changed. By comparing the original system call address with the system in the current kernel state
The call address shows 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. kernel image file vmlinux-2.4.x first read into memory during system initialization
Vmlinux-2.4.x files are usually stored in the/boot directory in a compressed format, so you must decompress the file before comparison, another problem is:
The premise of our comparison is that the system. map and vmlinuz image are not modified by intruders, so the safer way is to clean the system
You have created a trusted copy of the two files and created the md5 hash of the files.

The original Article also lists a kernel module [gcc-c scprint. c-I/usr/src/'uname-R'/include/] using this module to print the system.
Call address, and automatically write syslog data, so that real-time comparison can be performed.

In most cases, the kernel is changed only after the system initialization, and the change occurs when the module where the rootkit is loaded or
Insert the on-the-fly kernel patch for direct read/write/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 of the system.
The call address (which may be changed) can be obtained from the kcore file in/proc, and the result can be obtained by comparing the two.

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 a sys_ni_syscall system call.
Entry 1 (0xc011e1d0) is a sys_exit system call.
Entry 2 (0xc01078a0) is a sys_fork system call.

# Gdb/boot/vmlinux-2.4 .*
(Gdb) x/255 0xc0302c30
0xc0302c30 <sys_call_table>: 0xc01261a0 0xc011e1d0 0xc01078a0 0xc013fb70
0xc0302c40 <sys_call_table + 16>: 0xc013fcb0 0xc013f0e0 0xc013f230 0xc011e5b0
0xc0302c50 <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
0xc030260< sys_call_table + 48>: 0xc013e620 0xc011f020 0xc014bcd0 0xc013e9a0
...

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 (System Call starts from 0)

We can say that it is abnormal, but its address is higher than 0xc8xxxxxx. Linux uses a 4 GB linear address by default, with a maximum of 1 GB.
0x00000000-0xffffffff is reserved for the kernel. When a module is inserted into the kernel, The vmalloc function allocates an address space for it,
This address usually starts from 0xc8800000... Is it obvious now?

System Call hijacking]

Unlike the previous method, hijacking does not directly modify the entry address in the system call table, that is, pointing
The jump pointer of each system call, but adds a jump code before the system call to be hooked, so that the execution flow is redirected to
Attackers use their own kernel state functions. The front of these hook system calls usually include call, jmp, and other Assembly commands.

To detect this attack, also use gdb and vmlinux-2.4. * And/proc/kcore parameters, and then disassemble the system call:

# Gdb/boot/vmlinux-2.4. */proc/kcore
(Gdb) disass sys_read
Dump of worker er code for function sys_read:
0xc013fb70 <sys_read>: mov $0xc88ab0a6, % ecx
0xc013fb73 <sys_read + 3>: jmp * % ecx <--
0xc013fb77 <sys_read + 7>: mov % esi, 0x1c (% esp, 1)
0xc013fb7b <sys_read + 11>: mov % edi, 0x20 (% esp, 1)
0xc013fb7f <sys_read + 15>: mov $0xfffffff7, % edi
...

Note that the two commands "mov $0xc88ab0a6, % ecx -- jmp * % ecx" are redirected to other places for execution.

Then let's take a look at the system call commands before being hooked:

# Gdb/boot/vmlinx-2.4 .*
(Gdb) disass sys_read
Dump of worker er code for function sys_read:
0xc013fb70 <sys_read>: sub $0x28, % esp
0xc013fb73 <sys_read + 3>: mov 0x2c (% esp, 1), % eax
0xc013fb77 <sys_read + 7>: mov % esi, 0x1c (% esp, 1)
0xc013fb7b <sys_read + 11>: mov % edi, 0x20 (% esp, 1)
0xc013fb7f <sys_read + 15>: mov $0xfffffff7, % edi
...

See it. It's different.

[Change System Call processing routine]

Intruders may modify some important kernel functions, such as the system_call function, which calls the processing routine.
Respond to the system call requested by the user, find the corresponding entry address in the system call table, and then jump to it for execution. This function
The address of the system call table is saved. What can attackers do? Another piece of memory space where attackers forge their own system calls
Table, and then modify the system call table address in the system_call function to point to it.

The system_call function can be used to find the address of the system call table:

(Gdb) disass system_call
Dump of worker er code for function system_call:
0xc01090dc <system_call>: push % eax
0xc01090dd <system_call + 1>: cld
0xc01090de <system_call + 2>: push % es
0xc01090df <system_call + 3>: push % ds
0xc01090e0 <system_call + 4>: push % eax
0xc01090e1 <system_call + 5>: push