On Fri, 18 Oct 2002, David Litchfield wrote:
> Whilst this works on a binary level /docone = 0 and /doctwo = 1 enabling you
> to channel bits it's quite network intensive.
Yes, if you are about to transfer a 50 kB file, but not for basic backdoor
signalling.
> Further, by looking at the log files one could get an idea that
> *something* is wrong.
Hardly... The code can behave to look pretty much like an average browser
user, just the selection of visited documents would be specific for the
message encoded. Besides, an average visit on a webpage (say, *blink*
lcamtuf.coredump.cx *blink*) generates something around 20-30 GET requests
for all images and such. The order is pretty arbitrary - depends on what
browsers you use, what is already cached, which SYN leaves the local TCP
stack first and which handshake is first completed, etc. The order of
those requests can be altered to fit quite a few bits of data, most likely
without being detected - there's no reliable way to do it. Quite a few
ordinary users visit a page they find interesting several times a day, and
visit more than the frontpage. This is more than enough to send back
sniffer passwords, for example.
But defending this particular technique is not the point - point is, as
long as I can get any traffic off the network you're trying to defend -
which is a real-world scenario - I can send a message to the world, as
long as I previously agreed on a specific covert channel protocol with my
party. There's nothing you can do about it. There are ways to mitigate the
risk by making it more difficult (since the attacker would have to get
close to "normal" traffic characteristics - and how difficult that is
depends on how good your model would be), and ways to defend against known
code, but protocol analysis is no silver bullet against covert channels =)
--
------------------------- bash$ :(){ :|:&};: --
Michal Zalewski * [http://lcamtuf.coredump.cx]
Did you know that clones never use mirrors?
--------------------------- 2002-10-18 11:25 --
This archive was generated by hypermail 2b30 : Fri Oct 18 2002 - 09:05:38 PDT