The TCP/IP protocol suite, our conceptual model we use to explain the way in which data travels across a network, contains a myriad of communication protocols. The TCP/IP protocol suite generically refers to two main protocols: TCP and UDP, but there are many other protocols, some of which can be abused to create covert channels. These covert channels are nothing more than a means of illegal communication, which exploits some process of the protocol in use that is not a part of its intended design.

As you might imagine, malicious insiders could create covert channels to evade detection form cybersecurity and network analysts inside their company. Using a covert channel, insiders can sidestep packet filters, sniffers, and search engines.

Manipulating TCP Headers for Covert Communication

TCP headers offer the most possibilities for covert communication, so we’ll start here. Depicted below is a normal TCP header with all the usual fields (e.g., source and destination port, Sequence Number, Acknowledgement Number, Flags, etc.). There are a few areas in the header where secret information can be stored and sent across the network inconspicuously to a remote destination.

The Sequence Number Field

To create a covert channel in TCP, you should understand how TCP works; otherwise, you may initially have a tough time understanding this concept. The first covert channel in TCP can be created by modifying the Sequence Number field using “covert_tcp.” When a client attempts to establish a connection with a server, it send a packet with a 32-bit “Initial Sequence Number (ISN)” and a “Synchronization (SYN)” bit set in the Flags field. The ISN is used by the other packet’s Sequence Numbers to signify where they belong in the same TCP stream.

Above, we have nemesis.psionic.com secretly communicating with blast.psionic.com. Look at the first packet being sent. The “S” is the SYN followed by a 10-bit Sequence Number for this packet. The Sequence number is 1207959552. This Sequence Number is converted to ASCII characters by dividing the Sequence Number by 16777216, which equals 16. The ASCII character for 16 is “H.”

We can follow along using the same process of division for Packet One all the way up to Packet Five. The destination host will simply reconstruct and decode the data on their end and reveal the secret message, which in this case, is “HELLO.”

The Acknowledgement Number Field

This is also called the “ACK Bounce method,” and you’ll see why this is in just a moment. The ACK Bounce method uses a third party bounce server in between the two conspirators A and B.

As you should recall from a typical TCP Three-Way handshake, after the client sends its connection request to the server (ISN and SYN), the server should respond back with a SYN/ACK. This ACK packet actually contains an “Acknowledgement Number,” which is the ISN+1.

The ACK Bounce method uses IP address spoofing. If A wishes to send a secret message to B, he must spoof his source IP address so that it is the IP address of B. That way, when A sends the encoded message to the bounce server, it won’t respond with the SYN/ACK to A because the source IP address is forged. Instead, the bounce server will send (or “bounce”) the SYN/ACK (and ISN+1) to B. Since B is expecting to receive information from the bounce server, it decodes the data and stores it.

Conspirators can forge the port numbers as well. This helps if the bounce server is listening on predetermined ports or if the conspirators wish to conceal their traffic. For example, using HTTP on port 80 is very common. Using another random, not-often-used port may draw attention.

Manipulating IP Headers for Covert Communication

An IP packet has 14 fields, but only 13 are required. Take a look at the IPv4 header below. The options field is one specific field that is not required, and conspirators can certainly attempt to conceal secret information inside. However, a more common approach is to manipulate the Identification field

The Identification Field

The Identification field in a IPv4 header is 16-bits and it gives the fragmented IP packets a unique number for reassembly purposes. Conspirators can replace the Identification field with the numerical ASCII representation of the character to be encoded.

Again, we have nemesis.psionic.com secretly communicating with blast.psionic.com. Notice the Identification (id) number for the first packet. The 18432 is divided by 256 to get 72. The ACSII character for 72 is “H.”

This is very similar to the TCP SYN field manipulation. We just follow the same division process for Packet Two through Packet Five to get the secret message “HELLO.” The conspirator on the other side of the communication, listens for the information, and decodes it on the other side.

Using the IP identification field may not be feasible as routers, especially ones using NAT, modify some of these fields.

Manipulating ICMP Headers for Covert Communication

Normally, we use ICMP for troubleshooting reasons. The ICMP echo request (or “ping”), for example, is used to test a destination host’s reachability. Below is a depiction of an ICMP header included in an IP packet.

ICMP Payload

There’s a 20-byte IP header and an additional 8-byte ICMP header in a ping. If the maximum size of an IPv4 packet (including a ping) is 65,536 bytes, then that leaves an additional 56,507 bytes to conceal secret information.

Conclusion

Detecting these covert channels can prove difficult. Mostly, government agencies, military services, and other companies or industries worried about data leakage are concerned with unearthing these covert channels. If detection is difficult, then prevention is the likely way to stop covert channels from happening in the first place.

Implementing good access control will prevent unauthorized users from reaching sensitive information they can leak to third parties. One common implementation is Mandatory Access Control (MAC) in which subjects (users) are assigned security clearance levels and objects (data) are assigned sensitivity labels. You can read more about MAC here.

 

 

References

Rowland, C. H. (1997). Covert Channels in the TCP/IP Protocol Suite. First Monday, 2(5). Retrieved from http://ojphi.org/ojs/index.php/fm/article/view/528/449

University of Maryland University College. (2012). Covert Channels and Data Leakage. [Online Module]. Retrieved from the University of Maryland University Website