RE: Covert Channels

["Dom De Vitto" <dom () DeVitto com>]

That's so not true, nc being the first to mind. Why else use UDP for
a data channel is not to be covert?

I'd also suggest you check out cutting edge anti-ids techniques,
including using urgent data points and boundary anomalies to cause
IDSs to reform data streams differently to OS IP stacks.

In many institutions, like banks, all communications are restricted, 
and so the use of covert channels is almost mandatory for communicating
with compromised hosts. e.g. receiving commands as the result of HTTP
GET, POSTing results, and then receiving further commands in response.

Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto                                       Tel. 07855 805 271
http://www.devitto.com                         mailto:dom () devitto com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


-----Original Message-----
From: kam [mailto:kam () aversion net] 
Sent: Thursday, October 17, 2002 12:14 AM
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