Z. Kwecka, BSc (Hons) Network Computing, 2006 81 Introduction1.1 Project OverviewThe foundation of the current most popular data channel, the Internet, is made ofprotocols, which allow a considerable amount of “freedom” to their designers. Eachof those protocols was defined based on a number of vendor specificimplementations, in order to provide common procedures for cross vendorcommunication. Thus, every millisecond there is thous<strong>and</strong>s of bits of optional <strong>and</strong>redundant information being exchanged between computers from around the World.Those bits may be employed by intruders, criminals, <strong>and</strong> possibly even terrorists invarious types of malicious activity, since they are usually treated as irrelevant <strong>and</strong>ignored by the security systems. There are very high chances of those bits being usedby perpetrators to implement covert channels, which are a form of secretcommunication medium. This poses a large risk to public <strong>and</strong> private informationconfinement.The overall aim of this Honours project is to investigate data hiding in the <strong>Application</strong><strong>Layer</strong> of Internet protocol suite <strong>and</strong> the main focus is on the detection of covertcommunication. Therefore, research into technology <strong>and</strong> knowledge required to builda successful covert channel detector <strong>and</strong> limiter were conducted. This includedliterature review of recent research publications dealing with covert channels, whitepapers <strong>and</strong> RFCs of specific technologies. In addition a prototype of <strong>Covert</strong> <strong>Channel</strong>Detection System (CCDS) was designed <strong>and</strong> implemented in order to evaluate datagathered. The intentions were to establish whether detection <strong>and</strong> elimination of thecovert channels is possible, <strong>and</strong> where the further work should be conducted in orderto achieve those goals.1.2 BackgroundThe foundations of Internet were built in accordance to 7-layer Open SystemInterconnection (OSI) model, suggested by the International St<strong>and</strong>ard Organisation(ISO). Each of the layers provides well-defined services to the layer directly above<strong>and</strong> exchanges data or control information with corresponding layer on remotemachine. It is also capable of employing services from the layer directly below. Forwell-defined services to operate, protocol stacks were designed to be as universal aspossible, <strong>and</strong> are defined in a way which is called “open”. Most implementations havean open-ended list of protocols that they are capable of providing services to. Forexample, the <strong>Layer</strong> 3 IP protocol carries an 8-bit protocol type field, thus allowing itto transfer 255 different <strong>Layer</strong> 4 protocols, of which only 138 are defined, 115 arefree for further development, <strong>and</strong> 2 are left for testing <strong>and</strong> experimental purposes.IP is the most widely employed protocol for computer networking <strong>and</strong> we can clearlystate that its versatility greatly contributed to this. However, the flexibility of Internetcommunication protocols, which allowed for the dream of simple data sharing, has atrade off, which is security. Optional protocols’ fields <strong>and</strong> variables which aretransmitted only to be ignored or discarded at the receiving end, pose a large threat forinformation confinement. Thus, organizations which permit any form ofcommunication of their employees, or computer systems, with the outside world,consequently consent for an arbitrary data leakage from their networks. Of course the
Z. Kwecka, BSc (Hons) Network Computing, 2006 9companies try to protect themselves from Internet threats in various ways, such aswith firewalls, proxies, <strong>and</strong> so on, but most of them focus only on direct informationtransfers, <strong>and</strong> neglecting the possibility of transferring data by other means. Astatefull firewall, often considered as sufficient protection by network administrators,acts like a locked gateway, allowing packets on selected <strong>Layer</strong> 4 ports to leave <strong>and</strong> thereturn packets to enter the secure perimeter. Thus only connections which originatedfrom within the network can proceed. Unfortunately, not all of these devices areperfect <strong>and</strong> methods for their deception exist, but what is even more important is thatmost of the time a message originating from within a network is allowed onto theInternet. Thus, this kind of protection is not enough to ensure confidentiality ofcorporate <strong>and</strong> private data. Some organisations may say that they trust all the users oftheir network, <strong>and</strong> there is no need to filter data leaving the network. But most ofthem neglect the fact that the users of the network are not only human operators, butalso automated software <strong>and</strong> hardware. Furthermore not all of these automatedsystems are legitimate, <strong>and</strong> some of them are malicious agent installed by hackers, oraccidentally downloaded by legitimate system users.The numbers of existing implementations of malicious agents are large <strong>and</strong> growevery day, so to protect against data leakage <strong>and</strong> dangerous software manyorganizations implement Proxy servers <strong>and</strong> intrusion detection systems (IDS). Proxyservers are protocol specific tools that act almost as transceivers 1 , where they check<strong>and</strong>, if required, modify data transfers between two environments, where the IDSsconstantly monitor the network traffic, examining data content, statistic <strong>and</strong> any otherinformation useful in detection of malicious operations. These precautions give higherlevel of protection, however, most of them examine only legitimate data channels,that in the data payload <strong>and</strong> the transaction headers, while the legitimate data channelsare not the only way that information may leave secure perimeter. B. W. Lampson inhis document “A Note on the Confinement Problem” (Lampson, 1973) was first toformally suggest possibility of creating computer communication channels byemploying methods originally not intended for any form of communication. He calledthem covert channels <strong>and</strong> considered them to be one of the greatest threats toconfinement of information.1.3 <strong>Covert</strong> <strong>Channel</strong>s TerminologyThe term covert channel describes a secret communication technique employed bytwo or more parties allowed to exchange information, while they assume the datachannel in use is under surveillance. Thus, they modify the content of the genuine lowsecurity message or the envelope used to carry this message, so that eavesdroppercannot read from the secret channel.EVEALICEBOBFigure 1-1 Communicating parties A <strong>and</strong> B, with eavesdropper E1 device capable of both transmitting <strong>and</strong> receiving, often used to allow connections between twodifferent technologies, devices or transmission mediums;
- Page 1 and 2: Application Layer Covert ChannelAna
- Page 3 and 4: Z. Kwecka, BSc (Hons) Network Compu
- Page 5 and 6: Z. Kwecka, BSc (Hons) Network Compu
- Page 7: Z. Kwecka, BSc (Hons) Network Compu
- Page 11: Z. Kwecka, BSc (Hons) Network Compu
- Page 14: Z. Kwecka, BSc (Hons) Network Compu
- Page 17 and 18: Z. Kwecka, BSc (Hons) Network Compu
- Page 19 and 20: Z. Kwecka, BSc (Hons) Network Compu
- Page 21 and 22: Z. Kwecka, BSc (Hons) Network Compu
- Page 23 and 24: Z. Kwecka, BSc (Hons) Network Compu
- Page 25: Z. Kwecka, BSc (Hons) Network Compu
- Page 28 and 29: Z. Kwecka, BSc (Hons) Network Compu
- Page 30 and 31: Z. Kwecka, BSc (Hons) Network Compu
- Page 32 and 33: Z. Kwecka, BSc (Hons) Network Compu
- Page 34 and 35: Z. Kwecka, BSc (Hons) Network Compu
- Page 36 and 37: Z. Kwecka, BSc (Hons) Network Compu
- Page 38 and 39: Z. Kwecka, BSc (Hons) Network Compu
- Page 40 and 41: Z. Kwecka, BSc (Hons) Network Compu
- Page 42 and 43: Z. Kwecka, BSc (Hons) Network Compu
- Page 44 and 45: Z. Kwecka, BSc (Hons) Network Compu
- Page 46 and 47: Z. Kwecka, BSc (Hons) Network Compu
- Page 48 and 49: Z. Kwecka, BSc (Hons) Network Compu
- Page 50 and 51: Z. Kwecka, BSc (Hons) Network Compu
- Page 52 and 53: Z. Kwecka, BSc (Hons) Network Compu
- Page 54 and 55: Z. Kwecka, BSc (Hons) Network Compu
- Page 56: Z. Kwecka, BSc (Hons) Network Compu
- Page 60 and 61:
Z. Kwecka, BSc (Hons) Network Compu
- Page 63 and 64:
Z. Kwecka, BSc (Hons) Network Compu
- Page 65 and 66:
Z. Kwecka, BSc (Hons) Network Compu
- Page 67 and 68:
Z. Kwecka, BSc (Hons) Network Compu
- Page 69 and 70:
Z. Kwecka, BSc (Hons) Network Compu
- Page 71 and 72:
Z. Kwecka, BSc (Hons) Network Compu
- Page 73 and 74:
Z. Kwecka, BSc (Hons) Network Compu
- Page 75 and 76:
Z. Kwecka, BSc (Hons) Network Compu
- Page 77 and 78:
Z. Kwecka, BSc (Hons) Network Compu
- Page 79 and 80:
Z. Kwecka, BSc (Hons) Network Compu
- Page 81 and 82:
Z. Kwecka, BSc (Hons) Network Compu
- Page 83 and 84:
Z. Kwecka, BSc (Hons) Network Compu
- Page 85 and 86:
Z. Kwecka, BSc (Hons) Network Compu
- Page 87 and 88:
Z. Kwecka, BSc (Hons) Network Compu
- Page 89 and 90:
Z. Kwecka, BSc (Hons) Network Compu
- Page 91 and 92:
Z. Kwecka, BSc (Hons) Network Compu
- Page 93 and 94:
Z. Kwecka, BSc (Hons) Network Compu
- Page 95 and 96:
Z. Kwecka, BSc (Hons) Network Compu
- Page 97 and 98:
Z. Kwecka, BSc (Hons) Network Compu
- Page 99 and 100:
Z. Kwecka, BSc (Hons) Network Compu
- Page 101 and 102:
Z. Kwecka, BSc (Hons) Network Compu
- Page 103 and 104:
Z. Kwecka, BSc (Hons) Network Compu
- Page 105 and 106:
Z. Kwecka, BSc (Hons) Network Compu
- Page 107 and 108:
Z. Kwecka, BSc (Hons) Network Compu
- Page 109 and 110:
Z. Kwecka, BSc (Hons) Network Compu
- Page 111 and 112:
Z. Kwecka, BSc (Hons) Network Compu
- Page 113:
Z. Kwecka, BSc (Hons) Network Compu
- Page 116 and 117:
Z. Kwecka, BSc (Hons) Network Compu
- Page 118 and 119:
Z. Kwecka, BSc (Hons) Network Compu
- Page 120 and 121:
Z. Kwecka, BSc (Hons) Network Compu
- Page 122 and 123:
Z. Kwecka, BSc (Hons) Network Compu
- Page 124 and 125:
Z. Kwecka, BSc (Hons) Network Compu
- Page 126 and 127:
Z. Kwecka, BSc (Hons) Network Compu
- Page 128 and 129:
Z. Kwecka, BSc (Hons) Network Compu
- Page 130 and 131:
Z. Kwecka, BSc (Hons) Network Compu
- Page 132 and 133:
Z. Kwecka, BSc (Hons) Network Compu
- Page 134 and 135:
Z. Kwecka, BSc (Hons) Network Compu
- Page 136 and 137:
Z. Kwecka, BSc (Hons) Network Compu
- Page 138:
Z. Kwecka, BSc (Hons) Network Compu