Thanks for the insights, Mark. I was hoping you'd chime in. The covert channel thing has fascinated me since Defcon 9. My intent with the covert channel concept was simply to "communicate" with an outside entity in a method that would slip right by most modern monitoring utilities. When I think of covert channel, I think of someone who is in a very restricted environment (or country) that needs to get messages to the outside in a way that their opressors (or government) cannot (or do not) monitor the messages. Now that the group knows that we're not talking about using this covert channel to pipe a root shell back to an attacking machine, I have a couple of additional questions. Do you think you could obscure your messages even further by taking advantage of some of fragroute's capabilities with tcp's fragment reassembly functions to hide the message even better? Or would the original header be preserved within the fragments? Also, you make mention of packet synchronization, packet validation, etc. In a very simple setup, where the messenger sends information in a one way fashion (kind of like a "drop location" for images using steganography) the state of the session or packet validation don't appear to be a problem, because there is only one channel to listen for and only one operator to pick it up. If you had multiple messengers communicating with a single operator, or you needed bidirectional communication, it may prove to be more important. Just some thoughts. Thanks again. -Jeremy -----Original Message----- From: Mark Grimes [mailto:markat_private] Sent: Wednesday, October 16, 2002 6:16 PM To: vuln-devat_private Cc: kamat_private; Jeremy Junginger Subject: Re: Covert Channels >Many people have discussed this concept, but nothing has ever taken >form. Covert channels aren't so covert if everyone knows what to look for because it's published wide and far. Libraries work better here where you have so many options for channel types and fields to spin on that there are too many possibilities to identify any particular channel type without a state machine analyzing all permutations. It's even better, but far more difficult to make things more dynamic here (multiple major/minor protocol types TCP ACK, ICMP Reply, UDP...) However that is largely conceptual at this point because there are too many factors; packet syncronization, packet validation (how do we know it's a part of the same channel), router filtering, etc. Needless to say, covert channels ARE in use out there whether you believe they are or not... and they do work for what they are intended to be used for (which is not the use described in your message) Likewise, the less ppl know about specifics, the better they work, since things like signature based IDS are retroactive technologies -- if you can't signature it, it must not exist. :) >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. Covert channels have everything to do with both host and network exploitation, but if your defination of exploitation is "getting root", then I suppose they are not so useful. The purpose of covert channels is to evade monitoring capabilities. In modern tongue in terms of network channels this resembles anomalous and signature based IDS, but it could also involve someone with a clue that knows how to use a sniffer properly. However most public forms of backdoors work fine on existing networks as long as their isn't a host or network based signature for it. Unless you hire a bunch of grunts to sit around and analyze sniffer dumps all day, LOTS of stuff goes under the radar screen... You simply can't monitor everything, everywhere in real-time, so long as that's a fact, covert channels have a use. >In order to get a host machine to pull this out of the packet and USE >it, you'd have to re-write the IP stack for that machine. If you can >replace an IP stack on a machine, there's no good reason to be doing it >in the first place, as you've already got root (or some form of >escalated privs). With a userland daemon on the compromised host, there are plenty of packet types that can be injected toward the victim that the kernel will not interfere with. If you don't want to re-write the IP stack, then quite simply don't send packets to the victim that the kernel will intefere with. >In order for this concept to be effective against a single host (in the >case of attempting to run a remote exploit against a host), you'd have >to have a box in the middle with a modified stack to intercept, decode, >and not throw away these extra bits of data. Then again, if you can >insert a new BOX on a network, you probably aren't worried about using >such a complicated method of compromising a host. I had to re-read the original message, but I simply can't understand why your focus is on machine exploitation -- The original poster didn't mention covert channels for the use of compromising a host at all. It is simply NOT what covert channels are useful for. Covert channels ARE useful for moving data around in a form that is not directly addressible by modern day monitoring capabilities. >In a network sense- it's almost even more pointless. A router isn't >going to understand whatever hidden commands you've got in any field >(IP option, ID, generally unused portions of the TCP header, etc) so >they will throw it out. Huh? A router will filter whatever is in the access lists. If you send a LEGAL packet but still are capable of using the header and/or payload for obfuscated transmission, and it's not a packet the router will filter, the router will do it's job -- route packets. I don't know routers that make decisions based on reserved/MBZ bits for example. However MOST channels use valid packet headers and have their own protocol header made up of the initial bytes of a layer-2/3/4 TCP/IP packet payload (depending on what your channel rides on). >All in all, a kinda cool concept, but completly pointless. As you have described the use of covert channels, I would agree with you -- completely pointless. But then again this is the vuln-dev list, so you're on topic, it's just I wouldn't far and wide call covert channels pointless -- they are in use, and for what they are good for -- they work VERY well. I take great interest in this area only because I KNOW they work, otherwise I wouldn't waste my time. -- Mark Grimes <markat_private> Stateful Labs
This archive was generated by hypermail 2b30 : Thu Oct 17 2002 - 07:25:57 PDT