[Dshield] Communication when emails are being watched
cbrenton at chrisbrenton.org
Wed Dec 24 22:01:07 GMT 2003
On Wed, 2003-12-24 at 15:04, Johannes B. Ullrich wrote:
> One of the classic covert channel tools is 'loki'. Its quite old
> (1995/96?) and there should be an old phrack article around with
Agreed. Loki rocks, so long as you are not trying to protect a network
from it. ;-)
BTW Johannes, it was written in 1996. Your showing your age again. ;-)
> Signature based IDS's (like snort) usually don't do too well in
> detecting new covert channels.
This flows right into a question someone asked earlier today which was
"How hard would it be to write a Snort sig for this?" The answer is
"pretty damn hard if not impossible".
Client --> Server Loki sends echo-requests. Server--> Client you get
echo-replies. So the typical firewall is going to tell you that someone
pinged your host and nothing more.
So maybe your thinking "But wait Chris, all I have to do is check
echo-request packets and look for an ICMP ID of 666 and I can catch Loki
no problem". That's only true if the purp compiles the client and server
will all the default options. A smart purp (i.e. the one you should be
most worried about) is going to change this value to something else.
Weeeeee! Their covert channel now just blows right though.
So now maybe your thinking "Well I'll just look for text in the payload
and detect on that". Unfortunately, Loki2 supports encryption. So even
if I use this channel to transmit something as obvious as 'cat
/etc/passwd', you are not going to see it.
There are only 2 intrusion detection systems on the market today that I
am aware of that will accurately flag all Loki & Loki2 traffic. They are
NFR and Dragon IDS. This is because both of these IDS are stateful and
allow you to create a rule that compares the payload of the echo-request
to the payload of the echo-reply. If they don't match, you have a
Of course the easiest way to deal with Loki is to simply deny all
inbound echo-request packets. This will prevent Loki from being usable
as an inbound covert communication channel. People can still use it
_outbound_ from your network; but hey, what about your needs? ;-)
Unfortunately, there are other tools that use only echo-replies as the
covert channel. These are harder to block as your options are:
1) Block all inbound echo-replies
2) Only let in echo-replies when an outbound echo-request goes by
If your thinking "Hey I'm safe because I run a stateful inspection
firewall so I'm sure it only lets in legitimate echo-replies", grab a
packet crafting tool and _test_ it. My experience has been that *many*
SI firewalls let them blow right on through.
> The best deffence against a covert
> channel is to know what your network traffic is supposed to look
> like, so you will recognize an excess of ICMP (or other traffic).
Amen brother. There is not a single security tool on the market today
that can replace active brain matter. ;-)
Happy holidays all!
More information about the list