On Covert Channels

Document Sample
On Covert Channels Powered By Docstoc
					Covert Channels
Anton Chuvakin, Ph.D., GCIA, GCIH <http://www.chuvakin.org> 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 <mss 1460,sac kOK,timestamp 8566305 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/


				
DOCUMENT INFO