Shulou(Shulou.com)06/03 Report--

The traditional Rootkit is a more insidious backdoor than an ordinary backdoor. It achieves its goal mainly by replacing system files, which makes it more hidden and makes detection more difficult. Traditional Rootkit is mainly aimed at Unix platform, such as Linux, AIX, SunOs and other operating systems. Some Rootkits can replace DLL files or change the system to * Windows platform. Rootkit does not allow you to obtain permissions directly. On the contrary, it is a measure to protect permissions only after you have obtained permissions through various methods. After we have obtained the root permissions of the system (root permissions, that is, root permissions, is the highest permission of the Unix system), Rootkits provides a set of tools to build backdoors and hide tracks, so as to allow * * users to retain their permissions.

Traditional Rootkit to Unix *

How does RootKits implement the back door? In order to understand the Rootkits backdoor, it is necessary to first understand the basic workflow of Unix. When we visit Unix (whether locally or remotely logged in), the / bin/login program runs, and the system collects and checks the user's account and password through / bin/login. Rootkits replaces the / bin/login of the system with a / bin/login with the root permission backdoor password, so that the user can enter the system by entering the root permission backdoor password. Even if the administrator changes the original system password or clears the password. We can still log in as root using the backdoor password. After breaking into the Unix system, * * users usually carry out a series of * * actions, such as installing sniffers to collect important data, and some system files in Unix will monitor these actions, such as ifconfig. Rootkit will not be defeated, of course, it will also replace these system files, such as login, ifconfig,du,find,ls,netstart,ps and so on. Due to the space problem, the functions of these system files are not listed one by one, and interested readers can find them themselves. now Rootkit has a lot of tools, which basically contain some processed system files to replace the original system files, such as tOmkit and some Rootkit is more excellent.

Defense measures: Rootkit is so terrible that you have to guard against it. In fact, the most effective defense method is to check the integrity of important system files on a regular basis. There are many such tools, such as Tripwire is a very good file integrity check tool. Once you find that you are suffering from Rootkit***, you must completely reinstall all system files, components, and programs to ensure security.

At this point, the war seems to be over, but the scarier Rootkit has not yet appeared, which is kernel-level Rootkit. In most operating systems (various Unix and Windows), the kernel is the most basic component of the operating system, which controls access to network devices, processes, system memory, disks, and so on. For example, when you open a file, a request to open the file is sent to the kernel, which is responsible for getting the bits of the file from the disk and running your file browsing program. Kernel-level Rootkit gives people complete control over the underlying layer of the system. * users can modify your kernel, and most kernel-level Rootkit can perform redirection, that is, intercept the order to run a program, redirect it to the program selected by the * * user, and run the program. In other words, the user or administrator wants to run program A, and the modified kernel pretends to execute A, but actually executes program B.

Kernel-level Rootkit to Unix *

Unlike traditional Rootkit, the bin/login of Unix in kernel-level Rootkit*** is not modified, but all requests to execute / bin/login (which will be generated when logging into the system) are redirected to the hidden file / bin/backdoorlogin created by * *, so that it will not work when system administrators use methods to detect traditional-level Rootkit (such as using software such as tripwire to check file integrity). Because / bin/login has not been changed. By the same token, other system programs are also rescheduled so that your operation is actually carried out according to the wishes of the person.

Kernel-level Rootkit not only makes "perform redirect" settings, but also has a lot of supporting files hidden. Traditional Rootkit achieves file hiding by replacing ls programs, while kernel-level Rootkit deceives ls programs by modifying the kernel, which is more insidious. In addition, kernel-level Rootkit can also hide processes and networks, and users will not get real system status reports.

Implementation idea: according to the type of system, people have different ways to modify the kernel. The easiest way to modify the kernel on N Unix systems is to use the function of the loaded kernel module (LKM) of the system itself. Therefore, most kernel-level Rootkit provides new functions by dynamically updating the kernel using LKM, and the newly added modules extend the kernel. At the same time, you have full access to the kernel and everything else that uses it.

Therefore, many kernel-level Rootkit are implemented through LKM. Installing kernel-level Rootkit implemented through LKM is simple. For example, to install Knark kernel-level Rootkit on Linux, you only need a * * user with root permission to enter the command: insmod knark.o. After the module is installed, it is waiting for us to enter the command. Even better, the whole process does not need to be restarted. Rootkit implemented through LKM is very popular on Unix. We also often apply LKM patches to the windows platform * * windows.

Kernel-level Rootkit instance

Now that there are a large number of kernel-level Rootkit available, just choose some of the more powerful ones to discuss with you.

Kernel-level Rootkit:Knark on linux

Knark has a variety of standard kernel-level Rootkit functions, including performing redirects, file hiding, process hiding and network hiding. In addition, there are many more enjoyable features, such as:

1. Remote execution: we can send a command over the network to the machine running Knark. The source address is fake, and the command is sent to UDP port 53 to make it look like DNS traffic. We can use this feature to upgrade Knark, delete system files or anything we want to do.

2. Task *: when a process is running on the system, it always has permissions related to UID and valid UID (EUID). In addition, the process also has file and directory access related to the file system UID (FSUID). The task * * capability of Knark can change processes UID,EUID and FSUID in real time. The process suddenly has new permissions without stopping the movement.

3. Hide promiscuous mode: like normal RootKit, * * users will also run sniffers on the victim's machine. We can hide the sniffer with file hiding and process hiding. However, the Ethernet card will be set to promiscuous mode, and the administrator can check that Knark has modified the kernel to hide the mixed mode of the network card, which will make sniffing more secret.

4. Real-time process hiding: Knark can hide a running process. By sending signal 31 to a process, the process disappears but is still running. The command kill-31 process_id prevents the kernel from reporting any information about this process. Neither the use of the ps nor the lsof command can show the process while the process is running.

5, kernel module hiding: the lsmod command in Linux can list the LKM currently installed on the machine, so we naturally do not want the administrator to see the Knark module, so Knark contains a separate module modhide,modhide to hide Knark and itself. In this way, when we use a Knark*** system, we first make an insmod for Knark.o and then an insmod for modhide.o. So that no matter who runs the lsmod command, these modules will not be discovered.

Second, kernel-level Rootkit:Adore on another Linux

Like Knark, Adore is a LKM RootKit for Linux, which includes standard kernel-level Rootkit features such as file hiding, process hiding, network hiding, and kernel module hiding. We only talk about Adore because it also has a very powerful feature: a built-in root backdoor.

The root permission backdoor of Adore allows us to connect to the system and get the command shell of root permission. This function is very straightforward, and Adore skillfully includes this function in the kernel module. This trick is very difficult to break because administrators do not see any signs of files, processes, or listening on network ports.

Defense: the fundamental way to defend against kernel-level Rootkit is not to let people get the fundamental permissions of your machine's system (root in Unix and admin in windows), but this looks like nonsense. Currently, there is no absolute defense system against kernel-level Rootkit.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.