Juan Ortega 8/7/09 NTS470

Covert Channels Research Project

Using the Internet Protocol, computers across a packet-switched internetwork are able to communicate with each other using TCP/IP. The communication is bundled up into packets at the transport layer and onward into the Internet layer were Internet Protocol versions 4 and 6 add their own distinctive headers. An analogy of the IP headers can be described as writing your information on a mail envelope, you would always need to include the senders and receivers information in order for the mailman (router) to properly forward the mail (packet) to its proper destination; but unlike the mail envelope were every bit of information is required, Internet Protocol headers have a little too much information which can be used as covert channels. Kamran Ahsan wrote an excellent paper on the subject entitled Covert Channel Analysis and Data Hiding in TCP/IP available here [1], virtually everything about hiding data in IPv4 is explained as well as describe scenarios where it can be used effectively. Through the end of the paper on '7.2 Further Research' the author explains the subjects that were no covered in the writing; therefore, I will covert them on this paper; these subjects are: an overview of covert channels for IPv4, Covert Channels for IPv6, UDP, routing protocols such as RIP, and OSPF. Kamran Ahsan also developed a powerpoint presentation available here [2], where the basics of the research paper itself is explained but does not go much into detail on the framework of IPv4. Over viewing Kamran Ahsan description on Internet Protocol version 4; the main goal is to discovery a redundancy within the protocol that can used to transport even one byte of data to the receiver. IPv4 itself contains many headers that can manipulated to encompass data, many of these headers are rarely used such as the padding field, options field, and urgent pointer field. The following are scenarios Kamran Ahsan describes:

In TCP, if the URG flag is set then the 16-bit Urgent pointer field is used to tell the receiver were to read/look first in the packet. If the URG pointer is not set, the Urgent pointer field becomes redundant and becomes a field were extra data can be sent without any effect of the delivery process.

The Options field is used to define what segment size the hosts supports, this field is only used twice in the three-way handshake, once the connection is established this field also becomes redundant and can be used to store hidden messages, of course knowledge of the Maximum Segment Size (MSS) is needed.

The padding field is only used for extra meaningless bytes, again this can be used to hide characters.

The identification field is used to identify a specific IP datagram and to identify all fragments of a specific IP datagram if fragmentation occurs; therefore if fragmentation is set off (set by the DF bit) or if the packet is under the MTU, this field becomes redundant. This field contains a random generated 16-bit hexadecimal, the first 8-bits can

be used to transport a single ASCII character, after that (the X's) are random bits.

Taking the last scenario of manipulating the identification field in order to produce an ASCII character. Using my notice Perl programming skills, I constructed a sample Perl script that would do just that. However it is only a server script, I wasen't able to produce the client at this moment. The script can be found here [3]. The comments in the script detail the step process. The next generation protocol IPv6 was designed to reduce processing time at the destination and on intervening routers, so although bigger in packet size when compared to IPv4, IPv6 contains much less header information. In fact there are only 8 fields: Version, Class, Flow Label, Payload Length, Next Header, Hop Limit, Source, Destination; where as IPv4 contains 14, this leaves little to work with when discovering redundancies but not impossible. Lets look at possible fields that can be manipulated for covert channels:

Version Field (4-bits) Contains the version of the protocol so the value is always 6, no hidden data is possible.

Class Field (8-bits) This new field is used to support prioritization mainly used for voice and voice communications. There are 3 parts to this field: Delay Sensitive (1 bit), Precedence (3-bits), Reserved (4-bits). The Reserved field is not use at this time therefore cannot be used for covert channels as IDSs might see this packet as suspicious. Seeing as we need at least 4-bits to send one ASCII character, the Delay Sensitive and Precedence Field can be used as covert channels, though the only down side is if this packet is constantly sent as a very high priority, it might arouse suspicion.

Flow Label Field (20-bits) A flow is a set of packets for which a source requires special handling by the intervening routers. The IPv6 specification is intentionally vague about the use of flow labels. In fact, the use of flow labels is not required at all. If the Label field is not used, it is padded with 20 zero bits. [4] Usually used for QoS management, this is the mother load of covert channels, usually it is difficult to find one redundancy where 4-bits are not used, but 20-bits? This may be used to hide up to five (5) entire ASCII characters on a single packet.

Payload Length Field (16-bits) This field indicates the amount of data following, but not including the IPv6 header. Although the actual number of the size of the packet is usually two-bytes long, changing this field can become a problem for the router when verifying the actual size of the packet; therefore this field cannot be used for covert channels.

Next Header Field (8-bits) This field indicates the upcoming extension header, transport protocol, or other protocol. The value of the Next Header Field is necessary to preserve or

else the entire packet is useless (unless its a Raw IP packet). This field cannot be used for covert channels. Hop Limit Field (8-bits) The TTL field used in IPv4 was renamed to Hop Limit Field, essentially its the same field; therefore no covert channels can be used. Source and Destination IP Address Field (128-bits) Contains the IP of the source and destination as the name indicates, changing this field will be redundant to communication between two systems. No covert channels can be used.

So far in IPv6 only the Class and Flow Label Fields can be used for covert channels, but there is more. IPv6 no longer supports fragmentation leaving more possibilities for redundancies within headers of transport layer protocols such as TCP and UDP. IPv6 can also include one or more extension headers that can be added before the transport layer protocols are included. The only extension header that can possibly be used for covert channels is the Destination Options Extension Header. This extension provides support options for packet handling and preferences; this extension also makes room for future proprietary or standards-based communication; further, if placed after the ESP header, this header is encrypted. This field can be used to store anything at the moment and the size is variable, which means entire ASCII sentences can be stored undetected. Overall since IPv6 is relatively new, much of the headers are used for future development, if used today they can be used to store hidden information sometimes even encrypted. Like IPv6, UDP also contains a small amount of headers compared to TCP. These headers are: source port number, destination port number, UDP length, and UDP checksum. Although the UDP checksum field is optional, it is used to calculate the hash for the UDP header

(excluding the UDP checksum) to see if its legit, if tampered with, routers will discard the packet. Now I know why Kamran Ahsan never included UDP in his research, none of the fields can be used for covert channels. The routing protocols stand at the application layer of the OSI model with their own distinctive, many of the headers are reserved and must be 0 and leaves little redundancy options. RIPv1's headers cannot be used as covert channels as their all necessary. RIPv2 however encompasses the Address Family Identifier and Next Hop. The Address Family identifier is a 15bit field, if the field contains 0x02, the next 20 bytes contain a route entry, thats IF it contains 0x02, if not it may be used for hidden messages. RIPv1 also contains this field but it is used to define the protocol that is using instead. Another routing protocol,the open shortest path first protocol (OSPF), is the premier link-state routing used on TCP/IP, its purpose is to find the fastest route to its destination. Unfortunately, all the 8 header fields OSPF uses are necessary and none can be used as covert channels. In conclusion, any protocol residing in the OSI model contains headers, sometimes the headers fields may be necessary, other times the protocol has no use for them. As far as IDS's and Firewalls go, this kind of stenography is undetectable unless special software specifically looking at headers is in use. Although they can be hard to detect, that does not mean it can be suspicious for example, on IPv4 why would you have fragmentation on with a packet size very low the MTU limit? On IPv6 having a very high priority packet set by the Class Field with very little data can arouse suspicious as well; that is why when manipulating header fields is important to know exactly why that header exists. To add, some of the stego scenarios described only work on LAN environments since the MTU is known, others have no limit. With trillions of packets in an average network discovering this one packet is an unlikely process.

Sources:
[1] Ahsan, K. (2002). Covert Channels Analysis and Data Hiding in TCP/IP. Retrieved August 8, 2009, from gray-world Web site: http://gray-world.net/papers/ahsan02.pdf

[2] Ahsan, K. (2002). Practical Data Hiding in TCP/IP. Retrieved August 8, 2009, from University of Toronto Web site: http://wwwiti.cs.unimagdeburg.de/iti_amsl/acm/acm02/ahsan_kundur.pdf

[3] Ortega, Juan (2009). Sample TCP/IP Stego Server. Retrieved August 8, 2009, from SDF Web site: http://replay.freeshell.org/scripts/stegoserver.txt

[4] Chappell, L.A., & Tittel, E. (2007). Guide to TCP/IP. Boston, Massachusetts: Thomson Course Technology.