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 --
This archive was generated by hypermail 2b30 : Wed Oct 23 2002 - 12:27:13 PDT