Re: Covert Channels

[Michal Zalewski <lcamtuf () dione ids pl>]

On Wed, 23 Oct 2002, Blue Boar wrote:

> No more than an IDS vendor.  An IDS does not stop, or even detect, all
> intrusions.  A covert channel detector would be the same thing (and
> would probably just be an IDS add-on.)  That is, it would detect known
> covert channel methods, might have some logic to detect some possible
> unknown attempts.  It would have frequent signature updates, etc... you
> know the drill.

The difference is pretty obvious. IDS is supposed to detect known
characteristics of _unacceptable_ traffic (signature detection), or
unexpected _deviations_ from acceptable patterns (anomaly detection).
That makes sense - break-in attempts are an anomaly; there are no cases
when a common, valid traffic can also be an attack attempt - no mail
system does "rm -rf /" when words "Good morning" are seen in a mail.

All low-level attacks (buffer overflows, etc) can be told from legitimate
traffic. There's no legitimate traffic that would look like a valid
session - or, if there is, the false positive ratio is marginal. We get
bounces because we used the words "i love you" in a mail from time to
time, but generally, it's not a concern, and is a result of poor QA, not
strategy problems.

Exploit author can do his best to fool most popular IDSes, and vendors can
easily update to cover this attack mechanism, fragmentation or obfuscation
scheme. No biggie. If the model of acceptable traffic is lacking, it has
to be refined, and in most cases, there's a way to do it without catching
too much of a valid traffic.

Covert channels are different. Covert channels are a _valid_, _expected_
traffic. The purpose of network protocols is to exchange some information
- content, signaling - that is not already known to both endpoints -
otherwise, there's no purpose in communicating. You can define the data
format very precisely, but you can't make ultimate assumptions about the
actual information bits, within the acceptable range, to be exchanged.
There always at least two possibile scenarios in order for the process of
communication to make any sense at all. I may connect to you now, I may
not; I may pick www.latestnews.cx, I may pick www.oddphotos.com; I may say
"GET /", I may say "GET /nicephoto.jpg"; you may say "200 OK", you may say
"404 Not found". If I use the protocol in an abnormal fashion - e.g. 1,000
rapid-fire requests - IDS may find it suspicious. But what if it looks
just like a regular user activity? How can you tell? How can you stop me
from mimicking regular user activity?

You can make assumptions like "this kind of transfer should occur only
from this hour to that hour, up to this rate per second, and this rate per
hour" - but there's still an amount of information that is being exchanged
and cannot be pre-determined. This traffic is non-anomalous! This is an
expected data exchange. There's a good amount of confusion, because most
of existing covert channel implementations are actually nowhere close to
using truly expected traffic, and can be easily told by manual examination
or even trivial rules, such as "raw binary data shouldn't be sent instead
of a HTTP request on port 80".

The IDS can make a number of assumptions on how the traffic should look
like, but it HAS to allow a certain amount of information to be exchanged.
And this is enough to implement a covert channel. You can filter SMTP very
precisely to make sure all mails look "normal", but it does not stop
people from hiding an information in the fact they sent a mail about
weather, as opposed to politics. Refining the model to define that an
average person writes his wife about weather on Mondays and Wednesdays,
and writes Jack about politics on Friday is destined to fail, as the
number of false positives will be overwhelming, and wouldn't get you any
closer to your goal, unless you can build an exact model of your employee.

Mathematically speaking, for anomaly detection, miss ratio can be
expressed as 1/model_precision, approaching 0 as the protocol model gets
more and more refined. For covert channel detection, it's
const+1/model_precision, never reaching 0 even when you have a perfect
model of the protocol, as a fixed minimum data throughput is necessary for
the protocol to make sense at all. This is not to say the channel would be
very practical for large file transfers and such - but most covert
channels are used for long-term, low-bandwith actions such as password
collection; if large amounts of data are the target, they can be captured
upon intrusion.

End of story... Attack (signature / anomaly) detection can be pretty
successful, and can get closer and closer as the formal model of
acceptable traffic / signature database is getting better and is updated.
Covert channel detection is doomed - as soon as IDS with this capability
become popular, black hats will implement covert channels that simply
cannot be told from a regular user browsing the net in a typical
environment. Not much to update at this point, not much to improve.

Note that I'm not trying to bash the concept of IDSes, and I'm not an
opponent of covert channel detection. I just don't agree with the
statement that the situation is similar to anomaly detection in terms of
effectivity or life cycle.

-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2002-10-23 13:58 --