March 7, 2011, 12:26 p.m.
posted by newmy
Knark is a cutting-edge backdoor tool. Technically, it is not just a remote-control/access tool and can wreak serious havoc to any Linux system on which it is installed. Knark is different in that it compromises the Linux kernel, rather than just the user space, and therefore is capable of eluding even trusted detection tools.
Knark can be downloaded at http://www.packetstormsecurity.com. It has two versions: one runs on the Linux 2.2 kernel, and the other runs on the Linux 2.4 kernel. The version of Knark studied in this section will be the newest version designed for the Linux 2.4 kernel, but all of the commands are exactly the same between the two.
Even though Knark hasn't been updated for the 2.6 kernel, that doesn't imply that the 2.6 series is any less (or more) resistant to these types of attacks. In fact, a descendant of Knark, adore-ng, provides much of the same functionality and works with Linux 2.2, 2.4, and 2.6 kernels. It was created by a now-defunct hacking group named Teso. You won't find the tarball on the group's web site, but you can find it on Packet Storm's site: http://packetstormsecurity.com/groups/teso/. You will notice that its configuration and installation resembles Knark. So, if you can install Knark and understand how it works, then you should be on your way to understanding adore-ng.
Kernel root kits are predicated on having root-level access to the victim system. A lot of security can be gained by building monolithic kernels (disabling support for loadable modules) and by implementing strict role-based access controls (such as those provided by SELinux). Yet these features serve to minimize the window of opportunity for installing a root kit. A 2001 article in the online security magazine Phrack detailed kernel root kit installation techniques that would not rely on loadable module support (http://www.phrack.org/phrack/58/p58-0x07). In the grand scheme of planning application, host, and network security, kernel-level defenses should not be the highest priority. The first steps should be to prevent unauthorized access and limit privileged access, and then worry about specific defenses and monitoring for root kits.
Knark is packaged as source code and must be compiled. To compile, Knark must have available the Linux kernel sources in the /usr/src/linux directory that match the running kernel. To compile the tool, you untar it, change into its directory, and type the following:
victim# make clean victim# make
To install Knark onto the victim machine, loadable kernel modules must be supported in the currently running kernel. When you are ready to backdoor the system, type the following command:
victim# insmod knark.o
Knark comprises many different tools and techniques. It is important to note that many of the implementation specifics discussed in the upcoming sections can be changed by editing Knark's source code. Furthermore, at any time, you can enter the /proc/knark directory to find the specifics of what Knark is currently changing in the system. Notice, however, that this directory is available by default in Knark's source code and could be changed to any name other than knark.
Typically, the root user is not allowed to log in remotely. Any attacker knows this, and Knark has a solution. Instead of making a normal user escalate his or her privileges by hacking the machine again, Knark provides a tool called rootme (you will obviously need to change its name when it is installed). When run, rootme will instantly turn a normal user (that is, any user ID that is not zero) into a root user without having to provide credentials. Furthermore, this action is not logged in any log, as the su command would be.
victim$ ./rootme /bin/bash victim#
Of course, every attacker needs to hide his tool kit so that the system administrator will not find it. Knark provides a tool called hidef that can hide files or whole directories when the attacker types the following command:
victim# ./hidef <filename>
If the attacker wishes for his files to return to the ls command, he types the following:
victim# ./unhidef <filename>
Typically, when an attacker owns a machine, he runs other utilities to gain a further foothold into the network. One of those utilities may be a sniffer (see Chapter 16) used to capture passwords flying by on the network. Because a sniffer must stay running in memory long after the attacker logs off, a savvy system administrator might catch the process by using the ps command.
With Knark installed, any process can be hidden by hiding its relative /proc entry. On Linux, the information related to every process ID (PID) is stored in the /proc virtual file system. Because it is a file system, the hidef and unhidef commands work quite well:
victim# ./hidef /proc/PID
When the attacker decides he would like a process to return to the process listing, he unhides the virtual directory that corresponds to the PID:
victim# ./unhidef /proc/PID
When an attacker connects to the machine via telnet or SSH, his connection will be evident in a netstat listing performed by the system administrator. It would be unfortunate for the attacker if he were caught in this manner. Knark contains a tool called nethide that will hide connections containing a supplied string. For instance, if the attacker wanted to hide the IP address 192.168.1.100 from the victim machine, he would type the following:
victim# ./nethide "192.168.1.100"
If he wants to hide a TCP or UDP port in the list, the hacker would simply type the following command to make the port 2222 disappear:
victim# ./nethide ":2222"
If the attacker wants the strings to reappear when queried, he would type the following:
victim# ./nethide -c
Probably one of the most overused expressions today is "I use Tripwire; therefore, I am secure if I am hacked." This couldn't be further from the truth if Knark has been installed on the victim machine. Knark has a tool called ered that will redirect one command to another. For instance, imagine what would happen if the cat command were redirected to the rm command. Every time a user typed cat filename, the command rm filename would be executed instead. To redirect one command to another command, type the following:
victim# ./ered <from command> <to command>
In the instance of a system administrator running a tool such as Tripwire to check the status of important system binaries, the ered command would render the tool useless. This is because Knark catches the system call specifying the executable at the kernel level, and when the system call is executed, it runs the destination executable instead. Notice that the source binary has not changed and therefore neither has the MD5 checksum's contents. Therefore, Tripwire would not detect this hacker activity.
As an example of fooling Tripwire, imagine the following redirection, which would run the attacker's md5sum tool instead of the system's version:
victim# ./ered /usr/bin/md5sum /tmp/hackers.md5sum
To clear all of the redirections, the attacker would type the following command:
victim# ./ered -c
After Knark has been installed, it is possible for an attacker/auditor to execute commands remotely with the rexec tool. This tool is executed with the following command:
attacker# ./rexec <Spoofed IP Address> <Victim IP Address> <Command>
Rexec then spoofs packets from the given IP address using UDP with source and destination ports of 53 (DNS). Therefore, these types of packets usually make it through a security architecture because DNS traffic is typically considered to consist of innocuous name resolution packets. Of course, this packet is different and Knark executes the command once the packet comes within its sight.
The last item on our list is to hide the fact that Knark is loaded in the kernel. Because all the loaded kernels are displayed when the lsmod command is issued, Knark will be included in that list. Of course, we could rename knark.o to another inconspicuous name, such as someobscuredriver.o, but Knark comes packaged with a better solution—the modhide.o module, which will hide the last module loaded. After Knark has been installed, you would type the following command:
victim# insmod modhide.o
This command will return with an error, which is expected and accepted. Now, typing the lsmod command does not produce the knark.o module that was loaded, but Knark is still active in the kernel. After modhide has been loaded, Knark can only be uninstalled by rebooting the victim system.