RE: Covert Channels

["Jeremy Junginger" <jjunginger () usbestcrm com>]

Thanks for the insights, Mark.  I was hoping you'd chime in.  The covert
channel thing has fascinated me since Defcon 9.  My intent with the
covert channel concept was simply to "communicate" with an outside
entity in a method that would slip right by most modern monitoring
utilities.  When I think of covert channel, I think of someone who is in
a very restricted environment (or country) that needs to get messages to
the outside in a way that their opressors (or government) cannot (or do
not) monitor the messages.  Now that the group knows that we're not
talking about using this covert channel to pipe a root shell back to an
attacking machine, I have a couple of additional questions.  Do you
think you could obscure your messages even further by taking advantage
of some of fragroute's capabilities with tcp's fragment reassembly
functions to hide the message even better?  Or would the original header
be preserved within the fragments?  Also, you make mention of packet
synchronization, packet validation, etc.  In a very simple setup, where
the messenger sends information in a one way fashion (kind of like a
"drop location" for images using steganography) the state of the session
or packet validation don't appear to be a problem, because there is only
one channel to listen for and only one operator to pick it up.  If you
had multiple messengers communicating with a single operator, or you
needed bidirectional communication, it may prove to be more important.
Just some thoughts.  Thanks again.

-Jeremy

-----Original Message-----
From: Mark Grimes [mailto:mark () stateful net] 
Sent: Wednesday, October 16, 2002 6:16 PM
To: vuln-dev () securityfocus com
Cc: kam () aversion net; Jeremy Junginger
Subject: Re: Covert Channels



> Many people have discussed this concept, but nothing has ever taken 
> form.

Covert channels aren't so covert if everyone knows what to look for
because it's published wide and far.  Libraries work better here where
you have so many options for channel types and fields to spin on that
there are too many possibilities to identify any particular channel type
without a state machine analyzing all permutations.  It's even better,
but far more difficult to make things more dynamic here (multiple
major/minor protocol types TCP ACK, ICMP Reply, UDP...)  However that is
largely conceptual at this point because there are too many factors;
packet syncronization, packet validation (how do we know it's a part of
the same channel), router filtering, etc.

Needless to say, covert channels ARE in use out there whether you
believe they are or not... and they do work for what they are intended
to be used for (which is not the use described in your message)
Likewise, the less ppl know about specifics, the better they work, since
things like signature based IDS are retroactive technologies -- if you
can't signature it, it must not exist. :)

> The problem with your idea is that it will never work for the actual 
> exploitation of a system or network. If you plan on using this medium 
> as a communication channel, that's one thing, but you will never get a 
> host machine to respond to options in these fields.

Covert channels have everything to do with both host and network
exploitation, but if your defination of exploitation is "getting root",
then I suppose they are not so useful.  The purpose of covert channels
is to evade monitoring capabilities.  In modern tongue in terms of
network channels this resembles anomalous and signature based IDS, but
it could also involve someone with a clue that knows how to use a
sniffer properly.  However most public forms of backdoors work fine on
existing networks as long as their isn't a host or network based
signature for it.  Unless you hire a bunch of grunts to sit around and
analyze sniffer dumps all day, LOTS of stuff goes under the radar
screen... You simply can't monitor everything, everywhere in real-time,
so long as that's a fact, covert channels have a use.

> In order to get a host machine to pull this out of the packet and USE 
> it, you'd have to re-write the IP stack for that machine. If you can 
> replace an IP stack on a machine, there's no good reason to be doing it

> in the first place, as you've already got root (or some form of 
> escalated privs).

With a userland daemon on the compromised host, there are plenty of
packet types that can be injected toward the victim that the kernel will
not interfere with.  If you don't want to re-write the IP stack, then
quite simply don't send packets to the victim that the kernel will
intefere with.

> In order for this concept to be effective against a single host (in the

> case of attempting to run a remote exploit against a host), you'd have 
> to have a box in the middle with a modified stack to intercept, decode,

> and not throw away these extra bits of data. Then again, if you can 
> insert a new BOX on a network, you probably aren't worried about using 
> such a complicated method of compromising a host.

I had to re-read the original message, but I simply can't understand why
your focus is on machine exploitation -- The original poster didn't
mention covert channels for the use of compromising a host at all.  It
is simply NOT what covert channels are useful for.  Covert channels ARE
useful for moving data around in a form that is not directly addressible
by modern day monitoring capabilities.

> In a network sense- it's almost even more pointless. A router isn't 
> going to understand whatever hidden commands you've got in any field 
> (IP option, ID, generally unused portions of the TCP header, etc) so 
> they will throw it out.

Huh?  A router will filter whatever is in the access lists.  If you send
a LEGAL packet but still are capable of using the header and/or payload
for obfuscated transmission, and it's not a packet the router will
filter, the router will do it's job -- route packets.  I don't know
routers that make decisions based on reserved/MBZ bits for example.
However MOST channels use valid packet headers and have their own
protocol header made up of the initial bytes of a layer-2/3/4 TCP/IP
packet payload (depending on what your channel rides on).

> All in all, a kinda cool concept, but completly pointless.

As you have described the use of covert channels, I would agree with you
-- completely pointless.  But then again this is the vuln-dev list, so
you're on topic, it's just I wouldn't far and wide call covert channels
pointless -- they are in use, and for what they are good for -- they
work VERY well. I take great interest in this area only because I KNOW
they work, otherwise I wouldn't waste my time.

--
Mark Grimes <mark () stateful net>
Stateful Labs

Attachment: smime.p7s
Description: