On 5/25/07, Joff Thyer <jsthyer@gmail.com> wrote:
My question surrounds detection; given that IDS tends to be payload
focused, if a covert channel exists that has encrypted data in a
packet header, how do we go about detecting it?
My first response is why? The internet is peer to peer and that makes
it obvious who is communicating with who. Most would not consider it
sufficiently covert if the communicating hosts were apparent, even if
the secret part of the communications was not. Computers don't have
the kind of relationships that people do to create the types of
situations within which a covert channel could be very useful without
anonymity. If I am wrong, then I'd certainly appreciate being
educated.
I can also easily dream up several techniques for creating indirect
covert channels, where it is not apparent that the parties are
communicating with each other at all. Why have covert direct
communications if indirect would make it more difficult to detect?
My initial thought leans toward the fact that encrypted data blocks
are statistically flat over time. Given say 'snort', how can we use
this idea?
Let's suppose that this is a necessary pursuit for some reason beyond
my imagination.
Snort itself has not historically been a great tool for multi-packet
and certainly not multi-session analysis. This would be something that
a snort pre-processor would have to handle, as I assume you'd need
some sort of long term data store per communicating peers. If I recall
correctly, there are to be ways to perform the statistical analysis
without having to store all the data to be analyzed, but that probably
comes at a high calculation cost.
Now, what to analyze? This becomes very difficult even if I have a
very good idea of what normal should be for the operating systems
generating the headers. There is likely sufficient randomness in "best
practice" header field generation for flatness to be present already.
This would make it difficult to determine where something was
encrypted well, or just appropriately random. For instance, sequence
numbers should increment randomly within a defined range. Suppose that
the increment is the covert channel?
Even if this is detectable, say from poor randomness of the host OS,
this quickly becomes an escalating effort where the attacker will
always have the upper hand if the means of detection is public. For
whatever the analysis capability put in, the attacker can simply
adjust to evade detection. Only change every other packet, or packets
with other data, or combine bits from other places in the header.
It seems to me that there are too many ways of either avoiding direct
communications or in hiding in existing randomness in the packet
header to make this a worthwhile pursuit. As always, I'd be happy to
learn otherwise.
I would be happy to summarize opinions.
That's nice to offer, but there doesn't seem to be a heated exchange
going on. Perhaps flames would have been better. ;)
--
Eric Hacker, CISSP
aptronym (AP-troh-NIM) noun
A name that is especially suited to the profession of its owner
I _can_ leave well enough alone, but my criteria for well enough is
pretty darn high.
------------------------------------------------------------------------
Test Your IDS
Is your IDS deployed correctly?
Find out quickly and easily by testing it
with real-world attacks from CORE IMPACT.
Go to http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw
to learn more.
------------------------------------------------------------------------
