Covert Channels

Published on June 2017 | Categories: Documents | Downloads: 26 | Comments: 0 | Views: 378
of 30
Download PDF   Embed   Report

Comments

Content

3380-1 (CFNOC/DND CIRT) 30 Aug 06 NOSO I&W ANALYSIS COVERT CHANNELS: CLOAK AND D AGGER 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 resu lt of this, savvy attackers are now utilizing covert communication channels in o rder to bypass security measures, evade detection and exfiltrate/infiltrate info rmation. 2. (U) In previous decades, much attention was paid to the threat of st orage and timing covert channels as they were implemented on an individual syste m1. However, with the evolution of networking and the growth of large interconne cted networks, covert channels based upon existing network protocols gradually b ecome prevalent. 3. (U) Though this document will touch on the historical aspect s of systemic storage and timing covert channel techniques, its primary focus wi ll be on networkbased covert channels and the possible countermeasures that can be implemented to defend the organization's networks. AIM 4. (U) The purpose of this report is fourfold: a. to acquaint the reader with the basic concepts of co vert communication channels; b. to demonstrate the methods by which covert commu nication channels may be implemented; c. to recommend solutions to detect the pr esence of covert channels on the organization's networks; and d. to recommend co untermeasures that will prevent the implementation of covert channels. 1 System - A framework of software and hardware designed to allow software program s 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 sy stem 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 sys tems. 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 ut ilized to facilitate information leaks, synchronize attacks on a system or diver t 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 pur poses in addition to data exfiltration ad demonstrated in Annex B. 8. (U) Althou gh consensus indicates that it is impossible to eliminate the threat posed by co vert channels, detection of covert channels and mitigation of their impact is mo re critical today than ever due to the development of network based covert chann els and the prevalence of large interconnected networks. 3 9. (U) In 1985 the Na tional 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-ca lled "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 d ealt exclusively at the system level and did not address networks specifically; despite its limited scope, it did introduce the two basic scovert channel method ologies: a. storage based covert channels - which utilize a system resource in o rder to store compartmentalized data that can then be accessed by an unauthorize d 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 inform ation to another process. 2 3 4 5 6 7 Loïc Hélouët et al. "Covert Channels Detection in Protocols Using Scenarios". Ibid, Loïc Hélouët et al. National Computer Security Center - a child organization of the Nati onal Security Agency, was established in 1981 and is responsible for testing and evaluating computer equipment for use in high security and/or classified applic ations. Department of Defence. "DoD 5200.280-STD: Department of Defence Trusted Computer System Evaluation Criteria. Rainbow Series - a series of computer secur ity standards published by the United States government in the 1980s that descri be a process of evaluation for trusted systems. Common Criteria - an internation al standard (ISO/IEC 15408) for computer security. 2

11. (U) In recent years, the widespread deployment of large interconnected netwo rks and the exploitation of protocols utilized in their information flows result ed in the naissance of a new threat - network based covert channels. This new fo rm 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 util ized to convey compartmentalized information between processes on a single syste m, network based protocols utilize existing data fields in standard protocols to convey information covertly across a network from one system to another. This d ifferentiation makes them inherently dangerous to the highly networked infrastru cture of the organization. The Wolf in Sheep's Clothing - Network Based Covert C hannels 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 ob fuscation and level of utility of is dependent on the manner in which the bits i n 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 wi thout violating the legal framework of the protocol and whether the channel can be cre ated within the constraints of actual implementations of the protocol. This poss ibility arises because protocol implementations and their specifications are not identical. Consequently, covert channels could follow the legal definition of t he filed to be manipulated but might not work at the implementation level, or th ey 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 whe n 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 c arrier protocol and should not result in obvious anomalies in either spatial (pa cket size, bandwidth usage) or temporal (rate of occurrence) properties of it’s ca rrier in the target network. detection and correction facility should be available to cope with latency and c ongestion issues, and the reliability should not depend on assumptions of sequen ce, path or time of packet delivery. • Robustness: The covert channel should be reliable. For example, an error 16. (U) Obviously, maximum obfuscation and high utility should be the ultimate g oal 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 w ith limited utility; and c. provide more diverse obfuscation options. 17. (U) Fa ilure to consider these two qualities and Llamas' criteria when implementing a c overt channel may cause the implementation to degrade, fail or become easily det ectable by standard network security facilities. Network Based Covert Channels Implementations 18. (U) In their aforementioned report, Smeets and Koot describ ed the four possible implementations of network based covert channels based loos ely 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 repre sentation 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 t he letter ‘A’ by crafting one TCP packet with the source port set to 1234’,waiting, an d then crafting a second TCP packet with it’s source port set to ‘6464’ (the transitio n from ‘1234’ to ’6464’ would represent the character ‘A’). 9 Marc Smeets et al. "Research Report: Covert Channels". Ibid, Marc Smeets et al. 11 Spatial container - A field of arbitrary length within a protocol header used to contain data of a specific type, e.g. TCP flag field, IPID field, etc. 10 4

• Value-based temporal channel (time): This class encodes data by modulating the occurrence of events (time dimension). Example: Using network pac ket 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 time s (jitter12) to implement a binary channel. Network Based Covert Channel Methodo logies - 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 info rmation 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 encodin g of the information within the covert channel; and b. presence based - the rece ption 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 s orting method is self explanatory; the remainder of the this report will deal wi th the more complex and more covert presence based timing channel. 22. (U) Timin g 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 i nterval to determine whether or not a packet was received. The result is a binar y 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 transmi ssion, is subdivided into smaller blocks of binary data, referred to as frames.1 5 While all the frames are of equal length, the actual length, as well as the in terval between frames, is influenced by the parameters of the encoding schema an d the network over which the data is being conveyed. 12 13 14 15 Jitter - a fluctuation in a network transmission; this term always referring to some offset of time and space from the norm (e.g. in a network transmission, jit ter would be a bit arriving either ahead or behind a standard clock cycle or a v ariability in round trip times). Sweety Chauhan. "Project Report: Analysis and D etection of Network Covert Channels". Serdar Cabuk et al. "IP Covert Timing Chan nels: Design and Detection". Frame - a fixed block of data consisting of the inf ormation being conveyed and all necessary system overhead (encryption, protocol control information, etc.); individual frames are delimited by header and traile r flags that "frame" each block. 5

24. (U) As with all binary communication circuits, the final interpretation of t he bit stream is determined by the prearranged coding and framing schema. In add ition to the information stream, additional overhead bits can be added to the fr ame for: a. error detection - parity bits16 or a CRC17 is inserted into the fram e in order to implement an error detection facility; b. error correction - addit ional bits can be added to the frame in order to provide an error correction fac ility (e.g. Hamming Code18 or ReedSolomon Code19); c. synchronization - the very nature of a timing based covert channel requires an accurate timing reference a bitstream can be made self-timing using techniques such as Manchester20 encod ing; 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 protoco l used to convey the channel can drastically affect the degree of obfuscation; t his is due primarily to the unique traffic pattern usually generated by covert c hannel activity. 26. (U) In addition to the decision regarding the protocol used to convey the covert channel's information, several other factors that can affe ct channel throughput must be taken into consideration: a. network Conditions traffic congestion and jitter can adversely affect the throughput of a covert ch annel; b. coding schema complexity - use of inefficient coding schema can signif icantly degrade the performance of a covert channel; c. endpoint processing capa bilities - endpoint bottlenecks caused by heavy traffic loads can result in a de lay in the processing of packets which will in turn degrade the covert channel's performance; and d. programming language portability - The proper synchronizati on of the channel depends directly on the correct and consistent functionality o f the subroutines and libraries used to implement the channel. 16 17 18 Parity - a technique of checking whether data has been lost that involves the ad dition 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. CR C - "Cyclic Redundancy Check"; a type of hash function used to produce a checksu m against a block of data in order to implement an error detection facility. Ham ming Code - a linear error correcting code which can detect single and double-bi t errors and correct single-bit errors. Reed-Solomon Code - an extremely robust detection block based error detection/correction code that utilizes polynomial o ver sampling to facilitate advanced error correction. Manchester Encoding - a sy nchronous communication encoding technique utilized to implement channel self-ti ming; this is accomplished by encoding both the timing information (clock) and d ata into a single bit stream. 19 20 6

27. (U) All four of these factors can affect the synchronization, maximum throug hput and available bandwidth of a timing based channel; they must therefore be c arefully 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 whe n network based covert storage channels are discussed below, the technical issue s that must be addressed in order to successfully implement a timing channel are considerable. However, timing based channels offer several advantages over stor age based channels: a. timing based channels, when properly implemented, are con siderably more difficult to detect than storage based channels; b. the ability t o easily implement a self timing synchronous communication channel allows greate r channel throughput; and c. the option to implement forward error detection and correction offers the potential for greater data integrity. Network Based Cover t Channel Methodologies - Storage Channels 29. (U) As mentioned previously, netw ork based covert storage channels utilize valid data fields in various protocols to convey the channel's information; each of the protocols commonly utilized th is type of channel will now be addressed individually. These include: a. IP head er - 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 obfuscatio n; d. HTTP headers - general-header, request-header, entity header and entity bo dy fields; and e. DNS headers - Field ID, QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT, QN AME 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 n ot been implemented on the organization's networks as of this writing. As demons trated in Annex C, several fields exist within the IP header in which covert cha nnels can be implemented: • Type of Service - The eight bits within the IP ToS field are rarely used with or iginal semantics and modern networks seldom make use of the field. Considering t his, up to eight bits of data could conceivably be concealed in this field. IP I dentification - 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 a n 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 inf luence on the IP delivery process. Considering this, it is a possible carrier fo r covert channels, even though it can only hold one bit per IP packet. IP Fragme nt Offset - A covert channel may be implemented within the IP fragment offset fi eld of the IP header by modulating the size of the fragments originated by a hos t and thus thereby modulating the fragment offsets. IP Options - The 24 bit opti ons (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. Despit e 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 P adding field (LSB25 of byte 12) is used to pad the Options a to 32-bits block; t his field should only contain zeros but could easily be used to implement a cove rt channel. • • • • • 21 22 23 24 Marc Smeets et al, op. cit. Steven Murdoch et al. "Embedding Covert Channels int o TCP/IP". Yogi Mehta. "Communication Over the Internet Using Covert Channels". MSB - Most Significant Byte; the bit position in a binary number having the grea test value. The MSB is sometimes referred to as the left-most bit. LSB - Least S ignificant Bit; the bit position in a binary number having the least value. The LSB is sometimes referred to as the right-most bit. 25 8

Covert Channels in TCP 26 27 31. (U) As was the case with the IP header, the TCP header contains fields in wh ich 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 ord ering on arrival and aid reliability using retransmit requests. The first (SYN) packet of a TCP session contains a random initial sequence number (ISN). The rec eiving host typically acknowledges its receipt by responding with a SYN/ACK pack et, using ISN+1 as an ACK number. However, this field can also contain a non-ran dom 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 rec eipt of a TCP packet to it’s source. This field must always contain the sequence n umber of the sender, incremented by 1; it has been demonstrated, however, that t he sender IP of a TCP packet can be spoofed, making the receiving host acknowled ge to an arbitrary host with the (incremented) input bytes encoded into this fie ld. 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 b y modulating the LSB of the TCP timestamps transmitted by a host as described in the paper by John Giffin et al 28. 29 • • Covert Channels in ICMP 32. (U) As demonstrated in Annex E, the ICMP protocol has a large data field, wh ich may be utilized to implement a covert channel. Several tools/methods are ava ilable 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 c reate 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 packet s.32 26 27 28 29 30 31 32 Marc Smeets et al, op. cit. Steven Murdoch et al, op. cit. John Giffin et al. "C overt Messaging in TCP". Marc Smeets et al, op. cit. Daniel Stødle. "Ping Tunnel For Those Times When Everything Else is Blocked". Thorner Gil. "ICMPTX (IP-over -ICMP) HOWTO". Grayworld.net Team. "Skeeve" (PoC tool). 9

• Loki - Loki is a client/server program enables a user to tunnel traffic within a n ICMP packet.33 34 Covert Channels in HTTP 33. (U) As demonstrated in Annexes F and G, HTTP response and request header fie lds can be manipulated to implement a covert channel: • HTTP Request General, Response and Entity Headers - HTTP request messages may co ntain multiple headers. Common examples include “UserAgent:”, “Referrer:” and “Cookie:”. Cov ert channels may be implemented within these headers in order to convey arbitrar y data. HTTP Request Entity-Body - The Entity-Body normally is only present in P OST requests as it has no use for other types of requests. However, RFC 1945 doe sn’t explicitly exclude this field from being present in other requests. Covert ch annels 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 i nclude 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 bidirectiona l communication channel. HTTP Response Entity-Body - Except in response to HEADrequests, 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. 35 • • • Covert Channels in DNS 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 differe nt 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 en tries 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 b its of data. • 33 34 35 Stephen Northcutt et al. "Intrusion Signatures and Analysis". Marc Smeets et al, op. cit. Ibid, Marc Smeets et al. 10

• ANCOUNT - The 16-bit ANCOUNT field is meant to specify the amount of resource re cords in the answer section that appears after this header. A hostile entity exe rcising 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 n ame server resource records entries in the answer section that appears after thi s header. A hostile entity exercising control over a rogue DNS server can use th is field to hide up to 16 bits of data. ARCOUNT - The 16-bit ARCOUNT field is me ant 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 us e this field to hide up to 16 bits of data. QNAME - This field represents the st ring of text entered as the actual DNS query and should be in the form of a FQDN 36. The QNAME field is limited to the maximum length of a FQDN, thus an adversar y can use up to 255 bytes so long as it complies to the limit of 63 octets per l abel 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 hea ders as demonstrated in Annex I; this message is the same for the answer, author ity and additional sections. NAME - This field represents the a FQDN to which th e resource record pertains. As with the QNAME field in the query message, the NA ME 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 controllin g 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 ARCOUN T fields. 36. (U) By employing a custom algorithm, the hostile entity can use th ese fields as a carrier for covert channels instead of only using it to point ou t how many queries or answers will be after this header; this can be accomplishe d 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 ma ke 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 impl ementation, data is hidden within QNAME and NAME fields, by mimicking queries of DNS CNAME and TXT records. 36 37 FQDN - "Fully Qualified Domain Name"; an unambiguous domain name that specifies the node's absoloute position in the DNS tree hierarchy. Dan Kaminsky. "Attackin g Distributed Systems - The DNS Case Study". 11

Network Based Covert Channels - Countermeasures 38. (U) Despite the insidious na ture of covert channels, countermeasures are readily available that can mitigate the threat posed to the integrity of the organization's networks. Various count ermeasure techniques for each of the protocols and methods discussed earlier wil l be touched on below. Covert Channel Countermeasures - Timing Channels 39. (U) Unfortunately, deployment of timing channel detection solutions and countermeasu res against is a technically daunting task usually requiring the engineering of custom detection software/appliances which are beyond the scope of this paper. 4 0. (U) This being stated, several non-commercial solutions have been proposed in several whitepapers; these include: a. deployment of a PQS (Process Query Syste m) based solution to facilitate and partially automate covert timing channel det ection38 (the Dartmouth College PQS analysis screen is demonstrated in Annex K); and b. development of a new engineering project to produce proprietary detectio n solutions for eventual deployment on the organization's networks. 41. (U) Unfo rtunately, as of this writing, research has failed to yield any results in regar ds 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, i f 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 tra ffic 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 o n the use of IP ToS field and Option tags and enforce that policy using an IP-aw are traffic normalizer. 38 39 40 Vincent Berk et al. "Covert Channel Detection Using Process Query Systems". Marc Smeets et al, op. cit. Traffic Normalizer - A device that sits between the inte rnet 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 cover t 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 a ll TCP traffic through a proxy device which establishes a TCPconnection to the e ndpoint on behalf of the originator but utilizes its own ‘trusted’ sequence number g enerator; and c. create a baseline of TCP traffic patterns and monitor for anoma lies. Covert Channel Countermeasures - ICMP 42 44. (U) The following countermeasures are recommended to counter ICMP based cove rt channels: a. block outgoing ICMP echo request/response traffic to the Interne t; 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 pt unnel traffic; d. use of a traffic normalizer to sanitize the ICMP Header Data b its 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 42 Marc Smeets et al, op. cit. Ibid, Marc Smeets et al. 13

Covert Channel Countermeasures - HTTP 43 45. (U) The following countermeasures are recommended to counter HTTP based cove rt channels: a. define a policy on the use of HTTP headers and enforce that poli cy using an HTTP-aware proxy; b. throttle outbound and inbound HTTP traffic usin g 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 preventiv e or reactive measure. Covert Channel Analysis & Countermeasures - DNS 45 46. (U) DNS analysis can be difficult at the best of times. However, several app roaches 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 a s follows: • • • • • • Is the queried DNS server off-site? Is the queried DNS server only us ed 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 qu eries 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 questi ons answered in the affirmitive, the likeliness of a covert channel existing in the DNS traffic flow increases. 43 44 45 Marc Smeets et al, op. cit. Borders, Kevin et al. "Wire Tap: Detecting Covert We b Traffic". Marc Smeets et al, op. cit. 14

48. (U) Should the next two points be answered in the negative, it is highly lik ely 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 serv er provide the same result? 49. (U) The following countermeasures are recommended to counter DNS based cover t channels which depend (either partially or fully) on crafting DNS headers or p ackets: a. block outbound queries to rogue DNS servers (i.e. use a hardened forw arding caching server located on the intranet, or disallow querying non-local do mains at all); b. create a baseline of DNS traffic patterns and monitor for traf fic 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 mentione d above. 46 CONCLUSIONS & RECOMMENDATIONS 50. (U) Network based covert communica tion channels present a clear and present danger to the integrity of the organiz ation's networks. Considering this, covert channel countermeasures, such as thos e discussed above, should be implemented as soon as the technical/fiscal means b ecome available. 51. (U) Any questions regarding this I&W report may be addresse d to the undersigned. //signed// E.L. Mac Daibhidh, CD Cpl DND CIRT Special Operations Analyst 945-774 7 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 Protoc ol Specification”. September 1981. Accessed on 19 August 2006. http://www.faqs.org /rfcs/rfc791.html. Author unknown. “RFC793 – Transmission Control Protocol DARPA Int ernet Program Protocol Specifications”. September 1981. Accessed on 19 August 2006 . http://www.faqs.org/rfcs/rfc793.html Berk, Vincent et al. "Covert Channel Dete ction Using Process Query Systems". Date unknown. Accessed on 12 August 2006. ww w.pqsnet.net/publications/ CovCh_Flocon05_pres.pdf. Berk, Vincent et al. "Detection of Covert Channel Encoding in Network Packet Del ays". 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. Ac cessed on 24 August 2006. http://www.eecs.umich.edu/aprakash/papers/ borders-pra kash-ccs04.pdf. Cabuk, Serdar et al. "Covert Timing Channels: Design and Detecti on". 2005. Accessed on 24 August 2006. http://www.cs.jhu.edu/~fabian/courses/CS6 00.624/ slides/week2.pdf. Cabuk, Serdar et al. "IP Covert Timing Channels: An In itial Exploration". 2004. Accessed on 24 August 2006. www.cs.georgetown.edu/~cla y/research/pubs/ cabuk.ccs2004.pdf. Castro, Simon. "Covert Channel and Tunnellin g Over the HTTP Protocol Detection". November 2003. Accessed on 09 August 2006. http://www.gray-world.net/ projects/papers/html/cctde.html. Castro, Simon. "Cove rt Channel Tunneling Tool Manual". June 2003. Accessed on 10 August 2006. http:/ /www.entreelibre.com/cctt/man_en.html. Chauhan, Sweety. "Project Report: Analysi s and Detection of Network Covert Channels". December 2005. Accessed on 05 Augus t 2005. www.cisa.umbc.edu/ courses/cmsc/444/fall05/studentprojects/sweety.pdf. C ooper, Robert et al. "The Covert Channel Problem". August 1996. Accessed on 26 A ugust 2006. http://www.cs.unb.ca/tech-reports/files/TR96_111.pdf. Denning, Dorot hy. "An Intrusion Detection Model". February 1987. Accessed on 10 August 2006. h ttp://www.cs.georgetown.edu/~denning/infosec/ids-model.rtf. Department of Defenc e. "DoD 5200.280-STD: Department of Defence Trusted Computer System Evaluation C riteria. December 1985. Accessed on 29 July 2006. csrc.nist.gov/publications/his tory/dod85.pdf. Dubrawsky, Ido. "Data Driven Attacks Using HTTP Tunnelling". Aug ust 2004. Accessed on 12 August 2006. http://www.securityfocus.com/infocus/1793. i

Giani, Annarita et al. "Data Exfiltration and Covert Channels". Date unknown. Ac cessed 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 200 6. http://www.eecs.harvard.edu/~greenie/tcpcovertchannels.ps. Gil, Thomer. "ICMP TX (IP-over-ICMP) HOWTO". September 2004. Accessed on 23 August 2006. http://tho mer.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. "Ske eve" (PoC tool). June 2004. Accessed on 23 August 2006. http://gray-world.net/po c_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 Editio n. 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 Issu e 10. October 1973. Accessed on 16 August 2006. http://research.microsoft.com/~l ampson/11-Confinement/Word.doc. Llamas, David et al. "An Evaluation Framework fo r the Analysis of Covert Channels in the TCP/IP Protocol Suite". June 2005. Acce ssed on 1 August 2006. http://www.davidllamas.org/Portals/2/0507-ECIW/0507-ECIWPaper.pdf. Llamas, David et al. "Covert Channel Analysis and Detection with Reve rse Proxy Servers using Microsoft. Windows". June 2004. Accessed on 4 August 200 6. http://www.davidllamas.org/Portals/2/0406-ECIW/0406-ECIW-Paper.pdf. Llamas, D avid et al. "Covert Channels in Internet Protocols: A Survey". June 2005. Access ed 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. "Commu nication Over the Internet Using Covert Channels". July 2005. Accessed on 20 Aug ust 2006. http://www.cs.drexel.edu/~vp/CS743/Papers/ ypm23-hw2.pdf. Mockapetris, P. “RFC 1035 - Domain Names Implementation and Specification”. November 1987. Acces sed 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. Murd och, 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. Nort hcutt, Stephen et al. "Intrusion Signatures and Analysis". First edition. Indian opolis: New Riders Press. 2001. Postel, J. “RFC792 – Internet Control Message Protoc ol”. September 1981. Accessed on 19 August 2006. http://www.faqs.org/rfcs/rfc792.h tml. Postel, J. et al. "RFC1700 - Internet Numbers". October 1994. Accessed on 2 1 August 2006. http://www.faqs.org/rfcs/rfc1700.html. Rutkowska, Joanna. "The Im plementation of Passive Covert Channels in the Linux Kernel". 2004. Accessed on 20 August 2006 http://www.invisiblethings.org/papers/ passive-covert-channels-li nux.pdf. Rutkowska, Joanna. "Concepts for the Stealth Windows Rootkit". Septembe r 2003. Accessed on 20 August 2006. http://www.invisiblethings.org/papers/ chame leon_concepts.pdf. Smeets, Marc et al. "Research Report: Covert Channels". Febru ary 2006. Accessed on 13 August 2006. http://www.os3.nl/~mrkoot/courses/RP1/rese archreport_200602-15_final2.pdf. Stevens, W.R. "TCP/IP Illustrated Volume 1: The Protocols". First edition. Boston: Addison Wesley Professional. 1994. Stødle, Dan iel. "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 Horenbe eck, 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 implem ented by a hostile party. The workstation on the internal network has been compr omised and a covert channel has been brought online by a Trojan. The firewall al lows certain protocols (e.g. HTTP, HTTPS, DNS) to pass between the internal netw ork 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 tr affic flow and whether or not the flow is continuous or blocked; this is demonst rated 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| Fragm ent Offset....| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding....| +-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The IP v4 header con tains several fields that may be utilized to implement a covert channel; the fie lds 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 Po rt | 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).........| P adding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dat a | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The TCP he ader 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 Numb er | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data .. ...................................................| +-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The ICMP header contains a single field th at may be utilized to implement a covert channel; the field in question is highl ighted 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. An nex 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 f ields 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 "Tragedi e 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 int erval 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.pqsne t.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 informat ion deals with the decades-old concepts of system-based covert channels. This be ing stated, the majority of the information regarding network based covert chann els was gleaned from the works of: a. Mr. Marc Smeets and Mr. Matthijs Koot ("Re search 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 Repor t: Analysis and Detection of Network Covert Channels"); and e. Mr. David Llamas et al (various documents). Gracious thanks are hereby extended to these professi onals without whose superb and detailed work this report would not have been pos sible. A-8

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close