RE: Covert Channels

["Jason Barbour" <jbarbo1 () gl umbc edu>]

I am probably way over my head. But isn't possible to use a packet
sniffer to pull the info out of the packet? The target would have a
modified packet sniffer that pulls whatever field out of the packet and
operates based on the packet. You will need root, and like you said, if
you can already packet sniff or replace the IP stack what's the use. One
idea I had, which is probably wrong, is that this convert channel could
be used for DDoS attacks.
If the packet's data is being filtered, but you can get the header
through with this covert channel you could issue commands to a worm,
daemon, etc. waiting on the target host. Another idea, maybe not dealing
with covert channels, but just the idea of hiding info in fields, what
if someone took over a firewall that blocked all packets on a specific
port. The attacker changes the firewall to check a special field for a
special bit pattern, if that bit pattern is there, it sends the packet
through. The firewall would appear normal, except for this backdoor.
Like I said, I am probably way over my head, I just had some ideas.

-- Jason 

> -----Original Message-----
> From: kam [mailto:kam () aversion net]
> Sent: Wednesday, October 16, 2002 7:14 PM
> To: Jeremy Junginger
> Cc: vuln-dev () securityfocus com; pen-test () securityfocus com
> Subject: Re: Covert Channels
>
> On Wed, Oct 16, 2002 at 03:08:49PM -0700, Jeremy Junginger said
sometin
> like...
> > Has anyone had success in creating a program that uses
IP/TCP/UDP/ICMP
> > header information to transmit encoded messages from one host to
> > another?  Shortly after reading
> > http://www.firstmonday.dk/issues/issue2_5/rowland/ I was very
tempted to
> > put together a proof-of-concept program to demonstrate the use of
covert
> > channels (and more imporantly, how they could slip right by the IDS)
> > with the tools I had on hand.  I ended up using nemesis (Thank you
Mr.
> > Grimes), tcpdump, and a little Perl script to kind of piece a tool
> > together that would transmit encoded (I use that term loosely) ASCII
> > data within the IP id field of the IP header.  It works okay until
you
> > go through a NAT device that decides to change the IPID :)
>
> Many people have discussed this concept, but nothing has ever taken
form.
> 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.
>
> The endpoint machine's IP stack is going to junk any data within those
> fields, as they are not pertinent to that particular machine
(especially
> if
> it's crap, ie, something not supposed to be in that field.)
>
> 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).
>
> 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.
>
> 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.
> Depending on when you do the actual insertion of your data into the
> packet,
> chances are at somepoint (if not on your machine, up the line)
someone's
> CRC
> is going to be off and you're going to lose the packet. Keep in mind
that
> not everyone runs the same network appliances, and all stacks (unless
> intentionally otherwise) act differently. Some will recalculate the
CRC
> with
> your data, some will toss your data and recalculate, and others still
will
> just toss your packet.
>
> All in all, a kinda cool concept, but completly pointless.
>
> kam