Section 11.11 Stealth Trojan Horses | Real World Linux Security Prentice Hall Ptr Open Source Technology Series

11.11 Stealth Trojan Horses

graphics/fourdangerlevel.gif

More SysAdmins are scanning their own systems now for Trojans that might be listening on particular ports awaiting instructions. The default port numbers for some popular Trojans are well known; the ports program discussed in "Turn Off Unneeded Services" on page 86 will recognize some of these and generate an alert. Of course, it is a simple matter for the cracker to alter the port listened on. The ports program will help detect this by flagging any high numbered port in a listen state because the listen state is for servers. Legitimate servers almost always are on well-known ports and almost always on ones below 1024.

Note that the issue here is an illicit program running on your system listening for messages from other systems (or outbound messages from your system). See "Captain, We're Being Scanned! (Stealth Scans)" on page 392 regarding programs on other systems scanning your system.

The TFN2000 (Tribe Flood Network 2000) Trojan, explained in the previous section, is an example of a Stealth Trojan horse. Normally an Ethernet network card's hardware is configured to "capture" only packets on the Ethernet with the destination address of the system that the card is in. This greatly reduces the load on the system by having the card not generate an interrupt and force the kernel to process the 80 99 percent of network traffic that is not destined for the local system.

Most Ethernet network cards can be reconfigured by any program running as root to go into what is called Promiscuous mode. This means that the card then will capture any packet on the network, regardless of the destination address in the packet. This will allow the program that placed the card into Promiscuous mode to read any packet of any type on the network.

This is how network sniffers such as tcpdump and various cracker tools work. TFN2000 puts a computer's network card into Promiscuous mode and listens for ICMP echo reply messages or various types of broadcast packets that contain instructions from the cracker specifying what system to flood with packets. Note that it does this without having any UDP or TCP ports open.

Once the Trojan has opened the socket and placed the Ethernet card in Promiscuous mode, the program can change its effective or real UID to something other than 0 (root) and thus be less noticeable, particularly if the executable is renamed to sh or netscape.

Note that the TFN2000 Trojan can communicate solely with ICMP echo reply packets. The master (client) sends an ICMP echo reply packet containing instructions containing the victim's IP address and the type of attack desired to the Trojan (server) running in a system that already was broken into. This single ICMP echo reply packet contains all the information necessary for the Trojan server to launch the attack against the victim's machine.

This ICMP echo reply packet contains a phony source address so only the system that receives the packet directly from the cracker's system could possibly identify the cracker's system, but even this system does not know whether the cracker's system merely is forwarding the packet. The cracker does not get acknowledgment that the server received the message to protect the cracker from being discovered by tracing an acknowledgment packet.

11.11.1 Why ICMP Echo Reply Packets and How?

Certainly, the Trojans such as TFN2000 listening in Promiscuous mode could react to any TCP, UDP, ICMP, or any other sort of packet so why use ICMP echo reply packets? An echo reply packet, surprisingly enough, is the reply to an ICMP echo request packet. The echo request packet is what ping sends to test connectivity to a remote system. The echo reply is the response to ping's echo request. All but the most tightly secured systems allow their systems behind the firewall to ping remote systems and receive the echo reply. To allow this, most firewalls are configured to allow echo replies originating from outside their networks to be forwarded to any system inside their networks.

Thus, the firewall does not stop these packets. I admire the brilliance of the person who thought of this. (See "Tunneling Through Firewalls" on page 77 for other ways that crackers tunnel through firewalls to see what is on the inside.)

How can programs communicate with ICMP echo reply packets? Any data that will traverse the network may be used for communication, regardless of how that data was intended to be used. The ICMP echo reply packet has bytes available that a cracker can place data in.

Some security experts have proposed firewalls looking at these data regions and removing data that is not necessary for the intended purpose. This will slow crackers down for about a week.

The crackers then could use the presence or absence of a packet within a time frame as a binary code to transmit the data similarly to Morse code. Many years ago, the security on a classified system was breached by having the sending process control the rate that it accessed the disk. The receiving process, operating at a different security clearance, measured the response time to its disk access requests to create a slow but effective Morse code like mechanism. This is referred to as a covert channel of communications.

There is no simple rule that a firewall might use to combat this problem other than forbidding echo replies from coming in and thus use of ping. Certainly, the firewall could restrict echo replies to one or two systems inside the firewall that are considered secure enough to be trusted.

Most stateful firewalls are smart enough to recognize that this ICMP echo reply is not in response to an echo request and block it. These are covered in "Stateful Firewalls" on page 540.

The use of broadcast packets has the advantage to a cracker that a SysAdmin will not know which system has the Trojan and also that it may trigger Trojans on many systems simultaneously. Please see "Detecting Promiscuous Network Interface Cards" on page 656 and "Finding Promiscuous Processes" on page 660 for details how to detect these Trojans. "Handling Running Cracker Processes" on page 673 covers what to do if you find such a process.

11.11.2 Future Directions in Stealth Trojan Horses

Now that you understand how to detect Promiscuous network cards and have installed the scripts to monitor for this, are you safe? Maybe for now. The author predicts that the next wave of Trojan horses simply will get more stealthy. One solution might be for them to tweak the kernel variables to defeat the code that searches for Promiscuous ports or even the code in the running kernel itself. Using /dev/kmem and a kernel debugger, this is easy.

There is a simple approach, though. Do not have any port open. Thus, your scans will not detect anything because there is nothing to detect. The Trojan, running as root, simply would open the port for a brief time at known intervals, listen for requests, and then close the port and go back to sleep unless a request was seen. When the cracker wanted the Trojan to activate, she simply would start sending the ICMP echo replies or similar shortly before the time that the Trojan was scheduled to wake up. This would allow for slight variances in clocks.

Statistically it would be unlikely for the scripts discussed to be scanning at exactly the brief time that the port would be open. The cracker might synchronize your system's time to a handy Internet atomic clock so that she can use a smaller time window. If the Trojan monitored the network for one second a day at irregular times known only to the cracker, there would be only 0.028 percent probability per day that your hourly Promiscuous port checker would detect this. The solution to this problem is discussed in the next section.

11.11.3 Promiscuous Mode Kernel Messages

Some of the Ethernet card drivers invoke one of the kernel logging methods to note when a card is put into Promiscuous mode, but consistency is lacking and some cards do not log this. Linus? If your card is not one of these, investing the small amount of effort to modify its driver to call printk() when Promiscuous mode is initiated might be worth the effort. These drivers reside in drivers/net. As of the 2.2.12-20 kernel, the messages are as follows in Table 11.1.

These messages may be scanned for via syslog's log files and you could arrange to be notified via e-mail and pager. These techniques are explained in "Paging the SysAdmin: Cracking in Progress!" on page 620. Certainly, a cracker could modify the kernel to bypass these messages.

Top