Backdoor technology and Linux LKM Rootkit

In this article, we will see a variety of backdoor technologies, especially Linux's loadable kernel modules (LKM ). We will find that LKM backdoors are more complex and powerful than traditional backdoors, making them more difficult to detect. After knowing this, we can create our own LKM-based Rootkit program, mainly reflected in the TCP/IP layer, because we believe this is the best place to hide backdoors in front of system administrators.

Preface

In some hacker organizations, Rootkit (or backdoor) is a topic of great interest. Different rootkits are developed and published on the internet. Among these rootkits, LKM is particularly concerned because it uses the module technology of modern operating systems. As part of the kernel, such Rootkit will become more powerful and more difficult to detect than traditional technology. Once installed and run on the target machine, the system will be completely controlled in hacker's hands. Even the system administrators could not find any trace of security risks because they could no longer trust their operating systems.

This article and some of the powerful LKM programs we have developed are based on Linux Kernel 2.2.x. Our goal is to hide as many footprints as possible.

In the next section, we will introduce the existing backdoor technology, compare it with the LKM technology, and finally discuss the design and implementation of my LKM program.

The purpose of the backdoor program is to grant the hacker system access permission even when the system administrator tries to make up for the system vulnerability. The backdoor program allows the local user to obtain the root permission in this way: Set the uid program, system Trojan program, and cron backdoor.

1. Set the uid program. Hackers put uid script programs in some file systems. Whenever they execute this program, they will become root.

2. System Trojan program. The hacker replaces some system programs, such as the "login" program. Therefore, as long as certain conditions are met, those programs will give hackers the highest permissions.

3. Cron backdoor. A hacker adds or modifies some tasks in cron and runs the program at a specific time to obtain the highest permissions.
The backdoor program can give the remote user the highest access permission: ". rhost" file, ssh authentication key, bind shell, and Trojan service program.

1. ". rhosts" file. Once "++" is added to a user's. rhosts file, anyone can use this account to log in without a password.

2. ssh authentication key. A hacker puts his own public key in the target machine's ssh configuration file "authorized_keys". He can use this account to access the machine without a password.

3. Bind shell. A hacker binds a shell to a specific tcp port. Anyone can telnet this port to obtain the interactive shell. More sophisticated backdoors can be based on udp, unconnected tcp, or even icmp.

4. Trojaned service program. Any opened service can be used as a Trojan to provide remote users with access permissions. For example, use the inetd service to create a bind shell on a specific port, or use the ssh daemon to provide access.

After intruders implant and run Backdoor programs, they will find some methods to joke with the system administrator. This involves two aspects: how to hide his files and how to hide his processes.

To hide files, intruders need to do the following: replace some common system commands such as "ls", "du", "fsck ". At the underlying level, they mark some areas in the hard disk as bad blocks and place their files there. Or if he is crazy enough, he will put some files into the boot block.

To hide a process, he can replace the "ps" program, or modify argv [] to make the program look like a legal service program. Interestingly, if you change a program to an interrupt driver, it will not appear in the process table.

LKM-is there anything worse than this?

We have seen some conventional technologies. Now the question is: can the system administrator find them? In fact, a good system administrator can easily find % 99 of them. The problem is that the attacker must modify or create important files. If the system administrator saves a copy of the "tripwire" database, you can determine the existence of security risks. By browsing the file system, you can remove the suid program and the ". rhosts" file.

Instead, we can effectively break through these limits using LKM. First, you do not have to modify or create any files in an important system directory. We can place the LKM program in the/tmp or/var/tmp directory. Generally, the system administrator will not monitor these directories. Second, we can hide anything we want, such as files, processes, and network connections. To obtain this information, you must rely on the system call.

Therefore, we can modify the kernel structure and replace the original system call with our own functions. Finally, we can even attack or modify the TCP/IP protocol stack and fool the system kernel! The following section describes how to use these mechanisms and implementation methods.

Our LKM program is mainly implemented based on Linux Kernel 2.2.x and TCP/IP, because an excellent backdoor program will certainly give remote users access to the system. Opening a port on the target machine makes it very easy to run a service. We need to hide ourselves as much as possible.

The first idea is that we don't run any process on the target machine to wait for the connection. We create a function in the TCP/IP protocol stack to replace it. Whenever a special udp or tcp packet is received, the kernel checks the packet to determine whether it is a specified special packet. If yes, the kernel will derive a process to execute the command. We can use any protocol packages supported by the kernel.

Now let's implement it. In the kernel, each protocol registers itself in * inet_protocol_base and * inet_protos [MAX_INET_PROTOS] hash. When the system is initialized, all supported protocols will be registered with inet_protocol_base. They are added to the inet_protos hash table. No matter when an IP packet is reached, the kernel will check the hash table and find the corresponding processing function and system call. We will perform hack on this point. We will use our processing functions to replace the processing functions of the original protocol. Therefore, we can intercept data packets and analyze them. If it is what we need, we will execute our command. If not, you only need to call the original function.

The reason we simultaneously process TCP and UDP is that if there are some firewalls, UDP may not pass through. Therefore, we only need to send a spoofed data packet from the source address to the target machine. In addition, TCP packets do not need to use SYN bits. In fact, our customer program uses the ACK package.

The second idea is more interesting. If a target machine has a WEB service and a firewall that only allows WEB communication, how can we pass through it? Can we get an interactive shell? The answer is yes. The method is as follows:

Assume that we have bound a bind shell backdoor to the web server and listened to port 53333 (the first method can be used) now we need to redirect the attacker's traffic to the web server from port 80 to port 53333. The traffic from Port 53333 to the attacker must be changed to port 80.

Implementation. It is easy to change the received packet. We can use the first LKM idea-we will check the incoming tcp packet whenever necessary to modify its target port. It is a little difficult to change the package. The TCP/IP protocol stack involves some underlying static functions of the Linux kernel. It is not easy to replace (but it is possible. For details, see the appendix ). We use most of the firewalls compiled into the kernel during release. Each incoming packet, forwarded packet, or sent packet must pass through the firewall. And firewall functions can be dynamically loaded into the kernel! We use the system export function register_firewall () to insert our own rules before the system firewall rules. If we find some packages from the 53333 port, we can automatically change it to 80.

Another detail about this implementation is that whenever we change data packets, We have to re-calculate the checksum. What's more interesting is that we can monitor network traffic on web servers and some other machines. We can see their differences. Sniffer on other machines looks like normal web traffic, but sniffer on web servers is useless traffic records. For details, see the appendix.

Now let's talk about how to intercept system calls. To hide the footprints of intruders, files, processes, and network connections must be hidden. Because this information can be obtained from special system calls, we can receive system calls of interest.

1. Hide the file. Such commands as "ls" and "du" use sys_getdents () to obtain directory information. Therefore, the LKM program must filter these outputs to hide files.

2. Hide the process. In Linux, process information is mapped to the/proc file system. Our job is to capture sys_getdents () calls and mark them as invisible in the process linked list. The common method is to set the signal flag of a task to unused semaphores. For example, 31 is an example.

3. Hide network connections. Similar to the hidden process, in this example, we hide some files including/proc/net/tcp and/proc/net/udp. So we changed sys_read (). Whenever you read these two files that contain matching strings, the system call will not declare that you are using it.

4. Redirect the executable file. Sometimes, intruders may need to replace the system's binary files, such as "login", but do not want to change the original file. It can intercept sys_execve (). Therefore, whenever the system tries to execute the "login" program, it will be redirected to another program specified by the intruder.

5. Hide sniffer. Here we refer to the miscellaneous mode for hiding network interfaces. Here we want to replace sys_ioctl ().

6. Communicate with LKM. The hacker has installed his LKM properly. Now he needs to tell the kernel to hide other files. What should he do? We know that switching from user mode to mentality is usually done through system calls, so we must modify some system calls.

For example, we will intercept sys_settimeofday (). When a specified parameter is passed, our system call will do something appropriate for us.

7. Hide the LKM itself. An excellent LKM program must hide itself well. The LKM in the system is connected by a one-way linked list. To hide the LKM itself, we must remove it from the linked list so that commands like lsmod cannot display it.

8. Hide the symbol table. Generally, functions in LKM are exported so that other modules can use them. Because we are intruders, it is necessary to hide these symbols. Fortunately, there is a macro available for us: "EXPORT_NO_SYMBOLS ". Putting this macro at the end of LKM can prevent the output of any symbol.

Experience and conclusion

Creating an LKM program is very interesting and dangerous. Interestingly, you can do what you want in the system kernel. But this is also very dangerous. It can bring your services into chaos, break your data, and do anything weird in your system. Our experience is: after installing the LKM program for a few days, our network layer does not work, and it only takes five minutes to restart. Whenever we send packets, such as telnet, netscape, pine will generate core dump, and immediately restart after the LKM program is installed. So, as the title says, the consequences are at your own risk!

It is worth mentioning that you can better understand how the system works by writing an LKM program. For example, the/proc file system has good features. Because LKM programs work in the kernel space, debugging LKM programs becomes more difficult than general programs. The "printk" function can solve some problems. But this is not the best solution. By registering the data structure of our files and directories in the/proc file system, we can access the kernel space information at any time. We can even modify the memory by writing this file, although this is generally not recommended.

From the perspective of experience, it is obvious that LKM programs can be installed on Linux. Once the system is cracked and LKM Rootkit programs are installed, this becomes very difficult to find. Because even the operating system cannot be trusted. If the machine cannot be shut down, the only way to discover intruders is to analyze the sniffer results on other machines on the network. Alternatively, use another operating system to monitor the hard disk. All these two methods are difficult to do, because you don't know what you are looking. Therefore, the best security measure is to prevent attackers from intruding into the system.

1. Analysis and Prevention of Rootkit intrusion tool Knark
2. The root cause is to completely remove the rootkit.