Covert File Transfer Protocol Based on the IP Record ... - CiteSeerX

55 downloads 1967 Views 692KB Size Report
information. Encryption only protects communication from being ... technique that offers a covert file transfer protocol (CFTP) based on the .... across the Internet.
Journal of Information Assurance and Security 5 (2010) 064-073

Covert File Transfer Protocol Based on the IP Record Route Option Zouheir Trabelsi and Imad Jawhar UAE University, College of Information Technology, P.O. Box 17551, Alain, UAE {trabelsi, ijawhar}@uaeu.ac.ae

Abstract: Covert channels are used for secret transfer of information. Encryption only protects communication from being decoded by unauthorized parties, whereas covert channels aim to hide the very existence of communication. This paper discusses a novel covert file transfer protocol (CFTP) based on the IP record route option. The CFTP protocol is used to secretly transfer text files and short messages between hosts. Firewalls that limit the outgoing traffic to a few allowed application protocols (e.g. FTP) can be circumvented by the CFTP protocol. To demonstrate the practical efficiency of the proposed covert protocol, a user friendly tool based on the client/server technology is implemented. Compared to related research, the main contribution in this work is that it introduces a new generation of covert channels. The proposed protocol is based on a novel session-oriented mechanism that offers TCP-like features embedded inside the IP option field. It provides more sophisticated communication tools that can be used for hiding information as well as synchronizing sessions and controlling the flow of exchanged data between hosts. Keywords: Covert channel and protocol, TCP/IP protocols, IP record route option, File Transfer Protocol (FTP).

network security. Furthermore, because of increased measures against open channels, such as the free transfer of memory storage devices in and out of organizations as described in [4], the use of covert channels in computer networks will increase. Understanding existing covert channel techniques is crucial to the development of countermeasures. The detection, elimination, and capacity limitation of covert channels are challenging but need to be addressed to secure future computer networks [5]. In this paper, a new covert channel technique that offers a covert file transfer protocol (CFTP) based on the record route option of the IP header and ICMP traffic is presented. A user friendly tool based on the client/server model is implemented in order to demonstrate the practical efficiency of the proposed covert channel. The rest of the paper is organized as follows. Section 2 presents some related work. Section 3 discusses the IP record route option. Sections 4 and 5 describe the proposed covert channel protocol and its implementation. Section 7 offers a related discussion, and the last section concludes the paper.

1. Introduction

2. Related work

The concept of a covert channel was first introduced by Lampson [1] as a channel that is used for information transfer, and is not designed nor intended for communication. Such channels are used for secret transfer of information. Typically, they use communication means which are not normally intended to be used for data transfer. This property makes them quite elusive. In computer networks, overt channels, such as typical network protocols, are used as carriers for covert channels [2, 3]. Covert channels in computer network protocols are similar to techniques for hiding information in audio, visual or textual content (steganography). While steganography requires some form of content as cover, covert channels require some network protocols as carrier.

Zander et al. provided an excellent overview and classification of existing covert channel techniques in computer network protocols [5]. In contrast to previous work Zander et al. grouped channels according to their mechanism and not just based on the layers of the Open Systems Interconnection (OSI) model. Eighteen groups have been proposed to describe existing covert channels. We believe their approach is advantageous because it provides a more fine-grained classification and also accommodates the fact that some methods could be applied similarly in different OSI layers.

A diverse range of individuals and groups have found reasons to utilize covert channels for communication and coordination. Typically this is motivated by the existence of an adversarial relationship between two parties. In addition, many organizations and groups have an interest to keep their communication secret. However, simply using encryption does not prevent adversaries from detecting communication patterns. Often, only the evidence of communication taking place is sufficient to detect the onset of activity, discover organizational structures or justify further investigation. Covert channels aim to hide the very existence of the communication. Many applications of covert channels are of a malicious or unwanted nature, and therefore pose a serious threat to

(1) Header extensions and padding:

Received September 10, 2009

Two groups of covert channels are related to the proposed one in this paper. They are the following:

Many protocols support extension of the standard headers. Usually there are some pre-defined header extensions that allow transporting non-mandatory information on demand, but many protocols also allow header extensions to carry data not foreseen in the original specification, extending the capabilities of the protocol. Graf proposed transmitting covert information in the IPv6 destination options header [6]. This header carries optional information for the packet’s destination node. If the option type is set so that the receiver ignores the option, covert information can be directly encoded as option data. Lucena et 1554-1010 $ 03.50 Dynamic Publishers, Inc.

Trabelsi and Jawhar

065

al. identified covert channels in the IPv6 hop-by-hop, routing, fragment, authentication and encapsulating security payload extension headers [7]. Trabelsi et al. proposed to hide covert data masked as IP addresses in the IP record route option [8]. Covert information can be encoded in frame or packet padding. For example, Ethernet frames must be padded to a minimum length of 60 bytes. If the protocol standard does not enforce specific values for the padding bytes, any data can be used [9, 10]. Padding of the IP and TCP header to 4-byte boundaries (in case header options are present) and padding in IPv6 can also be used to transmit covert data [7, 9]. All of the above covert channels allow sending secret data by embedding it in extended standard headers. However, these covert channels do not discuss the synchronization of the transfer sessions and the control of data flow between the involved hosts. (2) Payload tunnelling: Payload tunnels are covert channels that tunnel one protocol (usually the IP protocol) in the payload of another protocol. The main purpose of these channels is circumventing firewalls that limit outgoing traffic to a few allowed application protocols (e.g. HTTP). Therefore, most of these channels do not aim for stealth but rather for maximizing the throughput. A variety of tools exist for tunnelling over application protocols that are often not blocked such as ICMP [11] or HTTP [10]. One of the first approaches for tunnelling protocols over ICMP was Loki, which tunnelled data in the payload of ICMP echo messages [13]. Today many IP-over-ICMP tunnel solutions exist, for example Stødle implemented another IP-over-ICMP tunnelling tool [14]. Zelenchuk implemented an indirect IP-over-ICMP tunnel [15]. The covert sender sends echo request packets to a bounce host with a spoofed source address (set to the address of the covert receiver) and encodes the covert data in the payload. The bounce host then sends echo replies to the covert receiver with the same payload as in the requests.

the proposed steganographic routing, its convergence time, and available range. Existing covert channels have been restricted to covert transmission of only small amounts of data. However, Ray [21] demonstrated that it is possible to transmit large amounts of data covertly with sophisticated support such as security and reliability. The proposed protocol exploits the ICMP echo request as a covert medium, and uses OS finger printing techniques to simulate real TCP/IP stack behaviour for further security enhancements. Instead of encoding new information into unused (or loosely specified) IP packet header fields, or the time intervals between IP packet arrivals [22, 23], S. Zander [24] proposed a novel covert channel embedded within the traffic of multiplayer, first person shooter online games. Movement information is propagated to all clients attached to a given game server, yet the channel remains covert so long as the variations are visually imperceptible to the human players. However, this type of covert channels requires the users to be attached to a given server.

3. The IP Record Route Option In order to introduce the terms used by the proposed covert channel and lay the groundwork for what follows, we will introduce the IP record route option [25]. The Internet Protocol (IP) is the most commonly used protocol in the network layer today, and is used for all traffic moving across the Internet. Upon receiving a TCP, UDP or ICMP packet, the IP protocol generates a header which includes the source and destination IP addresses. An IP header is added to the front of a TCP, UDP or ICMP packet to create the resulting IP packet, which will be used to carry the entire contents (IP header, TCP/UDP/ICMP header, and application-level data) across the network. Figure 1 shows the format of the IP header.

Another popular method is to tunnel protocols over HTTP. Padgett developed a tool that tunnels SSH over HTTP proxies [16]. Dyatlov and LeBoutillier implemented tools for tunnelling UDP or TCP over HTTP [17, 18]. Lundström implemented a tool that can establish a bi-directional tunnel over the exchange of emails [19]. The payload tunnels use data fields of the common IP/ICMP/TCP/UDP headers. Obviously, the existence of hidden data in data fields can be easily identified. Since, usually these headers do not carry data inside their data fields. However, our proposed covert channel does not use these data fields. Instead, it uses the fields of the IP header options. Szczypiorski [20] presented the concept of a distributed steganographic router that provides the ability to create the covert channels between chosen agents. Paths between the agents can be built with the use of any of the steganographic methods in any network layer and be adjusted to the heterogeneous characteristics of a given network. This work has major limitations, since it lacks performance analysis of

Figure 1. The IP header An IP header without options has a length of 20 bytes. However, an IP header with options may have a length of 60 bytes. It is important to indicate that most IP packets do not use the Options field. Therefore, a covert channel can use the unused 40 bytes of the Options field to carry hidden information in the IP packets. The IP Options field is not required in every datagram; options are included primarily for network testing or debugging. Option processing is an integral part of the IP protocol, and all standard implementations must include it. Figure 2 shows the structure of the IP Option filed.

Covert File Transfer Protocol Based on the IP Record Route Option

066

Table 2. The most used IP options. OPTION CLASS 0

OPTION NUMBER 3

0

7

0

9

2

4

Figure 2.The structure of the IP Options field The length of the IP Options field varies depending on which options are selected. Some options are one byte long; they consist of a single option code byte. Other options, such as the Timestamps record and the Strict source routing, have variable lengths. Each option consists of a single octet option code, which may be followed by a single octet length and a set of data octets. The option code byte is divided into three fields as shown in Figure 3.

Figure 3.The field code of the IP header option The fields consist of a 1-bit copy flag, a 2-bits option class, and a 5-bits option number. The copy flag controls the way gateways treat options during fragmentation. When the copy bit is set to 1, it specifies that the option should be copied into all fragments. When it is set to 0, it means that the option should only be copied into the first fragment and not into all fragments. The option class and option number bits specify the general class of the option, and the specific option in that class, respectively. Table 1 shows how classes are assigned.

DESCRIPTION Loose Source Routing. Used to route a datagram along a specified path Record route. Used to trace a route Strict source route a datagram along a specified path Internet timestamp. Used to record time tamps along a route

Whenever a host handles a datagram that has the record route option set, the host adds its IP address to the record route list (enough space must be allocated in the option by the original source to hold all entries that will be needed). To add itself to the list, a host first compares the pointer and length fields. If the pointer is greater than the length, then the list is full and the host forwards the datagram without inserting its IP address. If the list is not full, the host inserts its 4-octet IP address at the position specified by Pointer, and increments the value in the Pointer by four.

Figure 4. The format of the record route option in an IP datagram

Table 1. The Class field OPTION CLASS 0 1 2 3

MEANING Datagram or network control Reserved for future use Debugging and measurement Reserved for future use

Table 3. The standard values of the fields of the IP option FIELDS Code Maximum Length Pointer

VALUE 7 39 4

There are eight possible options that can accompany an IP datagram. Table 2 lists the most used options and gives their option class and option number values. As the list shows, most options are used for control purposes.

4. The IP Record Route Option Based Covert Channel

The record route option allows the source to create an empty list of IP addresses and arrange for each gateway that handles the datagram to add its IP address to the list. Figure 4 shows the format of the record route option. As described above, the Code field contains the option number and option class (e.g. 7 for record route option). The Length field specifies the total length of the option as it appears in the IP datagram, including the first three octets. The Pointer field specifies the offset within the option of the next available slot. The remaining area in the Options field is reserved for recording IP address entries.

When the IP header option designates a record route, the fields Code and Pointer should be set to the values 7 and 4, respectively. The maximum value in the Length field should be 39. These fields and their corresponding values are listed in Table 3.

4.1 The principle of the covert channel

In its way to the destination, each router writes its IP address in the 4-byte-field pointed by the value in the Pointer field. Figure 5 shows the fields in the record route option. Then, the value of the Pointer field in the IP header option is increased by 4. Consequently, the next router would write its IP address in the next 4-byte-field. However, if the value of the Pointer

067

Trabelsi and Jawhar

field becomes greater than the value of the Length field, then no more routers can write their IP addresses.

• •

Figure 5. A normal IP record route option Therefore, we may establish a covert channel if the initial value of the Pointer field is greater than the value of the Length field, or just greater than the length of the hidden message. Specifically, if we set the initial value of the Pointer field greater than the value of the Length field, then no router can write its IP address. In this case, we can use all the remaining 36 bytes of the IP header option to insert a hidden message. This is shown in Figure 6.a. However, if we set the initial value of the Pointer field to a value greater than the length of the hidden message, then a number of routers can still write their IP addresses in the remaining bytes of the IP header option. This is shown in Figure 6.b.





Undetectability: Sniffers are unable to detect the hidden messages which are assumed to be router IP addresses. Large amount of covert memory: The proposed technique offers 40 bytes of covert memory which is considerably larger than the 4 byte size available in TCP based covert channel [28]. Flexibility: the covert channel in [28] has to follow restrictions and the rules imposed by the TCP protocol including synchronisation, flow control and congestion control. In contrast, the proposed techniques can exclusively rely on ICMP traffic to carry hidden messages. The good rate of privacy, memory and flexibility provided by the proposed covert channel, allow defining a secret transfer protocol that exploits these features at a maximum level. The protocol is called Covert File Transfer Protocol (CFTP). The following section describes the proposed CFTP protocol in more detail.

[a] : The ICMP echo request packet carries the message “This is a covert channel” in the Options field. [b]: The ICMP echo reply packet is where the first host (which is the destination host = 172.16.16.20) wrote its IP address just after the hidden message.

Figure 7. An ICMP packet carrying a hidden message Figure 6. The different values of the Pointer field used for the covert channel 4.2 Example Frameip packet generator [26] is used to generate an ICMP Ping packet [27] including the record route option. The value of the Pointer field in the packet is set to be greater than the value of the Length field. The IP addresses of the source and destination hosts are 172.16.16.3 and 172.16.16.20, respectively. The hidden message written in the Options field is: “This is a covert channel” and its length is 24 bytes. Consequently, the value of the Length field is 39 bytes. The value of the Pointer field is set to 28, in order to force any router to write its IP address in the 4-byte-field that just follows the hidden message. The contents of the Options field in the sent and received packets are decoded using the Ethereal Sniffer program. Figure 7 shows that the first router (which is the destination host in our case) has inserted its IP address just after the hidden message. Using this technique, a covert channel is established and a secure communication using hidden messages can be done. This technique has the following advantages:

5. The Covert File Transfer protocol – CFTP Common file transfer protocols, such as FTP [29] and TFTP [30], are application layer protocols and use either TCP or UDP as the transport layer protocol. CFTP allows downloading and uploading hidden text files, as well as sending hidden short messages. However, CFTP uses neither TCP nor UDP; rather it uses the ICMP protocol to transport covert data within the IP record route option. CFTP protocol is a client/server application. Therefore, it requires mechanisms to be able to establish and terminate sessions, as well as synchronize data transfer between the clients and the server. For FTP, this is assured by the TCP protocol which is not used by CFTP. In order to achieve these functions, the structure of the IP record route option has been modified to include the necessary fields. Figure 8 shows the structure of the IP record route option along with added fields to enable the following functions: • To open a connection by the CFTP client with the CFTP server • To acknowledge packets carrying secret data and text • To terminate a session. • To control the packet’s sequence numbers

Covert File Transfer Protocol Based on the IP Record Route Option

068

4.

It is used by the CFTP server to inform the CFTP client about the offered privileges which specify the operations that a CFTP client is allowed to perform on the CFTP server. As shown in Figure 9, there are 4 bits corresponding to the offered privileges: • View the list of files to be downloaded. • Download text files. • Upload text files. • Send SMS messages.

Figure 8. The new IP record route option structure used by the CFTP protocol All the fields in this new structure, except the “Hidden Message” field, constitute the header of the CFTP protocol. These fields are used to control the session between the CFTP client and the CFTP server. The “Hidden Message” field is the location where the secret data will be inserted. The following are the fields in the new structure: • •

The Code, Length and Pointer fields have the same function as in a normal IP record route option. The Flags field: o

o o

SMS = 1 means the packet carries a hidden short message (SMS) and not a part of a hidden text file. RET = 1 means the packet is a re-transmission of a lost packet. SYN, ACK and FIN have the following functions which are similar to the ones used by the TCP protocol: • • • • •

SYN = 1 means a request to establish a CFTP session. ACK = 1 means that this packet has an acknowledgement. FIN = 1 means a request to terminate a CFTP session. The Number field has 4 functions which are discussed in the next section. The EOL (End of List) field must be set to zero, and it is a padding field.

5.1 The Number field Depending on the type of the packets exchanged between the CFTP server and the CFTP client, the Number field has 4 functions: 1. 2. 3.

It is used by the CFTP server to inform the CFTP client about the total packets that will be sent. It is used by the CFTP client to inform the CFTP server about the total lost packets. It is used by the CFTP server or the CFTP client to indicate the packets sequence numbers, during the downloading or uploading phases, respectively.

Figure 9. The structure of the Number field when it is used to indicate the offered privileges. A value of 1 for corresponding bit indicates an offered privilege. Figure 10 shows an example in which the CFTP client is not allowed by the CFTP server to view the list of hidden text files that can be downloaded. However, the client is allowed to upload hidden text files and send hidden SMS messages. Therefore, the value of the Number field is: 00001100.

Figure 10. An example of offered privileges 5.2 CFTP session establishment This section describes how a CFTP client can establish a session, download/upload a hidden text file, and send a hidden SMS message. As mentioned earlier, the CFTP protocol should provide means for establishing and terminating sessions, and controlling the traffic flow. This is required because CFTP protocol is not built on top of the TCP protocol which normally handles these functions. In order to establish a session with the CFTP server, a CFTP client needs to send an ICMP packet which has the headers shown in Figure 11. In the IP record route option, the Code field is set to 7 (record route option code), Length field is set to 39, and the Pointer field is set to 40. The values for the length and pointer fields are chosen in such a way that routers located between the CFTP server and the client do not write their IP addresses in location previously reserved for the intermediate router IP addresses and newly reserved for the hidden data. This is because the value in the Pointer field (40) is greater than the value in the Length field (39).

Trabelsi and Jawhar

069

Figure 13. The contents of the fields of the CFTP header in Packet 2 Figure 11. The headers in a CFTP packet. Figure 12 shows the session establishment scenario between the client and the server in which following packets are exchanged:

5.3 Downloading a hidden text file: The “get” command in the CFTP server Once a session is established with the CFTP server, the client will attempt to download a text file. The different exchanged packets are:



Packet 1: The first packet is used to establish a session with the CFTP server (the bit SYN = 1).





Packet 2: The CFTP server sends a packet to the client to establish a session (the bit SYN = 1) and acknowledge the received packet (the bit ACK = 1). The command-reply 220 is used to indicate that the CFTP server is asking for the login and password of the client. We use the same command-reply used by the standard FTP protocol. Figure 13 shows the contents of the different fields of the CFTP header.



• • •

Packets Packet 1 (from client to server) Packet 2 (from server to client) Packet 3 (from client to server) Packet 4 (from server to client) Packet 5 (from client to server)

Flags

Number

Message

SYN

0

nothing

SYN-ACK

0

ACK

0

220 CFTP service login / password

ACK

Privileges

ACK

0

331 welcome to CFTP nothing

Figure 12. The CFTP connection scenario •

Packet 3: The CFTP client sends the login and password to the CFTP server.



Packet 4: The CFTP server sends to the client its corresponding privilege. If the privilege value is zero, then an authentication error has occurred and the Message field is empty. If the privilege indicates that the client can not see the list, then the Message field is empty but no error message will be shown to the client. In all the remaining cases, the Message fields contains the command-reply sequence 331 defined by the standard FTP protocol.



Packet 5: This packet is the acknowledgement packet of the Packet 4.



Packet 1: This is a SYN packet sent from the client which carries the name of the file selected to be downloaded. Packet 2: This is a SYN-ACK packet sent from the server that carries the total number of packets that will be sent. This number is obtained by dividing the file size by 34. Packet 3 - Packet n: These packets sent from the server carrying the contents of the file. Packet n+1: This is an optional packet that carries the total number of lost packets and their corresponding numbers. The subsequent packets: These are optional packets that constitute retransmissions of the lost packets. The last packet: FIN-ACK packet sent by the client to indicate that the file is successfully downloaded.

A CFTP client can download text files only if it has the appropriate privilege. Figure 14 describes the different packets exchanged between the CFTP server and the client when downloading a text file. The standard FTP protocol offers a variety of services that use a large number of specific commands. However our proposed CFTP protocol does not need this large number of commands, since it is used simply for downloading and uploading hidden text files. Operations such as directory creation, directory change, binary transfer, and removing files are not essential and might be added in the future. The proposed CFTP protocol includes only the two most important and common FTP commands “get” and “put”. 5.4 Retransmission of lost packets The command “get file.txt” allows a CFTP client to download a hidden text file. The CFTP server calculates the total number of packets that should be sent. The TCP protocol uses windows to control the packet flow and retransmission of lost packets. The CFTP protocol uses a simple algorithm to retransmit lost packets, namely:

Covert File Transfer Protocol Based on the IP Record Route Option

After receiving the total number of packets that will be sent, the CFTP client waits for the first packet. b. When the first packet is received, the client waits for the second one. c. If the client does not receive a packet within a timeout, then the client considers that packet as a lost packet. Hence, the client waits for the packet that normally follows the lost packet. d. When a client receives the FIN packet or the total number of received packets reaches the expected maximum number, then the client sends an ACK packet carrying the number of lost packets. All this process is repeated until there are no lost packets.

070

a.

Packets Packet 1 (from client to server) Packet 2 (from server to client)

Flags SYN

Packet 3 (from server to client) Packet 4 (from server to client) … … Packet n (from server to client) Packet n+1 (from client to server) … (from server to client) … (from server to client) … (from server to client) … (from client to server)

SYN-ACK

Number 0

Message Get file nothing

ACK

Total number of packets to receive 1 (packet 1)

ACK

2 (packet 2)

Second 34 bytes of the file

Packets Packet 1 (from client to server)

Flags SYN

Packet 2 (from client to server) Packet 3 (from client to client) … … Packet n (from client to server) Packet n+1 (from server to client)

ACK

Number Total number of packets to receive 1 (packet 1)

Message Put filename

ACK

2 (packet 2)

FIN

n (packet n)

ACK

Total number of lost packets

… (from client to server) … (from client to server) … (from server to client) … (from server to client)

RET

x (packet x)

Last 34 bytes of the file The numbers list of lost packets (for example: x/y/z) xth 34 bytes of the file

RET

y (packet y)

yth 34 bytes of the file

RET

z (packet z)

zth 34 bytes of the file

FIN-ACK

0

nothing

First 34 bytes of the file Second 34 bytes of the file

Figure 15. The command “put” of the CFTP protocol First 34 bytes of the file

FIN

n (packet n)

Last 34 bytes of the file

ACK

Total number of lost packets

RET

x (packet x)

The numbers list of lost packets (for example: x/y/z) xth 34 bytes of the file

RET

y (packet y)

yth 34 bytes of the file

RET

z (packet z)

zth 34 bytes of the file

FIN-ACK

0

nothing

(*) Packet n+1 can be repeated until here are no lost packets Figure 14. The command “gets” of the CFTP protocol 5.5 Hidden text files uploading: The “put” command in the CFTP server

Packets

Flags

Number

Message

Packet 1 (from client to server)

SMS

0

The 34 bytes of the SMS

Figure 16. Hidden SMS message transmission

6. Implementation A client/server GUI tool was implemented based on the proposed CFTP protocol, and using the library Winsock2 and the graphic library Wtl in Visual C++ environment. Figures 17 and 18 show the GUI interfaces of the CFTP client and server, respectively. In Figure 19, the Server Report option in the tool shows the entire received hidden SMS message as well as the downloading and uploading activities.

7. Discussion A CFTP client host can upload hidden text files only if it has the privilege for doing that. Figure 15 shows the different packets exchanged between a CFTP client and server when uploading a hidden text file. The uploading process is similar to the downloading process, but the text file is located on the CFTP client side. The packet containing the total number of the packets that will be sent to the CFTP server, is generated by the CFTP client. 5.6 Hidden SMS message The CFTP protocol allows sending a short hidden SMS message in a single packet. The maximum size of the message is 34 bytes. Figure 16 shows a packet containing a hidden SMS message sent by a CFTP client to a CFTP server.

7.1 Circumventing firewalls One of the main purposes of the proposed covert channel is circumventing firewalls that limit outgoing traffic to a few allowed application protocols (e.g. HTTP). That is, in a network, if the firewall does not allow FTP traffic between inside hosts and outside hosts, then the proposed CFTP can be used to transfer secretly text file and message using IP traffic that is usually allowed by the firewall. For example, if some types of ICMP traffic (e.g. ICMP Ping) or HTTP traffic, which use IP protocol as the transport protocol, are allowed by the firewall, then CFTP can establish a covert FTP session and assure the secret transfer of messages.

Trabelsi and Jawhar

071

7.2 Eliminating and detecting covert channels Covert channels based on non-standard use of the protocol can be detected easily. All proposed detection methods are based on the detection of non-standard or abnormal behaviour (anomaly detection) [5]. Furthermore, some proposed covert channels are obsolete because previously unused bits are now used. For example, some unused bits in the IP header are now widely used for explicit congestion notification. In addition, defined messages, or extension headers are de-facto not used anymore and their appearance would be suspicious. (e.g. ICMP-based flow control and IP timestamp header extensions). Some covert channels described previously exploit the fact that header fields can have arbitrary values within the requirements of the standard. However, if the fields are naively used and the resulting value distributions are different from the distributions generated by real operating systems, the covert channels are easy to detect as demonstrated for IP ID channels in [31]. While it is possible to detect many of the proposed covert channels, every channel that looks identical to normal use of the protocol will be harder to detect. For example, Murdoch’s TCP ISN channel has a value distribution matching the distribution of real operating systems [31], and Lucena’s SSH MAC channel has statistical characteristics identical to real MACs [32]. The only way that allows to reliably detect these covert channels is to somehow detect the embedding process at the covert sender.

IP traffic with IP record route option. However, if a security device (e.g. Firewall) is set to filter such IP traffic, then the covert channel may not work and can be easily detected by analyzing the inserted router IP addresses in the IP record route option field, and detecting that these IP addresses do not match the IP addresses of the routers in the paths took by the exchanged IP traffic.

Figure 19. CFTP Server Report Another approach to counter covert channels is to block protocols/ports that are susceptible. For example, ICMP is blocked by many firewalls these days rendering approaches such as Loki [13] ineffective. Obviously, in the Internet some protocols cannot be blocked because they are vital (e.g. IP, TCP, DNS), or because their services are too important (e.g. E-mail, Web). The proposed covert channel in this paper uses IP traffic which cannot be blocked since most Internet traffic (ICMP, TCP and UDP) is based on IP traffic.

Figure 17. GUI interface of the CFTP client Figure 20. Random ICMP traffic exchanged between a CFTP client and a CFTP server 7.3 Protection against eavesdropping attacks 7.3.1 Avoiding one type of ICMP packet traffic

Figure 18. GUI interface of the CFTP server The proposed covert channel in this paper looks identical to normal use of the IP protocol, and consequently it will be harder to detect. Many network applications require the use of

The CFTP protocol uses mainly the allowed ICMP traffic to establish a covert session and transfer secret messages. The existence of a flow of ICMP packets with the same type (e.g. ICMP echo request packets) is a strong indication of the existence of abnormal traffic or suspicious network activities. In order to avoid such a situation, the CFTP protocol generates ICMP packets with random types, such as Echo and Timestamp ICMP packets. Figure 20 shows a sample trace of randomly generated ICMP packets exchanged between a CFTP client and a CFTP server.

Covert File Transfer Protocol Based on the IP Record Route Option

7.3.2 Encrypting the hidden message Encryption can be used to further hide the messages carried by the covert channels. We choose to use a simple encryption algorithm, CESAR with a shift equal to 82, to encrypt the hidden information exchanged between the CFTP server and the CFTP client. If confidentiality is of paramount importance, the user may choose a complex cipher scheme at a cost of more complexity and resource requirements. Figure 21 shows that in a non-encrypted covert channel, the exchanged hidden message may be read using a Sniffer. On the other hand, encryption prevents reading hidden messages in covert channels.

Figure 21. Non-encrypted and encrypted covert channel

8. Conclusion This paper discusses a novel covert file transfer protocol (CFTP) based on the IP record route option. The CFTP protocol is used to secretly transfer text files and short messages between hosts. It was demonstrated that even with a Sniffer, the hidden information exchanged by the CFTP server and client cannot be identified. Since, the Sniffer’s users assume that the hidden information in the record route IP options is just a list of router IP addresses. In addition, to avoid the detection of the packet flow between the CFTP server and client, the packets exchanged do not have the same ICMP packet types. A GUI client/server tool was developed to demonstrate the practical efficiency of the proposed covert channel. Compared to related work, the major novelty of the protocol is that it provides a new generation of sophisticated covert channels that can be used not only for hiding information, but also for synchronizing sessions and controlling the flow of exchanged information between hosts. The protocol is based on a novel session-oriented mechanism that offers TCP-like features embedded inside the IP option field. The hidden information is packaged in the form of IP addresses. However, it is possible for one to verify the validity of these IP addresses in the connection path which immediately offers a means for Steganalysis.

References: [1] B. W. Lampson, “A Note on the Confinement Problem,” in Proc. of the Communications of the ACM, October 1973, number 16:10, pp. 613–615. [2] C. G. Girling. Covert Channels in LAN's. IEEE Transactions on Software Engineering, SE-13(2):292-296, February 1987. [3] M. Wolf, “Covert channels in LAN protocols,” in Proceedings of the Workshop on Local Area Network Security (LANSEC’89), T. A. Berson and T. Beth, eds., pp. 91 – 102, 1989.

072

[4] S. Katzenbeisser and F. Petitcolas, “Information Hiding Techniques for Steganography and Digital Watermarking.” Computer Security Series, 685 Canton Street, Norwood, MA 02062: Artech House, Inc., 2000. [5] S. Zander, G. Armitage, P. Branch. “A Survey of Covert Channels and Countermeasures in Computer Network Protocols.” IEEE Communications Surveys and Tutorials, 9(3):44-57, October 2007. [6] T. Graf, “Messaging over IPv6 Destination Options,” Technical report, Swiss Unix User Group, 2003, http: / /grayworld. net/papers/messip6.txt. [7] N. Lucena et al., “Syntax and Semantics-Preserving Application-Layer Protocol Steganography,” Proc. 6th Information Hiding Workshop., May 2004. [8] Z. Trabelsi et al., “Traceroute Based IP Channel for Sending Hidden Short Messages,” Proc. Advances in Information and Computer Security (IWSEC), Oct. 2006, pp. 421–36. [9] T. Handel, M. Sandford. Hiding Data in the OSI Network Model. In Proceedings of the First International Workshop on Information Hiding, pages 23-38, 1996. [10] M. Wolf, “Covert Channels in LAN Protocols,” Proc. Wksp. Local Area Network Security (LANSEC), 1989, pp. 91–101. [11] A. Singh, O. Nordström, Chenghuai Lu, André L. M. dos Santos, “Malicious ICMP Tunneling: Defense against the Vulnerability,” ACISP 2003: 226-235 [12] M. Smeets and M. Koot, “Research Report: Covert Channels,” Master’s thesis, University of Amsterdam, Feb. 2006. [13] Daemon9, “LOKI2: The Implementation,” Phrack Magazine, vol. 7, no. 51, Sept. 1997. [14] D. Stødle, “ptunnel - Ping Tunnel ,” 2005, http: / /www.cs.uit.no/daniels/PingTunnel. [15] I. Zelenchuk, “Skeeve — ICMP Bounce Tunnel ,” 2004, http://www.gray-world.net/poc_skeeve.shtml. [16] P. Padgett, “Corkscrew,” 2001, http://www.agroman.net/corkscrew/. [17] A. Dyatlov, “Firepass — Is a Tunneling Tool,” 2003, http://gray-world.net/pr_firepass.shtml. [18] P. LeBoutillier, “HTTunnel,” 2005, http://sourceforge.net/projects/httunnel/. [19] M. Lundström, “MailTunnel ,” http: / /gray-world.net/tools/mailtunnel-0.2.tar.gz. [20] K. Szczypiorski, I. Margasinski, W. Mazurczyk: Steganographic Routing in Multi Agent System Environment. Journal of Information Assurance and Security, vol. 2, Issue 3, pp. 235-243, 2007. [21] B. Ray, S. Mishra: A Protocol for Building Secure and Reliable Covert Channel, In Proceedings of the Sixth Annual Conference on Privacy, Security and Trust, pp. 246 – 253, October 1-3, 2008. [22] G. Yunchuan, Y. Lihua, Z. Yuan, L. Chao, G. Li: Simulation Analysis of Probabilistic Timing Covert Channels, In the Proceedings of the 2009 IEEE International Conference on Networking, Architecture, and Storage (NAS 2009), pp. 325 – 332, 9-11 July, 2009. [23] Y. Wang; P. Chen; Yi Ge; Bing Mao; Li Xie: Traffic Controller: A Practical Approach to Block Network Covert Timing Channel. In the Proceedings of the Forth International Conference on Availability, Reliability and Security, pp. 349 – 354, 16-19 March, 2009.

073

[24] S. Zander, G. Armitage, P. Branch: Covert Channels in Multiplayer First Person Shooter Online Games. In the Proceedings of the 33rd IEEE Conference on Local Computer Networks, pp. 215 - 222 14-17 October, 2008. [25] R. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols," Addison-Wesley, 1994. [26] Frameip packet generator : http://www.frameip.com. [27] J. Postel, “Internet Control Message Protocol,” Protocol Specifications, RFC 792, DARPA Internet Program, September 1984. [28] C. H. Rowland, “Covert channels in the TCP/IP protocol suite,” Tech. Rep. 5, First Monday, Peer Reviewed Journal on the Internet, July 1997. [29] J. Postel, J. Reynolds, “RFC 959 - File Transfer Protocol (FTP),” ISI, October, 1985. [30] K. Sollins, “RFC 1350 – Trivial File Transfer Protocol (TFTP)”, July 1992. [31] S. J. Murdoch and S. Lewis, “Embedding Covert Channels into TCP/IP,” Proc. 7th Information Hiding Workshop., June 2005. [32] N. B. Lucena, G. Lewandowski, and S. J. Chapin, “Covert Channels in IPv6,” Proc. Privacy Enhancing Technologies (PET), May 2005, pp. 147–66. [33] T. Handel and M. Sandford, “Hiding Data in the OSI Network Model,” Proc. 1st Int’l. Workshop on. Information Hiding, 1996, pp. 23–38.

Author Biographies Zouheir Trabelsi is an associate professor at the College of Information Technology, the United Arab Emirates University, and the head of the Information Security Program. He received his Ph.D. from Tokyo University of Technology and Agriculture, Japan, in the field of computer science. He was a computer science researcher at the Central Research Laboratory of Hitachi in Tokyo, Japan. He was also a visiting assistant professor at Pace University, New York, USA. His research areas are mainly networking security, Intrusion Detection and Prevention, Firewalls, and TCP/IP Covert Channels. Imad Jawhar is an assistant professor at the College of Information Technology at United Arab Emirates University. He has a BS and an MS in electrical engineering from the University of North Carolina at Charlotte, an MS in computer science, and a Ph.D. in computer engineering from Florida Atlantic University. He has published many papers in international journals, conference proceedings and book chapters. His research interests are in the areas of wireless networks and mobile computing, sensor networks, routing protocols, distributed systems, multimedia, and software design. He served on numerous international conference committees. Imad Jawhar worked at Motorola as engineering task leader involved in the design and development of IBM PC based software used to program the world's leading portable radios, and cutting edge communication products and systems. He was also the president and owner of Atlantic Computer Training and Consulting, which is a company based on South Florida, that conducted numerous classes in the latest computer system applications. Its customers included small and large corporations such as GE, Federal Express and International Paper. Imad Jawhar is a member of the IEEE, ACM, and ACS organizations.

Trabelsi and Jawhar