[Snort-sigs] Suggestions for new attack response rules

Joe Patterson jpatterson at ...2901...
Sat Dec 11 02:27:13 EST 2004


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.?

-Joe

> -----Original Message-----
> From: snort-sigs-admin at lists.sourceforge.net
> [mailto:snort-sigs-admin at lists.sourceforge.net]On Behalf Of Jason
> Sent: Tuesday, December 07, 2004 12:11 AM
> To: Joe Patterson
> Cc: Brian caswell; snort-sigs at lists.sourceforge.net
> Subject: Re: [Snort-sigs] Suggestions for new attack response rules
>
>
> Apologies for taking a while to respond. life...
>
> Joe Patterson wrote:
> >>-----Original Message-----
> >>From: Brian caswell [mailto:bmc at ...95...]
> >>Sent: Saturday, December 04, 2004 2:54 PM
> >
> > ...
> >
> >>Not only will you get a ton of false negatives, you can get a ton of
> >
> >
> > This seems like an odd justification to me.  True, the
> inclusion of the rule
> > will not guarantee a lack of false negatives.  Some percentage
> of successful
> > attacks will not generate alerts.  The converse of this,
> however is the fact
> > that not having the rule will be guaranteed to generate 100%
> false negatives
> > (of this rule).
>
> which is ultimately a false sense of security. It becomes far too easy
> to discount an alert because you do not see a corresponding "validator"
> alert. In a custom unpublished ruleset this has some validity because
> the attacker has no way of knowing you are using this system. In a
> published ruleset it only serves to provide the attacker another vehicle
> to make you miss the alert or discount it all together.
>
> >
> >>false positive "you got owned" alerts.  It would be rather trivial to
> >>convert a simple CGI scan into a "Oh god, the world is falling"
> >>generator.
> >>
> >>Let me reiterate, the idea is a nice one.  However, in practice, its
> >>not as simple as adding a few flowbits.
> >
> >
> > It's certainly not a simple thing.  So let me pull back and make a more
> > modest suggestion, with a bit of history.  When I first started
> using snort
> > and writing my own rules, I looked at the "tag" keyword and
> though it was
> > really cool.  Then I looked at what it actually did, and it
> turned out to be
> > not-quite-so-great.  It's improved a bit since then, but there are still
> > issues with it.
>
> I would be interested in hearing what your issues with the current tag
> functionality are. I suspect that there is anything wrong that cannot be
> remedied easily as it relates to tag functionality. There might be
> features that are desired but that is a different question.
>
> > I see flowbits as very usefull in many ways, but among them
>
> Agreed.
>
> > is a sort of improved flow tagging.
>
> Disagree completely. Using flowbits forces the engine to raise multiple
> alerts for a clearly related issue. This places a burden on the analyst
> to correlate those events unless you use another tool to do the
> correlation... It also places a further burden on the system doing the
> inspection when all you really want is the response logged with the alert.
>
> > As has been suggested here, my original
> > rules had a weakness, in that it is programmatically impossible
> (or at the
> > very least prohibitively difficult) to write a rule that can
> successfully
> > distinguish between a successful response and an unsuccessful response.
> > Fully qualified analysis requires more.  It requires the application of
> > human intelligence, specifically that of a talented intrusion
> analyst.  In
> > order to give that analyst sufficient information to make an informed
> > decision, let me propose a simpler rule:
> >
> > alert tcp any $HTTP_PORTS -> any any (msg:"ATTACK-RESPONSES http attack
> > response"; flow:from_server,established; content:"HTTP/1"; depth:6;
> > flowbits:isset,http-attack; classtype:misc-activity;)
>
> Interesting out of the box thinking but why would this be preferred to
> using tag?
>
> >
> > This way, the initial attack is seen, as always.  misc-activity
> will likely
> > be a low enough priority that it doesn't trigger any "the world
> is falling"
> > alarms.  However, when the analyst is examining the attack, he
> can look for
> > the corresponding response, and use some intelligence to
> determine if the
> > response indicates that the attack was a success or not.  This
> rule *should*
> > catch the first packet of response in every case.  If the
> analyst *can't*
> > find the corresponding response, that is also usefull
> information.  It means
> > that whatever the attacker did prevented the server from responding.  I
> > would categorize that as a successful DOS attack.  No matter what, the
> > analyst has more information at his disposal with which to make
> an informed
> > assessment of the overall severity of a particular attack.
>
> see above for why I think this is less desirable. I still do not see how
> this is better then having the packets associated with the attack itself.
>
> >
> > Does this strike you as better, or worse?
>
> Worse, it creates a social attack vector and doubles the amount of work
> required.
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
>
>





More information about the Snort-sigs mailing list