KNARK
| | ||
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.
Implementation
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.
Becoming a Root User
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#
Hiding a File or Directory
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>
Hiding a Process Entry
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
Hiding a Network Connection
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
Redirecting Executable Files
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
Remote Command Execution
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.
Hiding Knark.o in the Loaded Module Listing
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 solutionthe 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.
Kernel root kit techniques that hide processes may appear to be foolproof, but they really just consist of a simple sleight of hand. Take this example of hiding the SSH daemon. First, we identify the process ID. One way is to run netstat nap and grep for sshd :
[root@localhost knark-2.4.3-release]# netstat -nap grep sshd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 993/sshd
Now that we have the process ID, the next step is to hide the process entry. Since Linux uses a pseudo-file system called proc to keep track of running processes (among other kernel-related items), the practice of hiding a process is identical to hiding a file. In this case, we hide the file that corresponds to the process ID of 993.
[root@localhost knark-2.4.3-release]# ./hidef /proc/993 [root@localhost knark-2.4.3-release]# netstat -nap grep sshd ( blank line )
The blank response from the netstat command indicates that the process is hidden. A hidden process still functions normally. If you're working through this example, try to log into the system via SSH; you'll succeed. We could run another command to verify that the process has disappeared from sight. Run the ps command:
[root@localhost knark-2.4.3-release]# ps 993 PID TTY STAT TIME COMMAND
This verifies that the process is hidden from such user-space commands as netstat and ps . We can safely assume that any other command that reports on process status will also fail to identify our invisible SSH daemon. Yet you should realize that the process (or file) is only hidden. It still physically exists on the server and within memory since the daemon is still listening on port 22. A very simple test can verify its presence: the cd (change directory) command.
[root@localhost root]# cd /proc/993 [root@localhost 993]# ls binfmt cmdline cwd environ exe fd maps mem mounts root stat statm status [root@localhost 993]# cat cmdline /usr/sbin/sshd
Processes, unlike other files, are deterministic in the naming convention. For example, if the process ID doesn't exist, then you would receive an error:
[root@localhost root]# cd /proc/994 -bash: cd: /proc/994: No such file or directory
The change directory technique would be extremely difficult to apply to randomly named files anywhere in the directory structure. On the other hand, the processes in the /proc file system are easy to brute force. You could walk through each possible number and compare the running process list with the result of each change directory command. Any discrepancy may point to a process hidden by a kernel root kit!
This case study examines backdoor and remote controlling tools categorized into three different levels, each with varying degrees of complication for utilization, detection, and removalhence, the title "The Good, the Bad, and the Ugly." The "good" tool is VNC; the "bad" tools are Back Orifice, Netbus, and SubSeven; and the "ugly" tools are Loki, stcpshell, and Knark.
A simple network contains a Windows XP machine and a Linux server. The network is guarded with a standard stateful packet-filtering firewall with few filtering rules inbound. In fact, the administrator of the firewall was so lazy that he allowed the same ports inbound for the entire subnet. (Everyone knows how much of a hassle it is to submit the proper paperwork to open and close ports in a large organization!) Outbound from this network all traffic is allowed, which is a typical configuration in modern times. No firewalls exist between each of the victim machines in the subnet, so any and all traffic will be transmitted between them. Remember that these tools don't provide the initial point of entry into a network or host; they are backdoors that make revisiting a compromised host easier.
The following table shows the configuration:
| Machine Type | Allowed Inbound Ports |
|---|---|
| Windows XP machine used by the network administrator as a workstation | TCP port 80 (HTTP), TCP port 22 (SSH), and UDP port 53 (DNS) |
| Linux software development server, without a web server | TCP port 80 (HTTP), TCP port 22 (SSH), and UDP port 53 (DNS) |
The goal is to control this network remotely after it has already been compromised. The following paragraphs discuss several scenarios that an attacker can use to gain access to these systems.
VNC In the VNC scenario, an attacker changes the port of VNC to anything in the allowable TCP port range. The hacker changes the port to TCP port 80, binds it to an innocuous program, and dangles it in front of the administrator in an attractive manner in hopes that the admin will run the Trojaned program. After the administrator runs this program, which installs VNC and adds the appropriate registry values, the hacker will be able to connect to his Windows workstation through the misconfigured firewall.
Back Orifice Using BO2k, an attacker is able to open this backdoor, once again, on TCP port 80. The attacker can gain access to the administrator's Windows workstation if the administrator runs this program on the victim machine. Therefore, the attacker would want to dangle this program, attached to an attractive innocuous program, in front of the administrator in hopes it will be executed. Once it has been executed, the attacker has gained access to the network.
Netbus Using Netbus, an attacker can change the server port to 80, just as we've seen with VNC. If the attacker can get the administrator to install this on his machine by binding it with an attractive program, easy access is gained into the network. After Netbus is installed, an attacker can capture the administrator's keystrokes and perhaps gain extra passwords to the Linux server. In this scenario, because most virus-scanning programs can locate Netbus, the attacker must hope that the system is not running an updated virus-scanning program.
SubSeven Using Sub7, an attacker can change the port on which a backdoor will listen for connections. In doing so, the attacker is able to circumvent the firewall if he can get Sub7 installed on the administrator's workstation. After the attacker has gained access to the administrator's workstation, access to his Linux server can begin.
Once a hacker has installed a backdoor on the Windows machine left open by an administrator, the hacker can sniff passwords typed by the administrator by simply reading the keyboard input as he logs into the Linux server. Additionally, the hacker can also connect to the Linux server by activating a data redirection tool, built within Sub7, on the Windows machine. The attacker can then use his backdoor to connect to the Linux box through the Windows machine's TCP port redirection and supply the administrator's credentials. For this example, TCP port 22 is used as the input port to the Windows machine and forwarded to the Linux server, therefore evading the security architecture in place.
Knark Once the hacker is in the Linux server, he will have root access (supplied by the administrator's keyboard) and can install Knark successfully. Remote command execution will be successful because the rexec command uses UDP port 53 to communicate with the server. The hacker now has backdoors on both victim systems and owns the entire network.
| | ||
EAN: 2147483647
Pages: 175