[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TCP/IP Stego (was CU-SeeMe)
Okay, i'm going to try to address things systematically, here goes..
(excuse non standard quoteing)
_______________________
>From [email protected] Mar 9 00:54:38 1996
>Fine idea to create a subliminal channel using packet parity on an
>ftp connection but this is not a peer connection , so can't be used
>to do subliminal chat (for example) but could be used to do
>subliminal mail delivery .
------------------------
Since the data is steg'd into the tcp header and not the data you are
sending (openly) it doesnt make much difference what client is generating
the packets. Could be a web server. Could be a Y/Ntalk client, a sendmail
daemon, or a telnet. The greatest restriction being that you only get
about 1k per 500k .. which is a bit cumbersome in most cases. More on
that later.
------------------------
>From [email protected] Mar 9 00:54:43 1996
Subject: Re: TCP/IP Stego (was CU-SeeMe)
>This is a bad idea, because in addition to the extra processor overhead, it
>is an incredible waste of bandwidth. For a 512 byte packet, you are only
>getting .02% efficiency, because you wouldn't be able to use the actual data
>in the packet; otherwise someone would probably notice the increased error
>rate if you dink around with the checksum.
No need to do anything strange to the checksum. In the normal process of
framing packets data is buffered, and packets are 'padded' to make a full
packet. The hacked tcp protocol would simply be a bit more selective
about where and when padding was added. The checksum would still be a
valid checksum for that packet - we would simply select a packet that gave
a correct checksum value. The overhead for this is more than with
standard tcp but could hardly be considered a serious drain of cpu cycles.
As for wasted bandwidth: That could be seen as a problem, but there are a
few things to offset the overhead, the big one being that it doesnt make
any difference what form the carrier data takes.. if you can generate
half a meg of ANYTHING that can be plausibly sent to another machine,
then you can send your 1k of data. If implemented properly the carrier
data wouldnt even need to all come in through the same route. This
scenario leaves any one who may be watching with quite a haystack, and a
very small needle to find.
>This does not provide adequate plausible deniability. Stegoing a 16 bit
I disagree. Consider: the packet, taken bit by bit, or as a whole,
would be completely valid - with nothing added, or taken away except
perhaps the few octets that would need to be dropped to acheive the right
parity. This would actually be very few, since you have a
50% chance that the parity will be correct to begin with.
---------------------
From: Jim McCoy <[email protected]>
Subject: Re: TCP/IP Stego (was CU-SeeMe)
>I think that the original poster meant twiddling some of the (relatively)
>unused fields of the header which most routers and applications do not
>care about, the type-of-service field or priority would good place to
>start.
I'm pretty certain that altering TOS would pretty well scrap the packet,
but im not positive. <shrug>. Sequence numbers are definitly out. However
i think that playing with the priority flag could definitly work. Also a
parity check of the 'window' field could be done quite easily. Only
problem i see is that 'priority' packets basically are only used for
special characters and the like, for example to send 'ctrl-c' to a
abort a running ftp. Having a large number of priority packets would be
reletivly noticable. The window field is a bit more promising - you'd
need to prove the arrival sequence and timing of each packet and ack in the
stream to prove that it had been tweaked.
>This would have no effect on the data in the packet, particularly
>if you fiddle at the IP level instead of TCP.
[tons of good things I hadnt even thought of snipped]
--------------------
From: Bill Frantz <[email protected]>
Subject: Re: TCP/IP Stego (was CU-SeeMe)
>If you can hack your TCP implementation, you should be able (with a high
>probability) stego information in a few bits of the TCP checksum by
>adjusting the packet boundries of the TCP stream. An error correcting code
>protocol would cover the cases where you couldn't get that *%$# bit set
>correctly. Please note that this technique would not result in TCP
>checksum errors.
Thank you! This is what I was attempting (apparantly quite poorly) to say
in the original post.
:)
Benji