I agree that any third party software/hardware cannot defeat or detect all covert channels on a network it is nearly impossible since you can use any established protocol and rely on the kind, frequency, timing and order of messages rather on the content of messages itself. For example a CC could be developed so that it uses an FTP server and FTP connections, and the CC message grammar could be a simple yes or no based on the time I connect to the server from some IP, or the directory or file I intend to transfer from the server, or the order I use to browse directory and the list endless (and I bet any CC detection tool will have a hard time figuring out if a CC is in place. Now, there are analogies with other security tools such as Intrusion Detection Systems and Antivirus programs; all these kind of tools work based on patterns (no matter if the pattern consist of statistical deviations from a "predefined" activity profile or a sequence of bytes commonly called signatures). Most problems associated with the evasion of this security measures (IDS evasion techniques, polymorphic viruses, etcetera) rely on the fact that these tools are in some sense external to the resources they want to protect. Take for example a network intrusion detection system. Most of these tools these days try to emulate the way that protected resources handle TCP/IP packets because a Solaris won't react the same way as a Linux or Windows system to certain packet manipulations (I recall here the excellent document ICMP Usage in Scanning by Ofir Arkin). So, this is where I think that development of most security tools (including CC detection tools) will try to focus on the next years: correct emulation and interpretation of legitimate traffic. And to do this, my opinion is that developers will use: a) Focus on known behavior rather than unknown behavior: it is easier, faster and more reliable if correctly implemented; we already use this principle in our firewalls by denying all connections that are not explicitly permitted or, don't we? (And yes... there are some drawbacks to: flexibility is reduced) b) Integrate as much as possible with the resources that we try to protect; HIDS systems already try to integrate as much as possible with OS and some applications. Also, you see more and more NIDS-HIDS integration to help each other sensor understand what it is analyzing. Still, I doubt we'll see a CC detection tool able to integrate directly into all our server's applications and with the firewall and IDS to identify non legitimate traffic. c) Integrate cryptographic protocols to prevent unauthorized use of legitimate traffic; yes, this might help a lot, still it could be extremely painful to users to ask them to authenticate each time they want to connect to the outside with restricted protocols. VPNs might be extended to cover Firewall-application for this purpose. Even then, there will be techniques to bypass these controls and the user factor will be always there: how about an attacker that has compromised a router outside the company's collection of security tools that happens to forward all traffic to User's X favorite news web page and this attacker has also bribed User X so that all that he has to do is Access this news web page at a certain time for a "yes" and at another time for a "no".... good look catching that :-)... Omar Herrera -----Original Message----- From: Jose Nazario [mailto:joseat_private] Sent: Miércoles, 23 de Octubre de 2002 10:36 a.m. To: Frank Knobbe Cc: vuln-devat_private; pen-testat_private Subject: Re: Covert Channels On 22 Oct 2002, Frank Knobbe wrote: > does anyone think that attempting to solve the covert channel issue is > gonna be the next market boon in security? for the reasons clearly stated by several bright individuals on this topic previously, any product which claims to detect and defeat covert channels on a network (or even a multiuser system) is snake oil. ___________________________ jose nazario, ph.d. joseat_private http://www.monkey.org/~jose/
This archive was generated by hypermail 2b30 : Wed Oct 23 2002 - 12:33:10 PDT