Covert Channels

• Email
• Favorite
• Favorited X
• More...
•  

• Post to
• Blogger
• WordPress
• Twitter
• Facebook
• Delicious

• more share options
• Embed For WordPress.com
  
  Without related presentations
  

Favorites, Groups & Events

Covert Channels - Presentation Transcript

Covert Channels
Anton Chuvakin, Ph.D., GCIA, GCIH
WRITTEN: 2003-2004
DISCLAIMER:
Security is a rapidly changing field of human endeavor. Threats we face literally change every day; moreover, many security professionals consider the rate of change to be accelerating. On top of that, to be able to stay in touch with such ever-changing reality, one has to evolve with the space as well. Thus, even though I hope that this document will be useful for to my readers, please keep in mind that is was possibly written years ago. Also, keep in mind that some of the URL might have gone 404, please Google around.
While in some people the words " covert channeling" bring up images of
spies (due to " covert" ) and evil spirits (due to " channeling" ), the
meaning we discuss in this paper is even more interesting and
sometimes even more sinister.
Secret communications where there is seemingly no communication
happening within the same machine or even across the network can be
accomplished with covert channels. Specifically, communication that
violates a site security policy despite the deployed technology
safeguards is of particular interest.
We should note that we are not talking about " steganography" which is
mostly about hiding data and not about moving data from place to
place. Hidden data can be moved together with the object it is hidden
in, but if all such communication is also blocked, steganography just
won't help. Covert channel however might still be established. To some
extent, transmitting data embedded in images via steganography in case
such image transfers are allowed would likely constitute a " covert
channel" (see formal definitions below).
First, we would like to introduce some background of the problem of
covert channels. Indeed, covert channeling is a problem from
attacker's point of view (how to channel covertly and effectively) and
from defender's point of view (how to detect and prevent such
channels).
The notion of covert channels was popularized by the " rainbow series"
of the books by the National Computer Security Center affiliated with
the US National Security Agency (NSA). This books series are
officially known as US Department of Defense Trusted Computer System
Evaluation Criteria (TCSEC).
The " Light Pink Book" , officially called " A Guide to Understanding
Covert Channel Analysis of Trusted Systems" , contained the
definitions, classifications, identification and handling of covert
channels as well as methods to limit the possibilities for covert
channeling during the system design phase. It was published in 1993,
way before the snowballing growth of the Internet. Before that time
covert channels were discussed in some computer science publication
within academia and military [1].
The book provides many definitions of the covert channel. For example,
" a communication channel is covert if it is neither designed nor
intended to transfer information at all" or a channel " using entities
not normally viewed as data objects to transfer information from one
subject to another."
...
Currently, covert channels can be viewed as " old" and " new" . The
classic descriptions from the " Light Pink Book" are not very relevant
in today's highly distributed networking environment, where
workstation and servers exchange data across WANs and LANs and
multilevel operating systems are all but absent from most computing
environments. An ability to signal other users by accessing the swap
file or changing an entry in /tmp directory on a UNIX system does not
sound like a terrible risk to the ecommerce site. On the other hand,
an ability co send information from the customer database in real time
though firewalls while being invisible to the intrusion detection
systems might scare many an executive. Thus, old covert channels, such
as information leaks across the security levels on a multilevel
mainframe are likely left in the 80s, while the new covert channels,
such as risks of hidden network accesses and invisible tunneling for
data theft are here to stay for the foreseeable future. The study of
communication in a highly restricted network environments where most
normal protocol are blocked and monitored also presents some interest
at this time.
Additionally, the fusion of malicious software and autonomous attack
agents with covert channels might bring the risk level from " blended
threats" (as touted by some security vendors) to a new level and limit
the effectiveness of many current security controls.
In spite of relative obscurity and obsolete nature of classic
host-based covert channels, let us review some of the theory behind
them and some methods to eliminate such communication during the
system design stage. A lot of efforts were dedicated to such research
in 70s, 80s and early 90s.
The " Light Pink Book" which defined the comprehensive covert channel
analysis (CCA), listed the following four objectives of covert channel
analysis (CCA) [2]
* Identification of covert channels
* Determination of covert channels' maximum attainable bandwidth
* Handling covert channels using a well-defined policy consistent with the TCSEC objectives
* Generation of assurance evidence to show that all channels are handled according to the policy in force.
Just to clarify, the environment in which the described covert
channels take place - a secure multilevel OS with mandatory access
controls (MAC) - is described by a security policy similar to the
following:
-the process at higher security level can read the objects at lower
security levels but cannot write to them (since that will constitute a
data leak)
-the process at lower security level can write to the objects at
higher security levels but cannot read them (since that will
constitute an access to forbidden information)
Two main types of covert channels identified in the book are storage
and timing channels. As defined in the book " a potential covert
channel is a storage channel if its scenario of use " involves the
direct or indirect writing of a storage location by one process and
the direct or indirect reading of the storage location by another
process." " . That means that the processes communicate by allocating
some resource and checking for the evidences of such allocation.
Similarly, " a potential covert channel is a timing channel if its
scenario of use involves a process that " signals information to
another by modulating its own use of system resources (e.g., CPU time)
in such a way that this manipulation affects the real response time
observed by the second process." That means that one process attempts
to influence the timing of whatever event visible to the second
process. The examples of both kinds are provided below.
As for countermeasures, early researchers agreed that it is impossible
to eliminate covert channels from the system. Some methods (such as
avoiding resource sharing completely usually at some performance
penalty) were developed. However, it was deemed more effective to try
to reduce their bandwidth. Keeping in mind a particular covert
channel, the system designers will introduce noise in the covert
information flow, thus hindering the transmission by reducing the
bandwidth. Making the channel noisy by adding random delays and other
factors into various system processes while keeping the performance
adequate, the designers usually managed to reduce the bandwidth of
known cover channels. It was also required to carefully document all
possible channels discovered during the system design and
implementation phases and provide methods to reduce their
bandwidth. In many cases, the bandwidth of several bits per second was
deemed acceptable, and sometimes even high numbers (such as for
systems processing images) were acceptable.
...
Here are some classic examples of such covert channels. Keep in mind
that the described events occur in the multi-level OS platform where
the communication between levels is prevented based on the special
policy. Thus, the example might sound unimportant and even downright
silly for the common commercially available systems, but apparently
were viewed as critical in secure OS.
First, one program locks the file for access (such as for writing)
from one security level and another one is checking the lock. One
bit of information can be transmitted per time unit: file is locked
corresponds to 1 and unlocked is 0.
Second, one process allocates disk space and another is checking for
available space. If second process fails to allocates it knows that
the first is transmitting the 1, while allocation success indicates 0.
Third, the program reads a page of data. When second program tries to
read the same page it comes quickly (already loaded in memory, 1) or
slowly (had to be received from disk, 0). Thus, one bit is transmitted
between the security levels.
Fourth, the program creates an object thus exhausting a unique object
identifier of some kind (such as UNIX user ID). The second program
also attempts to create such object and notices the available unique
identifier. Thus it can deduce whether the first program actually
tried to create an object (1) or didn't (0).
Fifth, a process tries to unmount a file systems which might or might
not be busy. The second process is trying to send information by
allocating or deallocating disk space on the same file system.
To conclude and to illustrate the relevance (or, rather, total
irrelevance) of the above for modern information systems, one should
note that the NSCS CCA guide applied only to systems rated B2,B3 and
A1 by the TCSEC criteria. To remind, the TCSEC ratings go (or, rather,
went, since TCSEC is not supplanted by Common Criteria) from the least
secure D to C1,C2, B1,B2,B3 and the most secure A1 (see
http://www.radium.ncsc.mil/tpep/epl/epl-by-class.html) Most commercial
UNIX and NT systems would be rated at C1, some with high-security
packs and addons get to C2. Few heavily modified UNIX systems rate as
B1 and no general purpose OS ever got to B2. Thus, CCA and covert
channels, as defined and evaluated in the " Light Pink Book" has
absolutely no relevance in the modern computing environment, perhaps
outside the highly restricted government installations using special
purpose operating systems. Additionally, the book directly states
that " the notion of covert channels is irrelevant to discretionary
security models" such as those used in most commercial OS.
Let us now turn to more modern times and look at covert channeling
across the protected network. We will first look at covert channels
within the basic TCP/IP protocols and then briefly describe the
application protocol covert channeling (and tunneling, as its trivial
case).
Before we delve into the exciting world of covert network
communications, let use the briefly review the TCP/IP networking which
powers most of today's networks.
Applications communicating over TCP/IP networks use a subset of OSI
(Open Systems Interconnect) network protocol layers. Briefly, the
application typically communicates using an application layer protocol
(such as SMTP, HTTP, POP3, IMAP, SNMP and many others, both open and
proprietary). Such communication (for example, client requests and
server responses) are formed using the rules defined by the above
application protocols. The application protocol messages (such as a
GET request to download a web page in HTTP) are then encapsulated in
the appropriate network layer protocol (such as TCP or UDP). The
encapsulation process involves adding headers and footers (in some
cases). Also, sometimes an intermediate layer (for example, session or
transport, such as SSL or TLS) is also used before the network
layer. Further, the TCP or UDP message is encapsulated in the IP
message, again adding appropriate protocol headers. Then, depending
upon the physical transmission media, the IP message, also called a
" packet" , is encapsulated in the data link layer (such as the
Ethernet, ATM or frame-relay) messages, called " frames" . Next, it
reaches the bottom of the protocol stack at the physical layer, which
handles the electrical or optical signals carrying the data through
the wire.
Here is the example using the Ethereal protocol analyzer:
<<...PICTURE 1 - Network Protocol Encapsulation - hism5-covert1.png ...>>
The picture shows all the protocol layers from telnet (application
layer) to the ethernet frame (physical layer).
Let us also look at the headers that are added in the encapsulation
process. Here is the structure of the TCP header:
<<...PICTURE 2 - TCP Header ...>>
Some of the fields in the header are source and destination ports,
urgent flag, sequence (SN) and acknowledgment numbers (ACK), offset,
options and others. The field sizes (important for our further
analysis) are also shown. For example, the destination or source port
is a 16 bit value (ports go from 0 to 65535 which is 2^16-1) while
sequence number is a full 32 bit field.
And this is the IP header:
<<...PICTURE 3 - TCP Header ...>>
Some of the fields in the header are source and destination addresses,
version, type of services (TOS, recently also assigned to ECN -
Explicit Congestion Notification), padding, length, time-to-live (TTL),
identification (IP ID), protocol, options and others. The field sizes
(important for our further analysis) are also shown. For example, the
IP ID is a 16 bit field while version is a small 4 bit field.
Here is how it is relevant to network covert channels. Many of the
above fields in the TCP (also UDP) and IP headers are somewhat
undefined (TOS/ECN), unset (padding), set to random values (like the
initial sequence number), set to varied values (IP ID), or are
optional (such as options). This very important fact creates
possibilities for mixing in the information without:
1. breaking the TCP/IP standard (and thus preventing the transmission
of the packet)
2. without making the packet appear anomalous (and thus triggering the
network intrusion detection systems)
For example, whenever a TCP connection is established a random initial
sequence number is generated by the sender for the first packet in the connection (carrying the SYN flag). Here is how such packet is shown in the " tcpdump" tool (flags: -vvv):
11:45:43.965497 src.thisdomain.com.34620 > dst.thatdomain.com.telnet: S [tcp sum ok]
738144346:738144346(0) win 5840 0,nop,wscale 0> (DF) [tos 0x10] (ttl 64, id 34427, len 60)
The initial sequence number (ISN) is 738144346. It is worth noting
that different operating systems use different algorithms for this
number generation from almost random to deterministic. The covert
channel is apparent here: if one is to encode a message (or part of
the message) in the ISN, one can carry almost the full 32 bits of
information (or less if some random bits are added for higher
security) per established TCP session (all subsequent sequence numbers
are derived from the first one).Similar channel can be established
using the acknowledgment sequence number.
This channel is likely impossible to detect and stop, unless a
connection goes through an application level proxy (such as a good
proxy firewall) or other device which breaks the original TCP
session. Additionally, some NAT (Network Address Translation)
implementations might break some of the header fields, such as IP ID.
Sending a lot of information is unlikely with the above channel since
one has to establish a lot of TCP sessions which might appear
suspicious. We would like the opportunity to carry data in every
packet of the connection and not only in the initial one.
Using the IP ID field was suggested in [3]. The field may have a
non-zero value on any packet, which allows the information transfer of
up to 16 bit per packet without raising suspicion, since IP ID field
can have any legitimate value. Such covert channel is implemented in
the " covert_tcp" program, provided at the above reference. Application
proxy will always break such covert channel as referenced above.
Covert channels can be significantly improved by adding spoofing and
bouncing. Spoofing can help conceal the source of the communication,
but complicate things since response to such communication need to be
picked up off the wire by the sniffer. Spoofing also can help to
create diversions by initiating spurious connection to third party
machines, not related to the communicating parties. Bouncing (possible
with, say, ACK sequence number channel) works by initiating a spoofed
communication with an innocent third party which would then unwitting
respond to the intended destination of communication. More details on
implementing this are also provided in [3].
Similarly, encrypting the message before transmitting it over the
covert channel is also helpful to add another layer of protection in
case the channel is required. It can also help to prevent various
man-in-the-middle and message injection attacks, possible in case the
channel is discovered.
Detailed look at all the IP, TCP, UDP, ICMP and other network protocol
header options for the purpose of evaluating the potential of covert
channels (with suggestion on blocking them) will provide a fascinating
area of study, but unfortunately lies outside the scope of the current
paper. One of the efforts which covers many other header fields is [3a]
We should also note that covert communication (while not strictly a
covert channel) is possible using the " uncommon" protocols, such as
NVP, IGMP, EGP, GGP and many others, which are not expected to carry
interactive sessions. A casual look at " /etc/protocols" file on any
UNIX machine reveals a long list.
Fortunately, or, unfortunately, depends upon the side of the " security
equation" , any device that interrupts the flow of the TCP/IP
connection at higher layers, such as application proxy (web proxy,
SOCKS, etc) or a good proxy firewall will recreate the TCP/IP header
and wipe out all the information hidden therein, with the exception of
the destination port which cannot be used for covert channeling due to
its fixed value. Additionally, such device will be blocking the
" uncommon" protocols, only allowing the specified list. How can one
bypass this limitation? Higher-layer covert channel is the answer.
The trend to tunnel various network protocols over HTTP disturbs many
security professionals since " everything over HTTP" means that many
new attack vectors become possible through the firewall. This scenario
also gives rise to new possibilities for covert channels. A classic
example is a flurry of normal HTTP GET requests (used to fetch the
content off the WWW server) to specific " scripts" or " web
applications" . Many URL used by today's web applications are
complicated and can be made to carry information. Requesting
" http://www.example.com/detail/-/0130259608/102-5403649-1054521?akg"
might mean something else from asking the
" http://www.example.com/detail/-/0130259608/102-5403649-1054521?bkg"
and such long URL can carry hundreds of bytes of information from the
client machine to the malicious server. The response is possible vie
that pages themselves or via HTTP response codes (200, 302, 403, 404,
etc). Many programs utilizing telnet-like connectivity over the HTTP
protocol are known (for example, see " wwwshell" [4]).
Other application protocols (such as DNS) also open tunneling and
covert channeling possibilities. In fact, " telnet over DNS"
implementation in known as are some others (such as " ICMP telnet" or
Loki, detected by most current IDS ). Even " shell over SMTP" i.e. over
email was implemented. Application protocol are well suited for
tunneling since such communication can be made to pass through
high-security proxy firewalls, provided that the rules enforced by the
firewalls are not violated. For example, the above HTTP GET methods
should be completely transparent for the firewalls. To summarize, we
will refer the reader to the humorous RFC, " " [5], which illustrates
that tunneling is possible even in such extreme cases.
Recent advances in application level tunneling include the " setiri"
backdoor, described in [5]. The backdoor utilizes the legitimate
network applications to perform HTTP tunneling thus avoiding not only
network, but also host-based security controls.
Other real-life examples of covert communication in actions include
spoofing NVP backdoor, discovered and analyzed by the Honeynet
Project.
Now, let us look at covert channel risk analysis and
countermeasures. As we pointed out, the classic host-based covert
channels present almost no risk to the modern IT environment. Secure
multilevel operating systems, where such channels manifest themselves,
are not in widespread use.
The risk of network based covert channeling is harder to evaluate. Due
to the extreme advantage that the attacking party possesses in this
case, it is suspected that most cases of covert channel use are never
discovered and prevented. Automated attack agents such as worms and
Trojans utilizing covert communication would present the high level of
risk, provided they are actually discovered and described by
anybody. We can only suspect that such methods are indeed used by
advanced attackers.
As for preventative measures, keeping in mind that even the " Light
Pink Book" authors stated that complete elimination is impossible on
the host level, the network environment presents a more formidable
challenge. While system design analysis aimed at preventing some
covert channels was conceivable in the tightly-controlled environment
of the secure OS, no such analysis is likely to happen on the
network. There is simply too much variety in methods of communication,
occurring on the modern networks.
To some extent, the proxy firewall and a combination of signature
based and anomaly-based intrusion detection systems can help, but
infinite possibilities exist for evading such systems by various
covert channels. Additionally, inline traffic normalizers (similar to
the one proposed in [7]) may serve as additional layer of protection.
ABOUT THE AUTHOR:
This is an updated author bio, added to the paper at the time of reposting in 2009.
Dr. Anton Chuvakin (http://www.chuvakin.org) is a recognized security expert in the field of log management and PCI DSS compliance. He is an author of books " Security Warrior" and " PCI Compliance" and a contributor to " Know Your Enemy II" , " Information Security Management Handbook" and others. Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security management (see list www.info-secure.org) . His blog http://www.securitywarrior.org is one of the most popular in the industry.
In addition, Anton teaches classes and presents at many security conferences across the world; he recently addressed audiences in United States, UK, Singapore, Spain, Russia and other countries. He works on emerging security standards and serves on the advisory boards of several security start-ups.
Currently, Anton is developing his security consulting practice, focusing on logging and PCI DSS compliance for security vendors and Fortune 500 organizations. Dr. Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a Chief Logging Evangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by a security vendor in a strategic product management role. Anton earned his Ph.D. degree from Stony Brook University.
References:
1. B. W. Lampson, " A Note on the Confinement Problem," Communications
of the ACM, 16:10, pp. 613-615, October 1973.
2. " A guide to understanding covert channel analysis of trusted
systems" (ncsc-tg-030 version-1, " Light Pink Book" ) (available at
http://www.fas.org/irp/nsa/rainbow/tg030.htm), National computer
security center, November 1993
About author:
3. " Covert Channels in the TCP/IP Protocol Suite" Craig. H. Rowland
http://www.firstmonday.dk/issues/issue2_5/rowland/, published in
" First Monday" journal, Vol.2 No.5 - May 5th. 1997
3a. Drew Hintz, " Covert Channels in TCP and IP Headers" presented at
DefCon X conference
http://www.defcon.org/images/defcon-10/dc-10-presentations/dc10-hintz-covert.ppt
http://www.defcon.org/images/defcon-10/dc-10-presentations/dc10-hintz-covert.ppt
4. " Reverse WWW Tunnel Backdoor" http://www.securiteam.com/tools/5WP08206KU.html
5. D. Waitzman, " A Standard for the Transmission of IP Datagrams on
Avian Carriers" http://www.ietf.org/rfc/rfc1149.txt 1 April 1990
6. Roelof Temmingh and Haroon Meer " Setiri: Advances in Trojan
Technology" presented at DefCon X conference
http://www.defcon.org/images/defcon-10/dc-10-presentations/dc10-sensepost-setiri.ppt
7. Mark Handley and Vern Paxson, Christian Kreibich " Network Intrusion
Detection: Evasion, Traffic Normalization, and End-to-End Protocol
Semantics" , presented at USENIX http://www.icir.org/vern/papers/norm-usenix-sec-01-html/

Collect leads with LeadShare