Protocol Hopping Covert Channels


      An Idea and the Implementation
      of a Protocol switching covert
          channel



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

      Written in Sep/Oct/Nov 2007



ver. 0.4 (nov-11-2007)

Abstract
--------

This paper describes a new way to implement covert channels. 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) also known as
'takushi' (what is japanese for taxi) is available on my website
http://www.doomed-reality.org. phcct implements only one (the easiest)
version of such a randomized protocol hopping covert channel.

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

Protocol Hopping Cover 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.

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 a 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 your 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.

Do not forget the reason why doing this: It is to be stealth. Even
if _one_ of the protocols you are using 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 yes, it makes the forensic
analysis of network traffic much harder if there are multiple protocols
used for a covert channel.

Another important thing is that packets still look authentic. If you
use HTTP then you should not send your plaintext data trough port 80
without any modification. phcct uses a VERY simple (and of course not
the best) way to hide data in HTTP. It lets a GET request look like
using a cookie. The cookie includes the message ID and the payload of
this message.

Other protocols do also provide lots of ways to hide data. Me and other
people already wrote papers about hiding data within other protocols
(see google for details).

By choosing a protocol you have to take care about existing connections.
If for example your raw TCP packet includes the same values used for an
already established connection you could de-syncronize it. A wrong DNS
response to a client could also bring problems with it.

Routing
-------

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

  1. Simply only use routable protocols without faked src/dst
     information in their headers.
  2. Implement peer-to-peer PHCC. This would make it possibly to
     use protocols like CDP too.

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

If one usees 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!

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. You can find it on my website too.

The PoC tool 'phcct' only uses a msg ID to sort all the messages. Other
reliability information is not needed since it only supports TCP what
already implements reliability.
The msg 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 pkt via protocol X, Host B acknowledges the pkt
     using the same protocol and setting some flags in the micro
     reliability protocol header.

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

If one uses protocols without a checksum, the micro reliability proto-
col should also inclure some checksum information field in its header.

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

Lets 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.

For example the client sends this input:

  Pkt1, Pkt2, Pkt3, Pkt4, Pkt5, Pkt6

The 1st 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 msg 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.

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

... do they make sense? PCC presented by Joanna Rutkowska [1] already
are very hidden placed in the Linux kernel by using TCP ISN modifica-
tion. 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).

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