Covert Channels

3380-1 (CFNOC/DND CIRT) 30 Aug 06 NOSO I&W ANALYSIS COVERT CHANNELS: CLOAK AND DAGGER IN THE INFORMATION AGE INTRODUCTION 1. (U) In the modern information age, network security solutions of various types are now in widespread use; as a result of this, savvy attackers are now utilizing covert communication channels in order to bypass security measures, evade detection and exfiltrate/infiltrate information. 2. (U) In previous decades, much attention was paid to the threat of storage and timing covert channels as they were implemented on an individual system1. However, with the evolution of networking and the growth of large interconnected networks, covert channels based upon existing network protocols gradually become prevalent. 3. (U) Though this document will touch on the historical aspects of systemic storage and timing covert channel techniques, its primary focus will be on networkbased covert channels and the possible countermeasures that can be implemented to defend the organization's networks. AIM 4.

(U) The purpose of this report is fourfold: a. to acquaint the reader with the basic concepts of covert communication channels; b. to demonstrate the methods by which covert communication channels may be implemented; c. to recommend solutions to detect the presence of covert channels on the organization's networks; and d. to recommend countermeasures that will prevent the implementation of covert channels.

1

System - A framework of software and hardware designed to allow software programs to run; also often referred to as a "platform" or "host".

1

DISCUSSION Covert Channels 101 5. (U) A covert channel is basically defined as a clandestine information flow that violates the security policy of a either a system or network; the concept of the covert channel was introduced in 1973 by Dr. Butler Lampson in a paper discussing program data containment on standalone systems. A simple covert channel is demonstrated in Annex A. 6. (U) Covert channels are considered a threat to modern information infrastructures as they can be utilized to facilitate information leaks, synchronize attacks on a system or divert a system from its intended use. 2 7. (U) Depending on the intent of the party that has implemented the covert channel, the channel can be used for several purposes in addition to data exfiltration ad demonstrated in Annex B. 8. (U) Although consensus indicates that it is impossible to eliminate the threat posed by covert channels, detection of covert channels and mitigation of their impact is more critical today than ever due to the development of network based covert channels and the prevalence of large interconnected networks. 3 9. (U) In 1985 the National Computer Security Centre4, a child organization of the National Security Agency, published the "Orange Book" (DoD 5200.280-STD)5 one of many in the so-called "Rainbow Series"6 (since superceded by the "Common Criteria7) - which built upon the foundation laid by Dr. Lampson and provided analysis, containment and system accreditation procedures. 10. (U) Despite its advances, the Orange Book dealt exclusively at the system level and did not address networks specifically; despite its limited scope, it did introduce the two basic scovert channel methodologies: a. storage based covert channels - which utilize a system resource in order to store compartmentalized data that can then be accessed by an unauthorized third party; and b. timing based covert channels - which modulate the response time of a system in such a manner so as to allow for the transmission of information to another process.

2 3 4

5

6

7

Loïc Hélouët et al. "Covert Channels Detection in Protocols Using Scenarios". Ibid, Loïc Hélouët et al. National Computer Security Center - a child organization of the National Security Agency, was established in 1981 and is responsible for testing and evaluating computer equipment for use in high security and/or classified applications. Department of Defence. "DoD 5200.280-STD: Department of Defence Trusted Computer System Evaluation Criteria. Rainbow Series - a series of computer security standards published by the United States government in the 1980s that describe a process of evaluation for trusted systems. Common Criteria - an international standard (ISO/IEC 15408) for computer security.

2

11. (U) In recent years, the widespread deployment of large interconnected networks and the exploitation of protocols utilized in their information flows resulted in the naissance of a new threat - network based covert channels. This new form of covert channel, due to its very nature and modern society's dependence on network based infrastructure, is far more pervasive than the system based covert channels of auld. 12. (U) Unlike its antediluvian counterparts, which were utilized to convey compartmentalized information between processes on a single system, network based protocols utilize existing data fields in standard protocols to convey information covertly across a network from one system to another. This differentiation makes them inherently dangerous to the highly networked infrastructure of the organization. The Wolf in Sheep's Clothing - Network Based Covert Channels 13. (U) As mentioned above, network based covert channels utilize either valid data fields in existing communication protocols (IP, TCP, ICMP, HTTP and DNS) or a temporal variance in order to convey data from a compromised system to another "hostile" system. 14. (U) A network based covert channel's degree of obfuscation and level of utility of is dependent on the manner in which the bits in the protocol headers are manipulated. As detailed by David Llama in one of his papers: 8

...we identify two criteria. Whether or not the covert channel can be created without violating the legal framework of the protocol and whether the channel can be created within the constraints of actual implementations of the protocol. This possibility arises because protocol implementations and their specifications are not identical. Consequently, covert channels could follow the legal definition of the filed to be manipulated but might not work at the implementation level, or they could not strictly follow the legal definition but work at the implementation level. This in turn gives four types of covert channel:

• Legal and implementation supported: Will be difficult to detect and have a high utility.

• Legal and are not implementation supported: Will be difficult to detect but have limited utility.

• Illegal but are implementation supported: Will be easier to detect and have a high utility.

• Neither legal nor implementation supported: Will be easier to detect and have limited utility.

8

David Llamas et al. "An Evaluation Framework for the Analysis of Covert Channels in the TCP/IP Protocol Suite".

3

15. (U) In their report regarding covert channels, Marc Smeets and Matthijs Koot identified two qualities that must be considered in addition to those above when implementing a viable covert channel: 9

• Plausibility: Use of a covert channel should be invisible to both systems and

humans. For example, it’s usage should not influence the regular workings of the carrier protocol and should not result in obvious anomalies in either spatial (packet size, bandwidth usage) or temporal (rate of occurrence) properties of it’s carrier in the target network.

• Robustness: The covert channel should be reliable. For example, an error

detection and correction facility should be available to cope with latency and congestion issues, and the reliability should not depend on assumptions of sequence, path or time of packet delivery.

16. (U) Obviously, maximum obfuscation and high utility should be the ultimate goal of any covert channel design. In addition, those covert channels that have a high utility will: a. be the most flexible in regards to the type of data that can be conveyed; b. will generally have a higher bandwidth capacity than those with limited utility; and c. provide more diverse obfuscation options. 17. (U) Failure to consider these two qualities and Llamas' criteria when implementing a covert channel may cause the implementation to degrade, fail or become easily detectable by standard network security facilities. Network Based Covert Channels - Implementations 18. (U) In their aforementioned report, Smeets and Koot described the four possible implementations of network based covert channels based loosely upon the original classifications in the Orange Book:10

• Value-based spatial channel (storage): This class encodes data within a spatial container11. Example: Covertly communicating the letter ‘A’ by using it’s 32 bit representation from a Unicode character set as a TCP Initial Sequence Number.

• Transition-based spatial channel (storage): This class encodes data by

representing it as changes between spatial containers, therefore using at least N+1 spatial containers to encode N characters. Example: Covertly communicating the letter ‘A’ by crafting one TCP packet with the source port set to 1234’,waiting, and then crafting a second TCP packet with it’s source port set to ‘6464’ (the transition from ‘1234’ to ’6464’ would represent the character ‘A’).

9

Marc Smeets et al. "Research Report: Covert Channels". Ibid, Marc Smeets et al. 11 Spatial container - A field of arbitrary length within a protocol header used to contain data of a specific type, e.g. TCP flag field, IPID field, etc. 10

4

• Value-based temporal channel (time): This class encodes data by

modulating the occurrence of events (time dimension). Example: Using network packet arrival times or packet arrival order to implement a binary channel.

• Transition-based temporal channel (time): This class encodes data by

modulating intermediate delays on the occurrence of events, therefore using N + 1 events to encode N characters. Example: using network interpacket arrival times (jitter12) to implement a binary channel. Network Based Covert Channel Methodologies - Timing Channels

13 14

19. (U) Unlike storage based covert channels which rely upon the manipulation of storage containers within existing protocol fields, timing channels encode information by means of a temporal variance (e.g. packet inter-arrival timings) in a communication channel and are exceedingly more difficult to detect. 20. (U) The two types of covert timing channels include in common use at this time are: a. packet sorting - the order of packet arrival is varied to facilitate the encoding of the information within the covert channel; and b. presence based - the reception or absence of packets within specific time intervals is used to facilitate the encoding of the information within the covert channel. 21. (U) The packet sorting method is self explanatory; the remainder of the this report will deal with the more complex and more covert presence based timing channel. 22. (U) Timing channels make use of a prearranged timing schema and protocol to implement the channel. During each time interval the sender either transmits a single packet or remains silent. The receiving party monitors the circuit during each timing interval to determine whether or not a packet was received. The result is a binary code in which "1" represents a received packet and "0" represents the absence of a packet; this is demonstrated in Annex J. 23. (U) The data, prior to transmission, is subdivided into smaller blocks of binary data, referred to as frames.15 While all the frames are of equal length, the actual length, as well as the interval between frames, is influenced by the parameters of the encoding schema and the network over which the data is being conveyed.

12

13 14 15

Jitter - a fluctuation in a network transmission; this term always referring to some offset of time and space from the norm (e.g. in a network transmission, jitter would be a bit arriving either ahead or behind a standard clock cycle or a variability in round trip times). Sweety Chauhan. "Project Report: Analysis and Detection of Network Covert Channels". Serdar Cabuk et al. "IP Covert Timing Channels: Design and Detection". Frame - a fixed block of data consisting of the information being conveyed and all necessary system overhead (encryption, protocol control information, etc.); individual frames are delimited by header and trailer flags that "frame" each block.

5

24. (U) As with all binary communication circuits, the final interpretation of the bit stream is determined by the prearranged coding and framing schema. In addition to the information stream, additional overhead bits can be added to the frame for: a. error detection - parity bits16 or a CRC17 is inserted into the frame in order to implement an error detection facility; b. error correction - additional bits can be added to the frame in order to provide an error correction facility (e.g. Hamming Code18 or ReedSolomon Code19); c. synchronization - the very nature of a timing based covert channel requires an accurate timing reference - a bitstream can be made self-timing using techniques such as Manchester20 encoding; and d. encryption - the data stream can be encrypted in order to provide an additional layer of privacy/obfuscation. 25. (U) The most common implementation of a covert timing channel is IP based; such a channel can be configured to run on any application port. However, it is worth noting that the choice of protocol used to convey the channel can drastically affect the degree of obfuscation; this is due primarily to the unique traffic pattern usually generated by covert channel activity. 26. (U) In addition to the decision regarding the protocol used to convey the covert channel's information, several other factors that can affect channel throughput must be taken into consideration: a. network Conditions - traffic congestion and jitter can adversely affect the throughput of a covert channel; b. coding schema complexity - use of inefficient coding schema can significantly degrade the performance of a covert channel; c. endpoint processing capabilities - endpoint bottlenecks caused by heavy traffic loads can result in a delay in the processing of packets which will in turn degrade the covert channel's performance; and d. programming language portability - The proper synchronization of the channel depends directly on the correct and consistent functionality of the subroutines and libraries used to implement the channel. 16

17

18

Parity - a technique of checking whether data has been lost that involves the addition of a parity bit to a group of information bits; this bit is used only for the purpose of identifying whether the information bits have arrived intact. CRC - "Cyclic Redundancy Check"; a type of hash function used to produce a checksum against a block of data in order to implement an error detection facility. Hamming Code - a linear error correcting code which can detect single and double-bit errors and correct single-bit errors.

19

20

Reed-Solomon Code - an extremely robust detection block based error detection/correction code that utilizes polynomial over sampling to facilitate advanced error correction. Manchester Encoding - a synchronous communication encoding technique utilized to implement channel self-timing; this is accomplished by encoding both the timing information (clock) and data into a single bit stream.

6

27. (U) All four of these factors can affect the synchronization, maximum throughput and available bandwidth of a timing based channel; they must therefore be carefully considered when designing a such an implementation. Failure to consider these factors could contribute to the degradation/failure of the channel and/or reduce the effectiveness of the obfuscation. 28. (U) As will become evident when network based covert storage channels are discussed below, the technical issues that must be addressed in order to successfully implement a timing channel are considerable. However, timing based channels offer several advantages over storage based channels: a. timing based channels, when properly implemented, are considerably more difficult to detect than storage based channels; b. the ability to easily implement a self timing synchronous communication channel allows greater channel throughput; and c. the option to implement forward error detection and correction offers the potential for greater data integrity. Network Based Covert Channel Methodologies - Storage Channels 29. (U) As mentioned previously, network based covert storage channels utilize valid data fields in various protocols to convey the channel's information; each of the protocols commonly utilized this type of channel will now be addressed individually. These include: a. IP header - ToS, IPID, IP flags, IP fragment offset, IP options and padding fields; b. TCP header - sequence number and acknowledgment number fields; c. ICMP header - data field protocol tunnelling utilizing various techniques, protocol obfuscation; d. HTTP headers - general-header, request-header, entity header and entity body fields; and e. DNS headers - Field ID, QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT, QNAME and NAME fields.

7

Covert Channels in IP

21 22

30. (U) For the context of this paper, only IPv4 will be addressed as IPv6 has not been implemented on the organization's networks as of this writing. As demonstrated in Annex C, several fields exist within the IP header in which covert channels can be implemented:

•

Type of Service - The eight bits within the IP ToS field are rarely used with original semantics and modern networks seldom make use of the field. Considering this, up to eight bits of data could conceivably be concealed in this field.

•

IP Identification - The 16 bit Identification field is used to uniquely identify an IP datagram within a flow of datagrammes sharing the same source and destination. The value for this field should be chosen randomly by the source, but can also contain a non-random value without disrupting the IP mechanism; this allows 16 bits of data to be concealed in this field.

•

IP Flags - The 3 bit flag field is an optional field in the IP datagram and is used to handle fragmentation issues. As explained in Yogi Mehta's paper23, the "Don’t Fragment" (DF) flag may actually be considered to be a redundant bit and thus may be set or unset without any influence on the IP delivery process. Considering this, it is a possible carrier for covert channels, even though it can only hold one bit per IP packet.

•

IP Fragment Offset - A covert channel may be implemented within the IP fragment offset field of the IP header by modulating the size of the fragments originated by a host and thus thereby modulating the fragment offsets.

•

IP Options - The 24 bit options (byte 11 and MSB24 of byte 12) field is optional for each IP datagramme but are unnecessary for the most common communications; as detailed in RFC 791, the options include provisions for timestamps, security, and special routing. Despite the fact that some valid values for this field are specified in RFC 1700, this field may still be used to implement a covert channel.

•

IP Padding - The 8-bit Padding field (LSB25 of byte 12) is used to pad the Options a to 32-bits block; this field should only contain zeros but could easily be used to implement a covert channel.

21

Marc Smeets et al, op. cit.

22

Steven Murdoch et al. "Embedding Covert Channels into TCP/IP".

23

Yogi Mehta. "Communication Over the Internet Using Covert Channels". MSB - Most Significant Byte; the bit position in a binary number having the greatest value. The MSB is sometimes referred to as the left-most bit. LSB - Least Significant Bit; the bit position in a binary number having the least value. The LSB is sometimes referred to as the right-most bit.

24

25

8

Covert Channels in TCP

26 27

31. (U) As was the case with the IP header, the TCP header contains fields in which a covert channel may be implemented as demonstrated in Annex D:

•

TCP Sequence Number - This field is used as a ID number to facilitate packet ordering on arrival and aid reliability using retransmit requests. The first (SYN) packet of a TCP session contains a random initial sequence number (ISN). The receiving host typically acknowledges its receipt by responding with a SYN/ACK packet, using ISN+1 as an ACK number. However, this field can also contain a non-random value without disrupting the TCP mechanism; a covert channel utilizing up to 32 bits of data can therefore be easily implemented.

•

TCP Acknowledgement Field - The 32 bit acknowledgment number field (bytes 9-12) is used to acknowledge receipt of a TCP packet to it’s source. This field must always contain the sequence number of the sender, incremented by 1; it has been demonstrated, however, that the sender IP of a TCP packet can be spoofed, making the receiving host acknowledge to an arbitrary host with the (incremented) input bytes encoded into this field.

•

TCP Timestamp - The timestamp option consists of two 32 bit fields - the TS value and the TS echo reply. A covert channel may be implemented in this field by modulating the LSB of the TCP timestamps transmitted by a host as described in the paper by John Giffin et al 28.

Covert Channels in ICMP

29

32. (U) As demonstrated in Annex E, the ICMP protocol has a large data field, which may be utilized to implement a covert channel. Several tools/methods are available that enable the implementation of ICMP-based covert channels:

•

Ptunnel - Ptunnel is an application that allows you to reliably tunnel TCP

•

Icmptx - Icmptx is an application that allows any IP based stack to be tunneled using ICMP.31

•

Skeeve - Skeeve utilizes ICMP packets and spoofing technology to create a data channel in order to tunnel TCP connections; this is accomplished by IP Protocol field of incoming TCP packets to ‘1’ to make them look like ICMP packets.32

connections to a remote host using ICMP echo request and reply packets.30

26

Marc Smeets et al, op. cit.

27

Steven Murdoch et al, op. cit.

28

John Giffin et al. "Covert Messaging in TCP".

29

Marc Smeets et al, op. cit.

30

Daniel Stødle. "Ping Tunnel - For Those Times When Everything Else is Blocked".

31

Thorner Gil. "ICMPTX (IP-over-ICMP) HOWTO".

32

Grayworld.net Team. "Skeeve" (PoC tool).

9

•

Loki - Loki is a client/server program enables a user to tunnel traffic within an ICMP packet.33

Covert Channels in HTTP

34

33. (U) As demonstrated in Annexes F and G, HTTP response and request header fields can be manipulated to implement a covert channel:

•

HTTP Request General, Response and Entity Headers - HTTP request messages may contain multiple headers. Common examples include “UserAgent:”, “Referrer:” and “Cookie:”. Covert channels may be implemented within these headers in order to convey arbitrary data.

•

HTTP Request Entity-Body - The Entity-Body normally is only present in POST requests as it has no use for other types of requests. However, RFC 1945 doesn’t explicitly exclude this field from being present in other requests. Covert channels may be implemented in this field to convey data through an Entity-Body in any request type (POST, GET, etc.).

•

HTTP Response General, Response and Entity Headers - HTTP response messages may contain multiple headers; common examples include Server:”, “Content-Type:” and “Expires:”. Covert channels may be implemented in the same way as request headers; in addition, combining this field with one of the aforementioned fields in HTTP request messages allows creation of a bidirectional communication channel.

•

HTTP Response Entity-Body - Except in response to HEAD-requests, the Entity-Body is always present in HTTP responses. Again, combining this field with one of the aforementioned fields in HTTP request messages allows creation of a bidirectional communication channel.

Covert Channels in DNS

35

34. (U) As demonstrated in Annex H, DNS contains several header fields that may be manipulated to implement a covert channel:

•

Field ID - The 16-bit Identification field is meant to keep track of the different queries posed. An algorithm could be developed that uses a smaller space for identifying individual queries, so that the remaining space may be used to hide up to 16 bits of data.

•

QDCOUNT - This field is meant to specify the amount of entries in the questions section that appears after this header. A hostile entity exercising control over a rogue DNS server can use this field to hide up to 16 bits of data.

33

Stephen Northcutt et al. "Intrusion Signatures and Analysis".

34

Marc Smeets et al, op. cit. Ibid, Marc Smeets et al.

35

10

•

ANCOUNT - The 16-bit ANCOUNT field is meant to specify the amount of resource records in the answer section that appears after this header. A hostile entity exercising control over a rogue DNS server can use this field to hide up to 16 bits of data.

•

NSCOUNT - The 16-bit NSCOUNT field is meant to specify the amount of name server resource records entries in the answer section that appears after this header. A hostile entity exercising control over a rogue DNS server can use this field to hide up to 16 bits of data.

•

ARCOUNT - The 16-bit ARCOUNT field is meant to specify the amount of entries in the questions section that appears after this header. A hostile entity exercising control over a rogue DNS server can use this field to hide up to 16 bits of data.

•

QNAME - This field represents the string of text entered as the actual DNS query and should be in the form of a FQDN36. The QNAME field is limited to the maximum length of a FQDN, thus an adversary can use up to 255 bytes so long as it complies to the limit of 63 octets per label in the FQDN. Depending on the various implementations of the DNS protocol, a covert channel can ignore these limits and use larger packets. Every answer to a query consists of the message and query headers, appended with the answer headers as demonstrated in Annex I; this message is the same for the answer, authority and additional sections.

•

NAME - This field represents the a FQDN to which the resource record pertains. As with the QNAME field in the query message, the NAME field also has to comply to the rules of a FQDN.

35. (U) In the case of the four *COUNT DNS fields, the hostile entity controlling the rogue DNS server must add the proper amount of queries and answers in the messages after this header as marked in the QDCOUNT, ANCOUNT, NSCOUNT and ARCOUNT fields. 36. (U) By employing a custom algorithm, the hostile entity can use these fields as a carrier for covert channels instead of only using it to point out how many queries or answers will be after this header; this can be accomplished as long as the number of queries and answers matches these fields. 37. (U) The DNS protocol has multiple potential carriers for covert channels. Tools that make use of some of these carriers have been around for some time now; one of the more popular tools, designed by Dan Kaminsky, is "Ozyman"37. In its current implementation, data is hidden within QNAME and NAME fields, by mimicking queries of DNS CNAME and TXT records.

36

37

FQDN - "Fully Qualified Domain Name"; an unambiguous domain name that specifies the node's absoloute position in the DNS tree hierarchy. Dan Kaminsky. "Attacking Distributed Systems - The DNS Case Study".

11

Network Based Covert Channels - Countermeasures 38. (U) Despite the insidious nature of covert channels, countermeasures are readily available that can mitigate the threat posed to the integrity of the organization's networks. Various countermeasure techniques for each of the protocols and methods discussed earlier will be touched on below. Covert Channel Countermeasures - Timing Channels 39. (U) Unfortunately, deployment of timing channel detection solutions and countermeasures against is a technically daunting task usually requiring the engineering of custom detection software/appliances which are beyond the scope of this paper. 40. (U) This being stated, several non-commercial solutions have been proposed in several whitepapers; these include: a. deployment of a PQS (Process Query System) based solution to facilitate and partially automate covert timing channel detection38 (the Dartmouth College PQS analysis screen is demonstrated in Annex K); and b. development of a new engineering project to produce proprietary detection solutions for eventual deployment on the organization's networks. 41. (U) Unfortunately, as of this writing, research has failed to yield any results in regards to commercial solutions specifically designed to perform detection of covert timing channels. Covert Channel Countermeasures - IP

39

42. (U) The following countermeasures are recommended to counter IP based covert channels: a. analysis of IPIDs to recognize possible patterns; (or anomalies, if it's possible to establish a trusted baseline); b. use of an IP-aware traffic normalizer to sanitize the IP DF bit to either 0 or 1; c. use of an IP-aware traffic normalizer40 to sanitize the IP Padding bits to 0; d. create a baseline of IP traffic patterns and monitor for anomalies; and e. define a standard policy on the use of IP ToS field and Option tags and enforce that policy using an IP-aware traffic normalizer. 38

Vincent Berk et al. "Covert Channel Detection Using Process Query Systems".

39

Marc Smeets et al, op. cit. Traffic Normalizer - A device that sits between the internet and an internal network and removes "ambiguities" from the traffic flow.

40

12

Covert Channel Countermeasures - TCP

41

43. (U) The following countermeasures are recommended to counter TCP based covert channels: a. employ a traffic analyzer which is able to recognize patterns in failing and uncompleted TCP-handshakes (e.g. TCP-stateful firewalls); b. route all TCP traffic through a proxy device which establishes a TCPconnection to the endpoint on behalf of the originator but utilizes its own ‘trusted’ sequence number generator; and c. create a baseline of TCP traffic patterns and monitor for anomalies. Covert Channel Countermeasures - ICMP

42

44. (U) The following countermeasures are recommended to counter ICMP based covert channels: a. block outgoing ICMP echo request/response traffic to the Internet; b. in lieu of blocking outgoing ICMP echo request/response traffic, implement a throttle tool to limit such traffic; c. analysis of the the payload field of ICMP traffic for known magic numbers, such as ‘0xD5200880’ which is a default for ptunnel traffic; d. use of a traffic normalizer to sanitize the ICMP Header Data bits to 0; and e. define a policy on the use of ICMP headers/packets and enforce that policy through a ICMP-aware traffic normalizer.

41

Marc Smeets et al, op. cit.

42

Ibid, Marc Smeets et al.

13

Covert Channel Countermeasures - HTTP

43

45. (U) The following countermeasures are recommended to counter HTTP based covert channels: a. define a policy on the use of HTTP headers and enforce that policy using an HTTP-aware proxy; b. throttle outbound and inbound HTTP traffic using the metrics suggested in 44; c. when using a HTTPS proxy, disallow CONNECTs to ports other than 443; d. create a baseline of HTTP traffic patterns and monitor for anomalies; and e. employ URL whitelisting/blacklisting as either a preventive or reactive measure. Covert Channel Analysis & Countermeasures - DNS

45

46. (U) DNS analysis can be difficult at the best of times. However, several approaches are available to identify a covert channel within the DNS protocol. Some points to consider when attempting to identify a DNS-based covert channel are as follows: •

Is the queried DNS server off-site?

•

Is the queried DNS server only used by one or two hosts in the network?

•

Does the length of queries and responses outreach the average length?

•

Are the queries and responses real words?

•

Do the queries and responses contain mixed cases?

•

Is there excessive use of a particular record that normally isn’t used (e.g. TXT)?

47. (U) Although a small number of positive answers to the points above shouldn’t make a host suspect as a rule, it should be clear that with the number of questions answered in the affirmitive, the likeliness of a covert channel existing in the DNS traffic flow increases.

43 44 45

Marc Smeets et al, op. cit. Borders, Kevin et al. "Wire Tap: Detecting Covert Web Traffic". Marc Smeets et al, op. cit.

14

48. (U) Should the next two points be answered in the negative, it is highly likely that one is dealing with a covert channel: •

Do replayed lookups through that DNS server provide the same result?

•

Do replayed lookups through another DNS server provide the same result?

49. (U) The following countermeasures are recommended to counter DNS based covert channels which depend (either partially or fully) on crafting DNS headers or packets: a. block outbound queries to rogue DNS servers (i.e. use a hardened forwarding caching server located on the intranet, or disallow querying non-local domains at all); b. create a baseline of DNS traffic patterns and monitor for traffic anomalies; and c. implement a custom IDS ruleset that will alarm on DNS TXT strings that both exceed a certain length and meet some to the criteria mentioned above. 46 CONCLUSIONS & RECOMMENDATIONS 50. (U) Network based covert communication channels present a clear and present danger to the integrity of the organization's networks. Considering this, covert channel countermeasures, such as those discussed above, should be implemented as soon as the technical/fiscal means become available. 51. (U) Any questions regarding this I&W report may be addressed to the undersigned.

//signed// E.L. Mac Daibhidh, CD Cpl DND CIRT Special Operations Analyst 945-7747 Attachments: References Annexes A-K

46

A rule for the detection of TXT based DNS tunnelling already exists in Cisco IDS' rule set (SID 6066.0/TID 4249) but visualization of this signature is current suppressed in NSM5.

15

References Author unknown. “RFC791 – Internet Protocol DARPA Internet Program Protocol Specification”. September 1981. Accessed on 19 August 2006. http://www.faqs.org/rfcs/rfc791.html. Author unknown. “RFC793 – Transmission Control Protocol DARPA Internet Program Protocol Specifications”. September 1981. Accessed on 19 August 2006. http://www.faqs.org/rfcs/rfc793.html Berk, Vincent et al. "Covert Channel Detection Using Process Query Systems". Date unknown. Accessed on 12 August 2006. www.pqsnet.net/publications/ CovCh_Flocon05_pres.pdf. Berk, Vincent et al. "Detection of Covert Channel Encoding in Network Packet Delays". November 2005. Accessed on 05 August 2006. http://www.ists.dartmouth.edu/ library/149.pdf

Borders, Kevin et al. "Wire Tap: Detecting Covert Web Traffic". Date unknown. Accessed on 24 August 2006. http://www.eecs.umich.edu/aprakash/papers/ borders-prakash-ccs04.pdf. Cabuk, Serdar et al. "Covert Timing Channels: Design and Detection". 2005. Accessed on 24 August 2006. http://www.cs.jhu.edu/~fabian/courses/CS600.624/ slides/week2.pdf. Cabuk, Serdar et al. "IP Covert Timing Channels: An Initial Exploration". 2004. Accessed on 24 August 2006. www.cs.georgetown.edu/~clay/research/pubs/ cabuk.ccs2004.pdf. Castro, Simon. "Covert Channel and Tunnelling Over the HTTP Protocol Detection". November 2003. Accessed on 09 August 2006. http://www.gray-world.net/ projects/papers/html/cctde.html. Castro, Simon. "Covert Channel Tunneling Tool Manual". June 2003. Accessed on 10 August 2006. http://www.entreelibre.com/cctt/man_en.html. Chauhan, Sweety. "Project Report: Analysis and Detection of Network Covert Channels". December 2005. Accessed on 05 August 2005. www.cisa.umbc.edu/ courses/cmsc/444/fall05/studentprojects/sweety.pdf. Cooper, Robert et al. "The Covert Channel Problem". August 1996. Accessed on 26 August 2006. http://www.cs.unb.ca/tech-reports/files/TR96_111.pdf. Denning, Dorothy. "An Intrusion Detection Model". February 1987. Accessed on 10 August 2006. http://www.cs.georgetown.edu/~denning/infosec/ids-model.rtf. Department of Defence. "DoD 5200.280-STD: Department of Defence Trusted Computer System Evaluation Criteria. December 1985. Accessed on 29 July 2006. csrc.nist.gov/publications/history/dod85.pdf. Dubrawsky, Ido. "Data Driven Attacks Using HTTP Tunnelling". August 2004. Accessed on 12 August 2006. http://www.securityfocus.com/infocus/1793.

i

Giani, Annarita et al. "Data Exfiltration and Covert Channels". Date unknown. Accessed on 10 August 2006. http://www.pqsnet.net/publications/ Giani_SPIE2006.pdf. Giffin, John et al. "Covert Messaging in TCP". 2002. Accessed on 24 August 2006. http://www.eecs.harvard.edu/~greenie/tcpcovertchannels.ps. Gil, Thomer. "ICMPTX (IP-over-ICMP) HOWTO". September 2004. Accessed on 23 August 2006. http://thomer.com/icmptx. Gil, Thomer. "NSTX (IP-over-DNS) HOWTO". November 2005. Accessed on 23 August 2006. http://thomer.com/howtos/nstx.html. Grayworld.net Team. "Skeeve" (PoC tool). June 2004. Accessed on 23 August 2006. http://gray-world.net/poc_skeeve.shtml. Gregorio-DeSouza, Ian et al. "Detection of Complex Cyber Attacks". Date unknown. Accessed on 12 August 2006. http://www.pqsnet.net/publications/ DeSouza_SPIE2006.pdf. Harris, Shon. "CISSP All-in-One Exam Guide". Third Edition. Emeryville: McGraw-Hill Osbourne Media. 2003. Hélouët, Loïc et al. "Covert Channels Detection in Protocols Using Scenarios". Date unkown. Accessed on 29 July 2006. http://www.labri.fr/~zeitoun/research/articles/ confs/03-SPV/spv03.pdf. Hoglund, Greg et al. "Rootkits: Subverting the Windows Kernel". First edition. Boston: Addison Wesley Professional. 2005. Kaminsky, Dan. "Attacking Distributed Systems -The DNS Case Study". 2003. Accessed on 22 August 2006. http://www.doxpara.com/slides/ BH_EU_05-Kaminsky.pdf. Kaminsky, Dan. "OzymanDNS" (tool). 2003. Accessed on 22 August 2006. http://www.doxpara.com/ozymandns_src_0.1.tgz Lampson, Butler. "A Note on the Confinement Problem". Communications of the ACM, Volume 16 Issue 10. October 1973. Accessed on 16 August 2006. http://research.microsoft.com/~lampson/11-Confinement/Word.doc. Llamas, David et al. "An Evaluation Framework for the Analysis of Covert Channels in the TCP/IP Protocol Suite". June 2005. Accessed on 1 August 2006. http://www.davidllamas.org/Portals/2/0507-ECIW/0507-ECIW-Paper.pdf. Llamas, David et al. "Covert Channel Analysis and Detection with Reverse Proxy Servers using Microsoft. Windows". June 2004. Accessed on 4 August 2006. http://www.davidllamas.org/Portals/2/0406-ECIW/0406-ECIW-Paper.pdf. Llamas, David et al. "Covert Channels in Internet Protocols: A Survey". June 2005. Accessed on 4 August 2006. http://www.davidllamas.org/Portals/2/0506-PGNET /0506-PGNET-Paper.pdf.

ii

MacLure, Stuart et al. "Hacking Exposed: Network Security Secrets and Solutions". Fourth edition. Berkeley: McGraw-Hill Osborne Media. 2003. Mehta, Yogi. "Communication Over the Internet Using Covert Channels". July 2005. Accessed on 20 August 2006. http://www.cs.drexel.edu/~vp/CS743/Papers/ ypm23-hw2.pdf. Mockapetris, P. “RFC 1035 - Domain Names Implementation and Specification”. November 1987. Accessed on 19 August 2006. http://www.faqs.org/rfcs/rfc1035.html. Murdoch, Steven et al. "Covert Channels in TCP/IP: Attack and Defence". December 2005. Accessed on 7 August 2006. http://www.cl.cam.ac.uk/~sjm217/talks/ ccc05covert-tcp.pdf. Murdoch, Steven et al. "Embedding Covert Channels into TCP/IP". July 2005. Accessed on 29 July 2006. http://www.cl.cam.ac.uk/~sjm217/papers/ ih05coverttcp.pdf. Northcutt, Stephen et al. "Intrusion Signatures and Analysis". First edition. Indianopolis: New Riders Press. 2001. Postel, J. “RFC792 – Internet Control Message Protocol”. September 1981. Accessed on 19 August 2006. http://www.faqs.org/rfcs/rfc792.html. Postel, J. et al. "RFC1700 - Internet Numbers". October 1994. Accessed on 21 August 2006. http://www.faqs.org/rfcs/rfc1700.html. Rutkowska, Joanna. "The Implementation of Passive Covert Channels in the Linux Kernel". 2004. Accessed on 20 August 2006 http://www.invisiblethings.org/papers/ passive-covert-channels-linux.pdf. Rutkowska, Joanna. "Concepts for the Stealth Windows Rootkit". September 2003. Accessed on 20 August 2006. http://www.invisiblethings.org/papers/ chameleon_concepts.pdf. Smeets, Marc et al. "Research Report: Covert Channels". February 2006. Accessed on 13 August 2006. http://www.os3.nl/~mrkoot/courses/RP1/researchreport_200602-15_final2.pdf. Stevens, W.R. "TCP/IP Illustrated Volume 1: The Protocols". First edition. Boston: Addison Wesley Professional. 1994. Stødle, Daniel. "Ping Tunnel - For Those Times When Everything Else is Blocked". May 2005. Accessed on 22 August 2006. http://www.cs.uit.no/daniels/PingTunnel. Van Horenbeeck, Maarten. "Entity Tags as an HTTP Covert Channel". June 2006. Accessed on 12 August 2006. http://www.daemon.be/maarten/etagtunnel.html. Wagner, Aaron et al. "Information Theory of Cover Timing Channels. 2003. Accessed on 05 August 2006. http://www.eecs.berkeley.edu/~ananth/2005+/Aaron/ VA_ArmeniaNew.pdf.

iii

Annex A - Simple Covert Channel

47

The diagram above demonstrates a rudimentary covert channel that has been implemented by a hostile party. The workstation on the internal network has been compromised and a covert channel has been brought online by a Trojan. The firewall allows certain protocols (e.g. HTTP, HTTPS, DNS) to pass between the internal network and the internet with no restrictions. The hostile party takes advantage of this and sets up a covert channel which allows information to covertly tunneled through the firewall in an allowed protocol.

47

Marc Smeets et al, op. cit.

A-1

Annex B - Potential Purposes of a Covert Channel

48

The basic purposes of covert channels will vary depending on the direction of traffic flow and whether or not the flow is continuous or blocked; this is demonstrated in the table above. Annex C – IP v4 Header 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset....| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding....| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The IP v4 header contains several fields that may be utilized to implement a covert channel; the fields in question are highlighted above.

48

Marc Smeets et al, op. cit.

A-2

Annex D – TCP Header 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (including timestamp).........| Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The TCP header contains several fields that may be utilized to implement a covert channel; the fields in question are highlighted above. Annex E - ICMP Header 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data .....................................................| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The ICMP header contains a single field that may be utilized to implement a covert channel; the field in question is highlighted above. Annex F - HTTP 1.0 Request Specification Request

= Simple-Request | Full-Request Simple-Request = "GET" SP Request-URI CRLF Full-Request

= Request-Line *( General-Header | Request-Header | Entity-Header ) CRLF [ Entity-Body ]

The HTTP 1.0 request specification contains several fields that may be utilized to implement a covert channel; the fields in question are highlighted above.

A-3

Annex G - HTTP 1.0 Response Specification Full-Response

= Status-Line *( General-Header | Response-Header | Entity-Header ) CRLF [ Entity-Body ]

The HTTP 1.0 response specification contains several fields that may be utilized to implement a covert channel; the fields in question are highlighted above. Annex H - DNS Header 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |......................ID.......................| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |................... QDCOUNT....................| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |................... ANCOUNT....................| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |................... NSCOUNT....................| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |................... ARCOUNT....................| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ DNS headers contain a several fields that may be utilized to implement a covert channel; the fields in question are highlighted above. Annex I - DNS Query & Response Headers DNS Query Header 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / QNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QTYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QCLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

A-4

DNS Response Header 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / |...............................................| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Covert channels may be ensconced within the *NAME fields of DNS query and Answer headers; the fields in question are highlighted above.

A-5

Annex J - Network Based Covert Timing Channel Example

49

In the example above, the data (in this case, a passage from the Bard's "Tragedie of Macbeth") is encoded using a predetermined coding scheme. The encoded data is then sequentially transmitted one bit at a time at a predetermined timing interval to the receiver; a predetermined delay interval acts to separate each byte of information.

49

Serdar Cabuk et al, op. cid.

A-6

Annex K - Covert Channel Analysis - PQS Lab Display50

50

Thayer School of Engineering at Dartmouth College. PQS Project. http://www.pqsnet.net/display.

A-7

Annex L - Acknowledgements Information regarding this paper's subject was culled from many sources as noted in the references; however, the bulk of the information deals with the decades-old concepts of system-based covert channels. This being stated, the majority of the information regarding network based covert channels was gleaned from the works of: a. Mr. Marc Smeets and Mr. Matthijs Koot ("Research Report: Covert Channels"); b. Mr. Steven Murdoch and Mr. Stephen Lewis ("Embedding Covert Channels into TCP/IP"); c. Mr. Serdar Cabuk, Mrs. Carla Brodley and Mr. Clay Shields (multiple publications); d. Sweety Chauhan ("Project Report: Analysis and Detection of Network Covert Channels"); and e. Mr. David Llamas et al (various documents). Gracious thanks are hereby extended to these professionals without whose superb and detailed work this report would not have been possible.

A-8