10.4 Maintaining Covert Access

 <  Day Day Up  >  

This segment deals with rootkits , automated software packages that set up and maintain your environment on a compromised machine. Rootkits occupy an important place in a hacking tool chest. Originally, rootkits were simply tar archives of several popular binaries (likely to be run by system administrators of the compromised machines), along with several other support programs, such as log cleaners. For example, /bin/ps , /bin/login , and /bin/ls were often Trojaned in order to hide files and maintain access. Here is a list of binaries often replaced (from http://www. chkrootkit .org): aliens , asp, bindshell, lkm, rexedcs, sniffer, wted, scalper, slapper, z2, amd, basename, biff, chfn, chsh, cron, date, du, dirname , echo, egrep, env, find, fingerd, gpm, grep, hdparm, su, ifconfig, inetd, inetdconf, identd, killall, ldsopreload, login, ls, lsof, mail, mingetty, netstat, named, passwd, pidof, pop2, pop3, ps, pstree , rpcinfo, rlogind , rshd, slogin , sendmail, sshd, syslogd, tar, tcpd, top, telnetd, timed, traceroute, w, and write.

This list demonstrates that almost nothing is immune from Trojaning by rootkits and also emphasizes that "fixing" after the intrusion is nearly futile. A rebuild is in order.

Unix rootkits were first mentioned in 1994, after being discovered on a SunOS system. However, many tools that later became part of rootkits were known as long ago as 1989. There are three main classes of rookits available today: binary kits, kernel kits, and library kits. However, rootkits found in the wild often combine Trojaned binaries with the higher "security" provided by the kernel and library components .

Let's examine some rootkits. After gaining access, an attacker typically downloads the kit from his site or a dead drop box , [4] unpacks it, and runs the installation script. As a result, many system binaries are replaced with Trojaned versions. These Trojans usually serve two distinct purposes: hiding tracks and providing access. The installation script often creates a directory and deploys some of the support tools (log cleaners, etc.) in the new directory. This same directory is often used to store the original system binaries so that they're available to the attacker. After the kit is installed, the system administrator inadvertently runs Trojaned binaries that will not show the attacker's files, processes, or network connections. A Trojaned /bin/login (or one of the network daemons) binary provides remote access to a machine based on a "magic" password. This is the style of operation employed by the famous login Trojan , which looked for the value of the $ TERM environment variable. If the value matched a hardcoded string, the login let the attacker through; if the value did not match the control, it was handed to the original login binary and the authentication process continued as usual.

[4] A site used for tool retrieval and not for any other purpose. The term originates in the world of espionage; a spy leaves various artifacts for other spies to pick up in a dead drop box.

The level of rootkit sophistication has grown over the years . More and more binaries have been subverted by attackers and included in rootkits. Local backdoors, such as "root on demand," have been placed in many otherwise innocuous programs. If a program executes SUID root, it can be used as a local backdoor to provide root access. For example, a backdoored ping utility is often seen in Linux rootkits. In fact, one rootkit author sincerely apologizes in the kit's README file for not including top (a program to show running processes) in the previous version and for delaying the release of this popular "customer- requested " feature.

A lot of development went into creating better and more user -friendly (should we say hacker-friendly?) installation scripts. Colors, menus , and automated OS version detection and configuration began showing up in kits as they matured through the late 1990s. Installation scripts became able to automatically clean logs, look for dangerous configuration options (like enabled remote logging), seek and destroy competing rootkits (ironically, by borrowing components from the antirootkit tool, chkrootkit, from http://www.chkrootkit.org), and perform decent system hardening, complete with plugging the hole used to attack the system. One of the rootkits refers to "unsupported" versions of RedHat Linux and offers limited email installation support for the kit itself.

Another area where great progress has occurred is in rootkit stealth properties. Kernel-level or LKM (Loadable Kernel Module) kits rule in this area. Unlike regular kits that replace system files, LKM kits ( publicly available for Linux, Free/OpenBSD, and Solaris) hook into the system kernel and replace ( remap ) or modify ( intercept ) some of the kernel calls. In this case, the very core of the operating system becomes untrusted. Consequently, all of the system components that use the corrupted kernel call can fool both the user and whatever security software is installed.

Rootkits have also increased in size due to the amazing wealth of bundled tools, such as attack scanners . Typical rootkit tools are reviewed in the following sections.

10.4.1 Hiding

Let's analyze how rootkits accomplish the goal of hiding your tracks. First, the rootkit hides its own presence, the presence of other intruders' files, and evidence of access. Here is an excerpt from a recent Linux rootkit installation file:

 unset HISTFILE unset HISTSAVE export HISTFILE=/dev/null ... killall -9 syslogd chattr +i /root/.bash_history ... 

The kit disables history file generation via two different methods . First of all, the kit disables HISTORY. This works for the current session and makes the existing root history saved file "immutable" ”i.e., not editable by any program on the system, even root. In addition, the kit warns about remote logging and suggests that its user "go hack the syslog aggregation box" ”a feat that might well be beyond the ability of an average script kiddie .

The kit referenced above did not perform automated log cleaning; instead, it included the appropriate tools and some tips on how to use them. Killing syslog seems like a way to draw attention, but further in the installation script a "new" (i.e., Trojaned) version of syslogd software is deployed and executed. This one ignores some IP addresses, some processes, and some users. Any message containing any of the above will not be recorded. For example, if user "evil" logs in via FTP, none of her FTP accesses are logged in the system files, provided that the malicious syslogd was configured to prevent this. Likewise, if any user connects from 166.61.66.61 (the evil IP address), nothing is logged.

Rootkits often take measures to hide their own files and other attackers' files. The oldest trick in the book is for the rootkit to obscure its own location on the disk. Even expert system administrators might not look at the entire disk every day. However, understanding the functionality of every piece of your system clearly helps to avoid some surprises . In general, only integrity checking software (such as Tripwire) can find these malicious files. Unfortunately, there are tricks that kernel rootkits play that can even defeat them.

Here are some of the locations used by the kits:

 /dev/.hdd /etc/rc.d/arch/alpha/lib/.lib /usr/src/.poop /usr/lib/.egcs /dev/.lib /usr/src/linux/arch/alpha/lib/.lib/.1proc /usr/src/.puta /usr/info/.t0rn /etc/rc.d/rsha 

There are many others. In fact, it is just too easy to change the default location. The above list demonstrates the pattern of thinking manifested by rootkit authors: hiding files in /etc (where they might look like system files of unclear purpose), rarely used locations (such as /usr/src or /usr/info ), or /dev ( where no user-utilized programs reside).

Here is an excerpt from a rootkit configuration file that shows parameters hiding, apparently based on K2's Universal Root Kit (URK):

 [file] file_filters=rookit,evilfile1 [ps] ps_filters=nedit,bash [netstat] net_filters=hackersrus.ro 

The rootkit components refer to the above file and hide the references files and connections from Unix binary tools. URK is an old, multiplatform kit that replaces several system binaries with Trojaned versions.

LKM kits take the art of hiding to the next level. Using the loadable kernel module (a piece of software injected into a running Unix kernel), the kits are able to achieve near-total control over the system. See Section 10.5 for the analysis of the well-known LKM kit Knark.

Library Trojan kits, of which Torn 8 is the most famous representative, use a somewhat different method to elude detection. They add a special system library (called libproc.so by default) that is loaded before other system libraries. The library has copies of many library calls that are redirected in a manner similar to the kernel module. It's the user-space equivalent of kernel module-based redirection.

However scary this LKM rootkit technology might be, it is not on the bleeding edge of system hiding. Simply disabling the loading of modules within the Unix/Linux kernel can defeat most LKM kits; it's usually a compile-time option for open source Unix variants. Silvio Cesare, in his paper "runtime-kernel-kmem-patching.txt," showed that loadable modules are not required for intruding upon the Unix kernel. Several kits have since turned this research advance into production code. For example, SucKit is a user-friendly package that installs in the kernel and allows covert remote login, all without the need to insert any modules. The technique invented by Silvio Cesare works for both the 2.2 and 2.4 kernels .

Rootkits also help attackers to regain ground in case the system administrator locates and removes part of the attackers' tools. However many times it has been advised that a compromised system should be rebuilt, real life dictates otherwise. While the rootkits might make the system more difficult to hack from the outside, the kits often "weaken" the Unix system from the inside. Thus, if an attacker loses ground, and even a little CGI-based backdoor remains, all is not lost and the "root" can be regained.

Other items commonly seen in rootkits assist with the game of hide-and-seek on the compromised system. For instance, multiple Trojaned binaries allow attackers to regain root control even if the main method (such as a login Trojan with a magic password) is located and eliminated. Similarly, a seemingly innocuous ping (often SUID root) can hide a five-line code modification that spawns a root shell.

Hiding becomes complicated if some other "guest" is hiding on the same system as well. Some rootkits contain advanced antirootkit tools that can seek and destroy other kits, DDoS zombies , or worms that have previously taken over the system.

10.4.2 Hidden Access

It's also important for an attacker to covertly access the compromised system. Let us review some of the methods used for this purpose by attackers. The methods are as follows (approximately from least to most covert):


Telnet, shell on port

The first method is simply connecting to a system via telnet or the old inetd backdoor (a shell bound to a high port on a system). This option isn't covert at all; it's easily detected , and we only mention it for reference. The high port shell allows you to hide from only the most entry-level Unix administrators, since the connection will not leave records in system logs, unlike the stock telnet. This backdoor dates back to the 1980s, and maybe even earlier.


ssh (regular, Trojaned, and on high port)

ssh is the tool of choice for amateur attackers. Deploying a second ssh daemon running on a high port (such as 812 or 1056 TCP) on a compromised machine is the modus operandi of many script kiddies. This method provides several advantages over using telnet, since communication is encrypted and suspicious commands cannot be picked up by the network IDSs. Custom telnet daemons also will not leave evidence in logfiles upon connecting. However, both ssh and telnet show up in response to the netstat command (provided that it is not Trojaned). This technique becomes more effective under the cover of Trojan binaries or kernel rootkits that hide the connection from the sysadmin.


UDP listener

UDP services are more difficult to port scan than TCP and are usually less likely to be found. If a backdoor listens on the UDP port, there is less chance that it will be discovered. Obviously, the listening program might be detected, but (unlike with TCP) if one packet is sent per minute, the communication is less likely to be detected. As with TCP, it makes sense to Trojan netstat and other tools that might reveal the presence of a backdoor.


Reverse shell/telnet

A backdoor that opens a connection from a target to an attacker's machine is better than a regular connection, since the target should not have any new open ports that can be firewalled ”such as by personal firewall or host-based ACL (Access Control List) protection ”against inbound connections. The connection can also be encrypted and thus shielded from a network IDS. However, many people find it unusual if their servers start to initiate connections to outside machines. Moreover, some outbound connections can be blocked on the border firewall. The hacker's machine should be running something like netcat (nc) to listen for inbound connections.


ICMP telnet

There is a saying that you can tunnel everything over everything else, and the "ICMP telnet" (implemented, for example, by the Loki tool) is a prime example. ICMP control messages such as Echo Request and Echo Reply (commonly used to test network connectivity) can be made to carry payloads such as command-line sessions. Many types of ICMP messages are allowed through the firewall for network performance reasons. Obviously, such packets might still be blocked by the firewall, unless they are initiated from the inside of the protected perimeter. In this case, the communication (e.g., via a regular ping) should be initiated from the inside. Such backdoors will not be seen in netstat and cannot be uncovered by port scanning the target machine. However, network IDSs pick up the unusual patterns in ICMP communication caused by the existing ICMP backdoors.


Reverse tunneled shell

This method helps with blocked outbound connections. In most environments, web browsing (access to outside machines on port 80 TCP) is allowed and often unrestricted. A remote HTTP shell imitates a connection from a browser (inside the protected perimeter) to the web server (outside). The connection itself is fully compliant with the HTTP protocol used for web browsing. The software that can interpret the "HTTP-encoded" command session plays the web server part. For example, a simple and innocuous GET command (used to retrieve web pages) might be used to retrieve special files. The requested filename can carry up to several bytes of communication from client (inside) to server (outside). "GET o.html", then "GET v.html", then "GET e.html", then "GET r.html" transmits the word "over". An algorithm for such communication might be much more elaborate. Such a backdoor is unlikely to be detected. The backdoor engine can be activated by a "magic" packet or by a timer for higher stealth.


"Magic" packet-activated backdoor

This is a mix of reverse shells and regular direct connect backdoors. The backdoor opens a port or initiates a session from the target upon receiving a specific packet, such as a TCP packet with a specific sequence number or with other inconspicuous parameters set.


No-listener (sniffer-based) backdoor

This method of hidden communication provides a high degree of stealth and includes deception capabilities. In this case, the backdoor does not open a port on a local machine, but starts sniffing network traffic instead. Upon receiving a specific packet (not even aimed at the machine with a backdoor installed, but visible to it ”i.e., located on the same subnet) it executes an action and sends a response. The response is sent using a spoofed (i.e., faked) source IP address so that the communication cannot be traced back to a target. Well, actually, it can (if someone observes the layer II or MAC hardware address), but only if the observer is in the same LAN as the victim. These backdoors are just starting to pop up in rootkits. In some sense, such a backdoor is easier to detect from the host side, since it has to shift the network interface into promiscuous mode. However, this detection vulnerability is compensated for by the increased difficulty of detection from the network side, since packets are not associated with the backdoored machine. If spoofed replies are used for two-way communication, the MAC address of the real source might be revealed (if only to the sensors deployed on the same subnet as the source).


Covert channel backdoor

A full-blown covert channel (in the sense defined in the Department of Defense's "Light Pink Book" from the Rainbow Series) [5] can be mathematically proven undetectable. If you are going to design your own signaling system and then overlay it upon the otherwise innocuous network protocol, it will probably never be detected. The number of factors that can be varied and arbitrary fields on network and application layer protocols is too high to be accounted for. For example, what if the TCP initial sequence number is not quite random but carries a pattern? What if the web server slightly changes the formatting of the web page to send a byte or two out? The possibilities are endless.

[5] NCSC-TG-030 [Light Pink Book] "A Guide to Understanding Covert Channel Analysis of Trusted Systems" (11/93), available at http://www.fas.org/irp/nsa/rainbow/tg030.htm.

The above list demonstrates that even though hiding on a network is complicated, there are many tricks that interested parties can employ to keep their presence hidden, even under intrusion detection systems. However, the more tightly controlled the network is, the less likely it is that a covert channel will sneak through.

 <  Day Day Up  >  


Security Warrior
Security Warrior
ISBN: 0596005458
EAN: 2147483647
Year: 2004
Pages: 211

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net