Re: Covert Channels

From: Mark Grimes (markat_private)
Date: Wed Oct 16 2002 - 18:16:21 PDT

  • Next message: Alex Tibbles: "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 - 06:24:32 PDT