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 network-
based 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
Loïc Hélouët et al. "Covert Channels Detection in Protocols Using Scenarios".
3
Ibid, Loïc Hélouët et al.
4
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.
5
Department of Defence. "DoD 5200.280-STD: Department of Defence Trusted Computer System
Evaluation Criteria.
6
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.
7
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".
10
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.

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
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).
13
Sweety Chauhan. "Project Report: Analysis and Detection of Network Covert Channels".
14
Serdar Cabuk et al. "IP Covert Timing Channels: Design and Detection".
15
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 Reed-
Solomon 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
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.
17
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.
18
Hamming Code - a linear error correcting code which can detect single and double-bit errors and
correct single-bit errors.
19
Reed-Solomon Code - an extremely robust detection block based error detection/correction code that
utilizes polynomial over sampling to facilitate advanced error correction.
20
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".
24
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.
25
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.

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

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

• 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

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 “User-
Agent:”, “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.
35
Ibid, Marc Smeets et al.

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
FQDN - "Fully Qualified Domain Name"; an unambiguous domain name that specifies the node's
absoloute position in the DNS tree hierarchy.
37
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.
40
Traffic Normalizer - A device that sits between the internet and an internal network and removes
"ambiguities" from the traffic flow.

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 TCP-
connection 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
Marc Smeets et al, op. cit.
44
Borders, Kevin et al. "Wire Tap: Detecting Covert Web Traffic".
45
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_2006-
02-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