-----Original Message-----
From: Jason [mailto:security@brvenik.com]
Sent: Saturday, December 11, 2004 2:24 PM
To: Joe Patterson
Cc: snort-sigs@lists.sourceforge.net
Subject: Re: [Snort-sigs] Suggestions for new attack response rules
Joe Patterson wrote:
Now that I've had a chace to play around with it a little more,
I can more
accurately point out a problem with tagging. The problem it
that it's also
trivially evaded, due to the limitations of the tagging
mechanism. I think
it *can* be fixed. Whether or not it *should* be fixed, and
the mechanisms
for doing so, I'm curious to know what others think.
The problem stems from the fact that you can only tag a session
by packets
or seconds. But how many packets/seconds do you tag? At first
blush, I'd
say maybe 3-4 packets, since that should contain the server's
response and
some context, or maybe just a second or two, since the servers should be
fairly fast. The problem is, I'd be wrong. Take, as an example, the
following exchange (c-> denotes a packet from the client to the
server, s-<
denotes a packet from the server to the client, text in {} is
meta-information):
c-> GET /scripts/cmd.exe?/c+dir HTTP/1.1\r\n {This triggers an alert}
s-< {ack,tagged packet #1}
c-> Host: www.victim.com\r\n
s-< {ack,tagged packet #2}
c-> User-Agent: Telnet\r\n
s-< {ack,tagged packet #3}
c-> Accept: text/html,text/plain\r\n
s-< {ack,tagged packet #4}
c-> Accept-Language: en-us,en\r\n
s-< {ack,tagged packet #5}
c-> Accept-Charset: ISO-8859-1,utf-8\r\n
s-< {ack,are we still tagging?}
c-> \r\n
s-< HTTP/1.1 404 Not Found{...}
If the client delays each of those packets by a few seconds,
the response
will only show up if you're tagging the session for a very long time.
Similarly, there's no need to break these packets on newline boundaries.
Each character could come in its own packet. You always could
tag more, but
if the attacker can figure out how long your tagging is, he can
adjust his
attack accordingly. And if you ever get a false positive on
the download of
something huge, you'll get a huge flood of tagged packets in your IDS.
There are three solutions that I can see:
1) modify the tagging mechanism so that it doesn't consider a
packet to be a
packet unless there's data past the tcp header.
2) extend the functionality of tagging to allow it to tag all
packets in a
session until a specified number of payload bytes have been seen.
3) put a reasonably intelligent proxy in front of your servers to groom
shenanigains like this, and run the IDS behind it.
Does anyone see any other possibilities, or reasons why my suggestions
really suck, etc.?
Flowbits would not help here either unless you wanted to alert on every
packet for the session and then you thresholded the rule. ( That is
plain ugly ) I think the undocumented bytes operator for tag should do
the trick in this case.
from tag.c
else if(!strncasecmp(arg, "bytes", 5))
{
metric |= TAG_METRIC_BYTES;
bytes = count;
}
so it should work something like this
tag:session,1600,bytes;
