All, Using covert channels with the ICMP protocol can be defeated if you know what to expect and how your traffic needs to look like. Unfortunately as it seems people tend to forget that they need to look under the hood for profiling the traffic on their network. Without the minimum understanding on how your traffic looks like everything looks weird :P For example, there is no reason not to have a payload with ICMP Echo requests, having an encrypted payload with ICMP traffic, unsolicited ICMP query replies, information in the reserve fields, weird flag combinations, etc. If perimeter filtering devices would have been looking for non-legit IPv4 traffic some packets would not even register with the network they target. It would not solve the entire problem but at least deal with something. The other problem is IDSs which cannot (please correct me if I am wrong) discover and alert for illegitimate IPv4 traffic and abnormalities with network traffic. All and all you cannot defeat covert channels because there are so many ways to implement them which the current technology simply lag behind. Put it in a legitimate traffic which is allowed to and from your network and you are good to go (assuming you have some kind of a parser on the targeted network). Yours, Ofir Arkin [ofir@sys-security.com] Founder The Sys-Security Group http://www.sys-security.com PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA -----Original Message----- From: Valdis.Kletnieksat_private [mailto:Valdis.Kletnieksat_private] Sent: Thursday, October 17, 2002 6:17 AM To: kam Cc: Jeremy Junginger; vuln-devat_private; pen-testat_private Subject: Re: Covert Channels On Wed, 16 Oct 2002 16:14:16 PDT, kam said: > The problem with your idea is that it will never work for the actual > exploitation of a system or network. If you plan on using this medium as a > communication channel, that's one thing, but you will never get a host > machine to respond to options in these fields. It's not *intended* to be used as an exploit - by definition, a "covert channel" is a communications path used to transmit data without being noticed. The "classic" covert channel is *two* cooperating processes at *different* security levels that are not permitted to communicate directly because they *are* at different levels. You would then be able to "tunnel" Top Secret information out to the non-Secret process by (for example) alternately filling a shared disk and releasing it, or causing the system paging rate to go up and down, or creating/deleting a pre-arranged filename, to send a message by Morse code or whatever. The non-TS process then uses 'df' or 'uptime' or 'ls' or whatever to watch the freespace/paging rate/files to receive the message. I remember a number of years ago a telnet-over-DNS covert channel, where the "inside" process would issue strange DNS requests to send data out, and a subverted DNS server on the "outside" would send the inbound data in the replies... And just recently, there was a program to tunnel things over ICMP (remember, many ICMP carry an IP packet header so that space can be used for data storage). You could use things like the TCP ISN value to leak close to 4 bytes of information per 3-packet handshake without your firewall ever twigging to what's being tunneled right under its nose - I haven't seen actual code for this one. You can get yourself another 4 bytes per ACK if you use the sequence number field to send data rather than actually ACK packets - I'll bet that most firewalls don't keep *THAT* much state to detect that an ACK is out-of-bounds. If you're sufficiently desperate, there's the ICMP Timestamp Request/Reply, lots of places to hide stuff in IP option headers, etc etc etc... Even as early as the DOD Orange Book, it was recognized that it's impossible to eliminate covert channels on a shared-access computer system/network, and as a result, the requirements are of the form "designed to limit maximum bandwidth of the covert channel to N bits/second" (where N was on the order of 150 bits/sec) - this in a day when 1200 baud modems were considered fairly fast.... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
This archive was generated by hypermail 2b30 : Fri Oct 18 2002 - 06:30:32 PDT