Backdoor technology and Linux LKM rootkit detailed

2010-01-15 10:32 Chinaitlab Chinaitlabfont Size:T | T

In this article, we'll look at a variety of backdoor technologies, especially Linux's loadable kernel modules (LKM). We will find that the lkm backdoor is more complex, more powerful, and less discoverable than the traditional backdoor procedures. Knowing this, we can make our own lkm-based rootkit program, mainly in the TCP/IP layer, because we believe this is the best place to hide the backdoor in front of the system administrator.

AD:2014WOT Global Software Technology Summit Beijing Station course video release

Summary: In this article, we will see a variety of backdoor technologies, especially Linux loadable kernel modules (LKM). We will find that the lkm backdoor is more complex, more powerful, and less discoverable than the traditional backdoor procedures. Knowing this, we can make our own lkm-based rootkit program, mainly in the TCP/IP layer, because we believe this is the best place to hide the backdoor in front of the system administrator.

Preface

In some hacker organizations, rootkits (or backdoor) are a topic of great interest. Various rootkits have been developed and published on the Internet. Among these rootkits, LKM is particularly concerned because it is a modular technology that leverages modern operating systems. Running as part of the kernel, this rootkit will become more powerful and less detectable than traditional technology. Once installed and run to the target machine, the system will be fully controlled in the hands of hacker. Even system administrators cannot find traces of security breaches because they can no longer trust their operating systems.

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

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

The purpose of the backdoor is even when the system administrator attempts to compensate for the vulnerability of the system can also give the hacker system access rights. Backdoor programs enable Local users to get root permissions to do this: Set UID program, System Trojan, cron backdoor.

1. Set the UID program. Hackers in some file systems to put some Setup UID script program. They will become root whenever they execute the program.

2. System Trojan program. Hackers replace some system programs, such as the "Login" program. Therefore, as long as certain conditions are met, those programs will give the hacker the highest authority.

3. Cron Backdoor. Hackers add or modify some tasks in cron, and they can get the highest privileges when the program runs at a particular time.

Backdoor programs give remote users the highest access rights to do this: ". Rhost" file, SSH authentication key, bind shell, Trojan service program.

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

2. SSH authentication key. The hacker puts his own public key in the SSH configuration file "Authorized_keys" of the target machine, which he can use to access the machine without requiring a password.

3. Bind Shell. The hacker binds a shell to a specific TCP port. Anyone who telnet to this port can get an interactive shell. More sophisticated this way the backdoor can be based on UDP, or not connected TCP, or even the ICMP protocol.

4. trojaned Service Program. Any open service can become a Mumalai to provide access to remote users. For example, use the INETD service to create a bind shell on a specific port, or to provide access through the SSH daemon.

After the intruder implants and runs the backdoor, he will find some way to make a good joke with the system administrator. This mainly involves two aspects: how to hide his files and how to hide his process.

In order to hide the file, the intruder needs to do the following: replace some system commands such as "LS", "du", "fsck". At the bottom, they mark some areas of the hard drive as bad blocks and put their files there. Or if he's crazy enough, he'll put some files in the boot block.

In order to hide the process, he can replace the "PS" program, or modify argv[] to make the program look like a legitimate service program. It is interesting to change a program to an interrupt driver, it will not appear in the process table.

LKM-Do you have anything more to fart than this?

We've seen some conventional techniques. Now the question is: Can the system administrator find them? In fact, a good system administrator can easily find out the%99 in them. The problem is that intruders must modify or create some important files. If the system administrator saves a copy of the "tripwire" database, these can be used to determine the existence of a security risk. By browsing the file system you can remove the SUID program, ". rhosts" files, and so on.

On the contrary, using lkm we can effectively break through these limits. First, we don't have to modify or create any files in the important system directory. We can put the LKM program in the/TMP or/var/tmp directory, the general system administrator will not monitor these directories. Second, we can hide everything we want, like files, processes, and network connections. Because to get this information, the user must rely on system calls.

So we can modify the kernel structure, we can replace the original system call with our own function. Finally, we can even attack or modify the TCP/IP protocol stack and fool the system kernel! In the following sections, we will show you how to leverage these mechanisms and how to implement them.

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

The first idea is that we do not run any process on the target machine to wait for the connection, we create a function in the TCP/IP stack to replace it. Whenever a particular UDP or TCP packet is accepted, the kernel checks the package to determine whether it is the specified special package. If so, the kernel will derive a process to execute the command. We can use any protocol package that the kernel can support.

Now let's implement it. In the kernel, each protocol registers itself in *inet_protocol_base and *inet_protos[max_inet_protos] hashes. When the system is initialized, all supported protocols are inet_protocol_base registered. They were added to the hash table of the Inet_protos. Whenever an IP packet is reached, the kernel checks the hash table for appropriate processing functions and system calls. We are hack at this point. We will replace the processing function of the original protocol with our handler function. Therefore, we can intercept the packet and analyze it. If it is what we need, we will carry out our orders. If not, only the original function needs to be called.

The reason we deal with both TCP and UDP is that if there are some firewalls there, UDP may not be able to pass through. Therefore, we only need to send a source address to a spoofed packet to the destination machine. In addition, for TCP packets, it does not require the use of a SYN bit. In fact, our client program now uses an ACK packet.

The second idea is more interesting. If a target has a Web service on its machine and a firewall that allows only web traffic, how do we get through it? Can we get an interactive shell? The answer is yes. Here's how:

____________ _________________________

| Attackers | | Web Server |

| | | <=======> 53333 |

|__________| |_______________________|

| |

| |

|____________________________________|

1025 ==> or 1025 <== 80

Suppose we have a bind shell backdoor on the Web server and listen on port 53333 (which can be done with the first method) now we need to redirect the attacker's traffic to the Web server from port 80 to port 53333. Traffic from port 53333 to attacker must be changed to 80 ports.

Implementation section. Changing the received packet is very easy, we can borrow the first lkm idea-whenever we all check the incoming TCP packet if necessary we modify its destination port. This is a bit difficult to change the package that was sent. Because the implementation of the TCP/IP protocol stack involves some of the underlying static functions of the Linux kernel. It is not easy to displace (but is possible, see appendix for details). We are using firewalls that are compiled into the kernel when most of them are released. Each incoming package, the forwarded package, or the sent package must pass through the firewall. And the firewall function can be loaded into the kernel dynamically! We use the system Export function Register_firewall () to insert our own rules before the system firewall rules. If we find some packets from the 53333 port, we can automatically change it to 80.

Another detail about this implementation is that whenever we change the packet, we have to recalculate the checksum. The more interesting thing is that we can listen to the network traffic on the Web server and some other machines, and we can see their differences. Sniffer on other machines look like normal web traffic, but sniffer on the Web server is a useless traffic record. See appendix for specific details.

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

1. Hide files. Like these commands such as "LS", "Du" uses sys_getdents () to obtain directory information. So the LKM program must filter these outputs to achieve the purpose of hiding files.

2. Hide the process. In the implementation of Linux, the information of the process is mapped to the/proc file system. Our job is still to capture sys_getdents () calls that are marked as invisible in the process chain list. The usual technique is to set the signal marker for a task to a number of unused semaphores, such as 31, which is an example.

3. Hide the network connection. Similar to the hidden process, in this case we are going to hide some files that include/proc/net/tcp and/PROC/NET/UDP. So we change Sys_read (). Whenever you read these two files that contain a matching string, the system call will not declare that it is being used.

4. redirect the executable file. Sometimes intruders may need to replace the system's binaries, like "login", but do not want to change the original file. He can intercept Sys_execve (). Therefore, whenever the system attempts to execute the "login" program, it will be redirected to another program given by the intruder.

5. Hide Sniffer. Here we mean hiding the clutter mode of the network interface. Here we are going to replace the Sys_ioctl ().

6. Communication with LKM. The hacker has already installed his lkm well. Now he needs to tell the kernel to hide the other files. What should he do? We know that switching from the user state to the mindset is usually done through system calls, so we have to modify some system calls.

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

7. Hide the lkm itself. An excellent lkm program must be well hidden by itself. The lkm in the system is connected by a one-way list, in order to hide the lkm itself we have to remove it from the list so that lsmod such a command cannot show it.

8. Hide the symbol table. The functions in the usual lkm will be exported so that other modules can use it. Because we are intruders, it is necessary to hide these symbols. Fortunately, there is a macro available for us to use: "Export_no_symbols". Put this macro at the end of the lkm to prevent the output of any symbol.

Experience and conclusions

Being a lkm program is a very interesting and dangerous thing to do. The interesting thing is that you can do what you want to do in the kernel of the system. But this is also very dangerous, it can make your service into chaos, destroy your data, and can do anything weird in your system. Our experience is: After a few days after the installation of the LKM program our network layer does not work, only five minutes of work will be re-started once; Whenever a packet is sent, like these applications Telnet, Netscape, Pine will produce a core dump; Restart immediately after installing the LKM program. So, as the title says, the consequences are at your own risk!

It's worth mentioning that writing a lkm program gives you a better idea of how the system works. For example, the/proc file system has very good features. Because the LKM program works in kernel space, debugging the LKM program becomes more difficult than the general program. Use the "PRINTK" function to solve some problems. But that's not the best way to fix it. By registering the data structure of our files and directories in the/proc file system, we can access information about the kernel space at any time. We can even modify the memory by writing this file, although this is not generally recommended.

From experience, it is obvious that the LKM program can be installed on Linux, and once the system is compromised and the LKM rootkit program is installed, it becomes difficult to find. Because even the operating system can not be trusted. If the machine does not allow shutdown, the only way to discover intruders is by analyzing sniffer results on other machines on the network. Alternatively, use a different operating system to monitor the hard drive. All of these two methods are hard to do because you don't know what you're looking for. Therefore, the best security measures are to prevent attackers from invading the system.

Backdoor technology and Linux LKM rootkit detailed