[Snort-sigs] Suggestions for new attack response rules

Jason security at ...704...
Sat Dec 11 11:25:03 EST 2004


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;







More information about the Snort-sigs mailing list