Covert Channels


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Covert Channels

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