March 22nd, 2005, 03:55 AM
First off I would like to say I suck at writing tutorials. I am a knowledge retainer, not a giver. Hence why I will never teach anything tech. I have a difficult time explainging how things work to people so please, be gentle but critical when reading this. This tutorial is actually a part of an essay I am writing for my finals soon in my systems security course . The topic is Network infliltration from the attackers standpoint - how understanding methodology can be your best defense. So with out further adue I give you my tutorial on information handling on covert channels.
Once attackers have installed backdoor listeners on a system and cleaned up their tracks in the logs, they need to communicate with their nefarious programs on the victim machine to control them. To avoid detection, an attacker will utilize stealth mechanisms to communicate with the backdoor system across the network. Such disguised communication mechanisms are refered to as "covert channels". Covert channels are essentially an excercise in hiding data while it moves. While encryption mathematiclly transforms data into cipher text so an adversary can not understand it's contents, covert channels hide the data so the advasary doesn't detect it in the first place. A truley paranoid attacker will hide data and use cryptography together.
The techniques we will discuss for establishing covert channels across the network require a client and a server. The server must be installed on a victims machine, acting as a sentinel, ready to exchange data with the client. The client packages up the data using stealth techniques, while the server unpackages the data and reacts to it. The covert channel can be used for remotley controllig a system, secretly transmitting files, or any other application an attacker wants to keep secret.
How does the covert channel get installed on the victims computer in the first place?
Attackers have employed countless techniques in real-world cases, including these scenarios:
* An attacker can take over system and place a backdoor listener on it through a vulnerbility such as a buffer overflow.
* The attacker could email an unsuspecting internal user an executable program, or virus, witch implementes a covert channel server.
* The attacker may be an ex-employee who had system administrator privlages before being terminated. The attacker could leave the covert channel server as s way to keep unauthorized, lingering access.
* The attacker may have been a temp or contractor, who signed on for a brief stint with your organization for the sole purpose of installing a backdoor agent on your internal network (and hell, to make a couple bucks on your payroll while doing so.)
Any of these mechanisms can be used to gain access. Once access is obtained, the covert channel will help the attacker carry on his/her work in stealth mode remotely.
Covert channels often rely on a technique called tunneling, wich allows one protocol to be carried over another protocol. Any communications protocol can be used to transmit another protocol. Consider a hypothetical protocol called TCP/CP. TCP/CP marries a moderen-day computer protocol to an ancient mechanism for delivering messages, resulting in a slow, yet remarkably effective communication tool for intermediate distances.
What is TCP/CP? The Transmission Control Protocol (TCP), transmitted via Carrier Pigeon, of course. The higher-layer application (which could be web browsing, telnet, FTP, or any other TCP-based application) passes data down it's protocol stack. The TCP layer formats the packet, and instead of sending it to the IP layer, it prints each TCP packet on a tiny sheet of paper. Each packet is then wrapped around the leg of a carrier pigeon. The pigeon is released, carrying the printed sheet to it's destination. At the destination, the data is retyped into a computer, passed up through the TCP layer, and sent to the reciving application. Pigeons are then fitted with responses, and interactive communication occurs. Although not terribly efficent, TCP/CP shows how any protocol, no mater how bizzare or awjward, can be used to carry another protocol through tunneling.
In a real-world example of tunneling techniques, the secure shell (SSH) protocol can be used to legitimately to carry other TCP-based services. While originally secure shell focused on providing strongly authenticated, encrypted command line access across network, through tunneling, it's use has been greatly expanded. With a rock solid session in place, any other TCP services, such as telnet, FTP, or even X-window session, can be transmitted securely over SSH. This SSH tunneling technique is frequnetly used to create VPN-like access across untrusted networks for TCP services.
The power of these tunneling techniques has been harnessed by attackers to remain undetected as they communicate with their back-door listener. Several tools are widely exchanged within the computer underground based on these techniques. We'll look at a few of the most widely used.
Reverse WWW shell: Covert channels using HTTP
Reverse WWW shell allows an attacker to access a machine with a command line prompt on your internalnetwork from the outside, even if it is protected with a firewall. The attacker must install (Or get one of your users to install) a simple program on a machine in your network, the Reverse WWW shell server.
On a regular basis, usually every 60 seconds, the internal server will try to access the external master system to pick up commands, essentially calling home. If the attacker has typed something into the master on the external system, theis command is retrived and executed on the internal system. The next communication from the internal agent will carry the results of this command, and a request for the nxt command. This is the reverse parrt of it all: the server goes to the master to pull commands, executes them, and pushes the results. From a network perspective, the internal machine (victim) appears to be surfing the web. The Reverse WWW shell server uses standard HTTP messages sent to the attackers external system across the network, where the master is running. When it access the master, the Reverse WWW shell server pushes out the command line prompt from the server, tunneled in HTTP request and responses. So, the internal agent looks like a browser surfing the web. The external master looks like a web server. All outgoing data is transmitted from a high numbered source port, to a destination TCP of 80. All responses come back from TCP port 80 on the high numbered port.
Ok so, the packets have HTTP characteristics. But, even worse, the shell data is formated as HTTP GET commands. Therefore, even a proxy firewall that enforces the use of HTTP on TCP port 80, carefully combing the protocol to make sure it's HTTP, is befuddled. The firewall and other network components view the traffic as standard outgoing HTTP, something that most networks allow. In fact, the covert channel is incoming shell access, allowing the attacker to execute any command on the internal system.
From an attackers point of view, using Reverse WWW shell is rather annoying; the cascade of entering commands, waiting for the server to come and retreive them, and send the responses can be cumbersome and frustrating. The attacker types in a command, waits 60 seconds, and then gets a response. The attacker can then enter another command, wait another 60 seconds, waits and so on and so forth. To make it even more stealthier though the atacker can set access to random times.
Unfortunatley, you are still not safe if you require HTTP authentication with static passwords to get out through your firewall. Many organizations only allow outgoing web browsing is a user authenticates to a web proxy with a userID and password. Reverse WWW shell allows the attacker to program the system with a userID and password that will be given to the outgoing web proxy firewall for authentication.
From an implementation perspective, the Reverse WWW shell client ad server are the same program with different command line parameters. The single client/server program is written in perl, so an interperter is required on both the inside and the outside machines. A suffciently motivated attacker would rewrite the tool in C, to run it on a system with out perl. Additionally, several folks have developed similar funcionality for tools that use HTTPS.
Let the TCP and IP headers carry the data
While covert channels created by embedding one protocol entirely in a different protcol can be quite effective, covert channels can also be constructed by inserting data into unused or misused fields of protocol headers themselves. The TCP/IP protocol suite is a particularly useful in carrying cover channels.
One particularly intersting tool that illustrates exploiting TCP/IP headers to create covert channels is called Covert_TCP which runs on Linux. Covert_TCP shows how data can be secretly carried in TCP headers be implementing a simple file transfer routine using the technique. Covert_TCP allows for transmitting information by entering ASCII data in the following TCP/IP header fields:
* IP identification
* TCP sequence number
* TCP acknowledge number
Of course, other components of the TCP and IP headers could be used to transmit data, such as the reversed, window, code bits, options, or padding fields, but only three components are supported by Covert_TCP. These components were selcted because they are often left unaltered as packets transverse a network. Even though only three different fields are supported in the tool, Covert_TCP is still remarkably effective in creating a covert channel.
A single executable program implements both the client and server. An attacker configures Covert_TCP to run in a particular mode, depending on the field to be used to carry data. The command line arguments used to initalize Covert_TCP indicate whether it is to transmit data over the IP identification field (" -ipid" mode), TCP inital sequence number (" -seq" mode), or TCP acknowledgement sequence number (" -ack" mode). These modes are mutually exclusive, and the client and server must use the same mode to communicate with each other.
The IP identification mode is quite simple. ASCII data is simply dropped into that field at the client and extracted at the server. A single character is carried in each packet.
The TCP initial sequence number mode is somewhat more complex. The first part of the TCP three-way handshake set to represent the ASCII value of the first character in the file to be covertly transferred. The Covert_TCP server sends back a RESET packet, because the itent of the communication is to deliver the character in the sequence number field, not to establish a connection. The client then sends another session inititation ( again, this is part of the 3-way handshake), containing another character in the initial sequence number field. Again, the server sends a RESET and the 3-way handshake is not completed. Although not terribly effcient in transferring data, this Covert_TCP mode is quite useful.
The most complex mode of operation for Covert_TCP uses the TCP acknowledgement sequence number, which applies in a so called "bounce" operation. For scenarios where the acknowledgement mode is used, three systems are involved: the server, the client, and the bounce server. In this mode the attacker essentially sends data from the client and bounces it off the bounce server using spoofing techniques, thereby transmitting it to the receiving server. TO accomplish this, the attacker first establishes a Covert_TCP server on the receving machine, putting it in ack mode. The attacker also selects a bounce server, which can be any accessible machine on the internet. No attacker software is required on the bounce server. ALl the bounce needs is a TCP/IP stack and a network connection. The attacker will send the file over a covert channel fromt he client system to the recieving system via the bounce server. The beauty of this, from an attackers point of view, is that a trace of the packets at the server will show that they came from the bounce server. A forensics investegator must trace the spoofed connection back from the recieving server to the bounce server and then to the client. Which can be a truley difficult task. The bounce operation can even be distributed. A single client could bounce a single file off dozens or hundreds of bounce servers, with a single receiving server getting the file to confound investigators. Each character of the file being transmitted could come from a different bounce server, resulting in a much more complex investigation.
Don\'t be a bitch! Use Slackware.