Disguised TCPIP Protocols

 < Day Day Up > 

Disguised TCP/IP Protocols

A rootkit's activities should be covert undetectable. Communication over a TCP socket can easily be detected, both on the network and in the kernel. Opening a TCP socket is a very noisy event that creates a SYN packet, followed by completion of the famous three-way handshake.[2] Any packet sniffer will report it. Intrusion-detection systems will almost always log the event, and may even create an outright alarm. Finally, TCP ports can usually be mapped back to the software process that created them. These are all really bad for a rootkit. More-subtle measures must be used.

[2] TCP protocol dictates that three packets are used to set up a new connection; this is known as the "three-way handshake," and is detailed in many documents available in the public domain.

In a noisy environment like a network, intrusion-detection systems look for activities that stand out that are different. One approach to good covert-channel design is to use a protocol that is in constant use on the network (such as DNS, Domain Name Service). In using DNS as a covert channel, a rootkit will use a modification to the protocol to place extra data into a packet. The goal is to make the packet "look and smell" just like legitimate traffic (so that nobody will notice it). Even if you don't make your packets look exactly like the real thing, sometimes they still won't be noticed.

The rule is simple: Hide in traffic that is already there.

If you don't want to get into protocol specifics, just start by using a source and destination port of a common protocol. For DNS, this is port 53 (UDP or TCP). In many cases, DNS is even allowed over a firewall. For the Web protocol, the port is TCP port 80, or 443 for encrypted Web. If you choose port 443 and encrypt everything, you can be sure no one will take a look inside your packets. One word of warning, though: Technology exists to unencrypt SSL Web sessions.[3] This technology can be used by IDS equipment (but usually isn't).

[3] Ettercap (http://ettercap.sourceforge.net) is a tool for this purpose.

"Hiding in plain sight" can be harder than you might expect. In the following sections, we detail many challenges you will face, and we make some creative suggestions for your covert-channel designs.

Beware of Traffic Patterns

Hiding data in a known protocol is just a first step in creating covert communications. You must also use conservative traffic patterns. A covert channel should not create an excessive amount of traffic: To avoid being noticed, you must not spike above normal usage.

If your rootkit is creating solid green bars on the MRTG[4] graph, someone is bound to notice. If the network is quiet, and suddenly, at 3 a.m., a big traffic spike occurs, an administrator's first thought will be that someone is engaged in a high-traffic activity, such as sharing an "iso" of Quake III on some file share. If the administrator investigates, the traffic spike will lead her right to your infected machine. That's bad on all counts.

[4] Multi Router Traffic Grapher (www.mrtg.org).

Don't Send Data "in the Clear"

This is a fine point, but even if you use a known protocol and don't create traffic spikes, you should still hide your data so that it doesn't look malicious. Hide your data inside of other, innocuous-looking data. If you put unencrypted password files in the payload of the packet, for example, someone is going to notice. If some admin examines this packet, big alarm bells will go off. Furthermore, some IDS systems do blanket searches of all packets for suspicious strings, like "etc/passwd." The payload should be obfuscated at the very least. Even better, you should use encryption[5] or steganography.

[5] Sometimes using encryption increases the chance that something will look suspicious. If the protocol typically uses easy-to-read text, and you're transmitting garbled bytes or high-entropy data (read: encryption), the packets will stand out like a sore thumb.


Steganography doesn't have to be rocket science. In essence, the term means to hide a small message inside a much larger message in a way that is not easily noticed or detected. It does not necessarily imply that this data must be encrypted in any fashion it just means it should "hide in plain sight."

Successful use of steganography will surely require you to limit the bandwidth used by your communication, but it will be much more secure. To use our DNS example, the DNS packets would carry real DNS queries. The payloads would contain queries for legitimate Web sites. But secretly hidden between the lines would be remote commands and exfil data. The problem is that not much data will fit between the lines. This means it might take a long time to move a large file or database. Depending on the covert-channel design, some data could take weeks or months to transfer.

Use Time to Your Advantage

An often-overlooked factor in communication is time. Rather than encoding data into the packets themselves, a rootkit could encode data within the amount of time between packets. The rootkit would measure the time at which each packet arrives on the network, and based on this, extracts meaningful data. A time-based covert channel allows for a much more covert operation. Like many covert-channel designs, the bandwidth of your connection may be limited, so this would be useful only for short messages and commands.

Hide Under DNS Requests

A commonly used covert channel is one that hides under DNS packets. This channel has some attractive qualities. First, DNS can use UDP packets, which don't have the overhead of a three-way handshake. Second, UDP packets can be spoofed. Third, DNS is usually allowed through a firewall. And finally, DNS packets are constantly moving over the network, so they are usually ignored. These last two advantages are the most important ones.

"Stego" on ASCII Payloads

There are subtler ways to hide than just tacking an encrypted payload onto the end of a DNS packet. An astute observer would find this highly suspicious. Remember those toy crypto cards from childhood the ones with hole-punched cards? You could overlay the card upon written text and the punch-outs would align with certain letters. From a page of written text, a single message would be revealed. This is basic "stego."

For an example of using steganography in ASCII data, let us consider a basic scheme using our DNS covert channel. Assume we need to send a message that is 10 bytes long (perhaps a command, or a sniffed password). We can make a DNS query for each of the characters of the message. Each DNS query will be for a Web site name whose starting letter is the same as one message character. This is known as an acrostic message (see Figure 9-1).

Figure 9-1. A series of DNS requests used to encode an acrostic message. The first letter of each DNS name is used to reconstruct the message "SECRET."

This example works, but it is contrived. In the real world, you would want to first encrypt the message, and then use steganography to send only the cipher text. This would provide two levels of protection, so that even if the message were recovered, it would still be encrypted.

Our example design requires a database of DNS names, each corresponding to a different ASCII byte.[6] One enhancement could be to use DNS names that each represent more than one cipher character. Each DNS query could then transfer several characters of the message.

[6] The database of Web-site names could be built on-the-fly by sniffing other, legitimate DNS queries on the network.

Steganography is a very large subject, and a detailed exploration is beyond the scope of this book. We leave you with this simple example as a starting-point so that you can forge ahead on your own. Steganography resources are everywhere on the Internet, including software packages and source code to hide data within images, .wav files, and even MP3 music files.[7] The field is wide open.

[7] Steghide (http://steghide.sourceforge.net).

Use Other TCP/IP Channels

Other forms of packets have been used as covert channels by hackers, including ICMP packets. For fun, one person has even created an ICMP covert channel to transmit "ASCII art" (a crude form of artwork using printable characters).[8] One popular tool that uses ICMP to transfer data is known as Loki.[9] Loki has very likely been a starting point for many custom modifications. Kernel-rootkit technology has also been developed that can exfiltrate captured keystrokes using ICMP responses.[10]

[8] D. Opacki, ECHOART, available at: http://mirror1.internap.com/echoart/

[9] Daemon9 and Alhambra, "Project Loki: ICMP Tunneling," Phrack/7, no. 49, Article 6 (8 November 1996), available at: www.phrack.org/phrack/49/P49-06

[10] See B. Jack, "Remote Windows Kernel Exploitation: Step into the Ring 0" (Aliso Viejo, Cal.: eEye Digital Security, 2005), available at: www.eeye.com/~data/publish/whitepapers/research/OT20050205.FILE.pdf

Some amount of public research is available on using the TCP/IP protocol for covert channels.[11] In this section we have outline several ways you can use the protocol to hide data in transit.

[11] For example, see C. Rowland, "Covert Channels in the TCP/IP Protocol Suite," First Monday/2, no. 5, (5 May 1997), available at: www.firstmonday.org/issues/issue2_5/rowland/

In addition to the locations already discussed, data fields that are optional or not used in normal operations become prime candidates for carrying covert data. In the IP header, the IP Identification field can be used in this way. For TCP, the initial sequence number and the acknowledgement sequence number can be used as covert-data carriers.

     < Day Day Up > 

    Rootkits(c) Subverting the Windows Kernel
    Rootkits: Subverting the Windows Kernel
    ISBN: 0321294319
    EAN: 2147483647
    Year: 2006
    Pages: 111

    Similar book on Amazon

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