Protocol Hopping Covert Channels


		  An Idea and the Implementation
		  of a Protocol switching covert
			    channel



		      (C) Steffen Wendzel
		      cdp_xe (at) gmx.net

The current version of this paper is always available at www.wendzel.de.

ver. 1.5 (nov-08-2008): * Some tiny improvements including URL fixes
			  since I moved some files to wendzel.de.
			* Cut out non-useful comments.
ver. 1.4 (aug-14-2008): * I found out that the 1997 implementation of
			  the LOKI2 code already implemented a very
			  basic protocol hopping covert channel. Even
			  if the author did not describe the protocol
			  hopping (he called it protocol swapping), he
			  is the artificer of PHCC. A comment was
			  added in this paper to make that clear and
			  the published text is now referenced within
			  this paper.
			* I also added a comment about the side issue
			  of packet ordering. Previous work was done
			  here too [4].
ver. 1.3 (apr-28-2008): * IDS detection comment added
			* typo fix
			* Richard Bejtlich pointed out an FTP protocol
			  implementation error in phcct (added comment)
ver. 1.2 (mar-21-2008): * typo fixes
			* added comment (size of reliability protocol
			  header)
ver. 1.1 (jan-27-2008): * typo fix
ver. 1.0 (nov-11-2007): * first release

Abstract
--------

This paper describes a relative new way of a covert channels design. This is
done by changing the protocol of the tunnel while the tunnel exists and
even change the protocol on a randomized way without restarting the
tunnel or reconnecting to the tunnel. A simple proof of concept tool
called 'phcct' (protocol hopping covert channel tool) is available on my
website http://www.wendzel.de. phcct implements only one (the easiest)
version of such a randomized protocol hopping covert channel.
Such protocol hopping was known -- in a very basic form -- since 1997
(described in [3]).

This paper will also describe why this specially makes forensic
analysis more difficult.

Protocol Hopping Covert Channels
--------------------------------

A PHCC is a covert channel that is able to switch between a given
number of protocols to transfer data trough. The protocols can be pre-
defined in a given order or even choosed by randomization code.

The reason for the implementation of such tools is the chance to
decrease the possibility of detection of such a channel by a NIDS.

Previous Work (This was added in version 1.4)
---------------------------------------------

The result of my research about previous work is that 'daemon9' seems
to be the first (and only) person who invented such protocol hopping
covert channels before. His 'beta' feature called 'protocol swapping'
can be found in [3]. His proof of concept code is able to switch a
protocol on users command (it supports UDP and ICMP). The user has to
send a special '/swap' command trough the channel to make the change
possible.

Here are two very interesting lines of LOKI2 code:

#define SWAP_T      "/swapt"        /* Swap protocols               */
...
prot = (prot == IPPROTO_UDP) ? IPPROTO_ICMP : IPPROTO_UDP;

Poorly the author did not wrote anything about his swapping feature
besides the fact that it only runs under Linux and that it is a beta
quality feature.

This paper shows more advanced ways to do protocol hopping and
discusses its difficulties and advantages.

Choosing Protocols
------------------

It would be a bad idea to choose always the same protocols to use in
such a PHCC. To keep a PHCC stealthy it needs a knowledge of the
protocols used within a network. For example, if an attacker wants to
create a PHCC between a PC workstation client and a companys web proxy
server that also is configured as a caching server for DNS, it would be
a good choice to use DNS & HTTP(S) for such a tunnel. This of course
could need an additonal catching-layer in the kernel or a modification
of the used webserver/nameserver software.

Another way is to choose protocols _not_ used within a network. For
example: tunneling data trough CDP while there is no system that
uses CDP. One could also use unused routing protocols or unused IGMP
in a network to tunnel the data trough.

One characteristic of protocol hopping covert channels is that even if
_one_ of the protocols an attacker is making use of is recorded, the
monitoring system will not collect ALL packets of ALL protocols in a
network. This simply is a too huge amount of data. And last but not
least, it makes the forensic analysis of network traffic much harder
if there are multiple protocols used for a covert channel.

Routing
-------

There are at least two ways to implement routing functionality within a
PHCC:

	1. The simple use of routable protocols without faked source or
	   destination information in their headers.
	2. A peer-to-peer PHCC. This would make it possibly to use
	   protocols like CDP too.

Reliability
-----------

If one uses multiple protocols to tunnel trough and if there are
multiple routes the data can be sent trough, one needs to implement
reliability in a PHCC.

This can be done by a micro reliability protocol that fits into all
used protocols. Note that it even must fit into the protocol with the
smallest available space used within the PHCC! In other words:

M = Maximum size of the reliability protocol
An = Maximum Space for a reliability protocol within Protocol [n]

	M = Min (A1, A2, A3, ..., AN)

Implementing reliability increases the needed work on the implementa-
tion of a PHCC. A good way to do this is shown by the TCP protocol. I
also implemented reliability for ICMP in the 'very strange tunneling
tool' in 2006. One can find it on my website too.

The PoC tool 'phcct' only uses a message ID to sort all the messages.
Other reliability information is not needed since it only supports TCP
what already implements reliability.
The message ID is needed to sort the received messages in a list to
output them in the correct order.

But if reliability is needed there are again different ways for an
implementation. Here are two I can imagine:

	1. Host A sends packet via protocol X, Host B acknowledges it
	   using the same protocol and setting some flags in the micro
	   reliability protocol header.

	2. Like A but Host B acknowleges the received data with another
	   protocol.

Sending Order
-------------

Let me discuss another special point why PHCC can make forensic anylsis
more difficult.

It would make a channel harder to detect if the PHCC would mix the
order of packets to send and sorting the received packets at the other
PHCC end-point. This was previously described in [4].

For example the client sends this input:

	Pkt1, Pkt2, Pkt3, Pkt4, Pkt5, Pkt6

The first PHCC end-point then maybe would receive Pkt1 and Pkt2 at the
first time (via recv() from a socket or maybe read() from a FIFO or so)
and then Pkt3 to Pkt6 and would mix it with some randomized functions.
The host then could transfer the pkts in such an order:

	Pkt2, Pkt1, Pkt4, Pkt3, Pkt5, Pkt6

The other PHCC end-point would receive these packets in the order sent
but could extract the ID information from their secret headers what
makes it possibly to sort all received pakets and re-produce their
original order.

If one doesn't know the ways a PHCC uses to store the message ID informa-
tion in these different protocols (with a mixed order) his capturing
tool receives, he will get into trouble if he wants to re-assemble such
pkts.

Additional encryption would make such a PHCC very hard to detect!

phcct
-----

The PoC implementation 'phcct' only supports 3 different TCP protocols
(HTTP, FTP-DATA and its own plaintext protocol) without any encryption
to show how such a PHCC can be realized.

Both tunnel endpoints accept local TCP connections on port 9999 and
send their data in a randomized protocol order but in a static packet
order trough these 3 implemented protocols. Encryption is currently not
supported but could be easily added (for example by XORing the payload
with its message ID to have a very first basic encryption).

Example: To create a telnet chat connection via a PHCC it would only
need these steps:

HostA, Terminal1# ./phcct -a IP-Of-Host-B
HostB, Terminal1# ./phcct -a IP-Of-Host-A

After both services started, press return on both terminals to give the
the tools the command to connect to each other.

After the connection is established one can connect to the port 9999
(local and remote) to receive and send data.

HostA, Terminal2# telnet localhost 9999
HostB, Terminal2# telnet localhost 9999

Where HostB receives data from HostA and HostA receives data from HostB.

This was added in version 1.3:
Note: Richard Bejtlich pointed out in his weblog that >>The FTP data
traffic isn't simulated properly because the SYN segments go to port 20
TCP.<< This is true and I am sorry but I currently don't have the time
to fix that (and of course, it is not too important for this demon-
stration) since I am busy working on another research project.

Passive PHCC?
-------------

Do passive PHCC make sense? PCC presented by Joanna Rutkowska [1]
already are very hidden placed in the Linux kernel by using TCP ISN
modification. Interesting information about that can also be found in
[2].

Future work could be the creation of a passive protocol hopping covert
channel implementation (PPHCC).

Detecting PHCC within IDS (added in v. 1.3 of this paper)
---------------------------------------------------------

There are different ways to detect covert channels using intrusion de-
tection systems. But how to specially detect protocol hopping covert
channels? If the PHCC is not encrypted and is making use of a micro
protocol (what is very likely), there should be some kind of paket ID
in every header. If one can find the part of a paket that increments
(or decrements) from paket to paket or that changes from 2 to 8 and
then to 20 or so, then it _could_ be the micro protocol internal mes-
sage ID.

But one should keep in mind that it is possibly to hide the ID much
better than just incrementing it by one: One could decrement it.

All these methods make it harder to detect PHCC micro protocols.

But of course: One of the best ways should be to increment the whole
PHCC including its micro protocol header.

I think a detection mechanism of PHCC using encryption and a smart
message ID changing in its micro protocol header will be very hard
to implement.

Future Work
-----------

- kernel space implementation, no listen() sockets and such things,
  hide it better
- implement cryptography
- mixing packet order

Links
-----

[1] Joanna Rutkowska: The Implementation of Passive Covert Channels in
    the Linux Kernel: www.invisiblethings.org/papers/passive-covert-\
    channels-linux.pdf, December 2004.

[2] Steven J. Murdoch and Stephen Lewis: Embedding Covert Channels into
    TCP/IP: http://www.cl.cam.ac.uk/users/sjm217/papers/ih05coverttcp.\
    pdf

[3] daemon9: LOKI2 (the implementation), Phrack Magazine Volume 7,
    Issue 51 September 01, 1997, article 06 of 17 (can be found here:
    http://gray-world.net/papers/projectloki2.txt, last checked on
    Aug-18-2008).

[4] K. Ahsan, D. Kundur: Practical Data Hiding in TCP/IP, 2002.