[Snort-sigs] Suggestions for new attack response rules
jpatterson at ...2901...
Mon Dec 6 05:16:02 EST 2004
I assume by shell header you mean something along the lines of signature
2123, the Microsoft cmd.exe banner. That doesn't quite work. It's a great
rule, and I'm glad to have it, but it's even more trivially evaded than my
rules. Of course, the cynic in me feels that if my suggestions are as
ineffective as bmc and Jason seem to feel, then perhaps all of the trivially
evaded attack response rules, which would be pretty much all of them, should
be deleted since they generate so many false negatives... But that would be
mean, so I won't say it. :)
But back to the point at hand, first take a look at a recent post of mine
about http_inspect_server. It applies in what I feel are somewhat
disturbing ways to several attack response rules.
But more importantly, signature 2123 only fires if the attacker doesn't pass
anything to cmd.exe via /c or similar. Certainly some attackers will do
this, but not all.
To my mind, it's a progression of making life harder and harder for an
attacker. 2123 is a good rule, IMHO, and will catch some successful
attacks. It *is* trivially evaded, but will catch successful attacks by
attackers who don't put forth that trivial effort. Signature 1292
(ATTACK-RESPONSES directory listing) will catch the strangely common case of
attacks that try and find a cmd shell using "/c dir", but is trivially
evaded by attacks that instead send "/c echo moo". Likewise, it will catch
some things, but will miss attacks that put forth the effort to evade it.
The next step in the evolution, as I see it, is my initial suggestion of
looking for ?? http response codes. This *should* catch even more
things than either 2123 or 1292. It will catch the attackers who are smart
enough to evade those signatures, but not quite clever enough to make sure
that all of their commands terminate with a false exit status, or some other
method for avoiding the generation of a non-error status code. The next
step is my refined suggestion to have a rule which logs *some* context in
the response to every attack. This requires the attacker to craft his
attacks in such a way that the response is indistinguishable *to an
intelligent human analyst* from normal traffic. This is certainly possible
also, but it makes life harder for the attacker, and I am strongly in favor
of making life very very hard for attackers.
> -----Original Message-----
> From: snort-sigs-admin at lists.sourceforge.net
> [mailto:snort-sigs-admin at lists.sourceforge.net]On Behalf Of Nick
> Sent: Sunday, December 05, 2004 9:09 AM
> Cc: snort-sigs at lists.sourceforge.net
> Subject: Re: [Snort-sigs] Suggestions for new attack response rules
> Joe Patterson said the following on 03/12/2004 11:38:
> > The primary utility I'm trying to get to here is this. Looking
> at one of my
> > apache webservers, in the last two weeks I've gotten 70 requests for
> > /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir. They all got a 400
> > response. They all triggered an IDS alert. Those alerts weren't really
> > false positives. It was a real attack, but the server wasn't
> vulnerable. I
> > certainly can't ignore those alerts, but I can take my time
> getting to them.
> Just to put a different slant on this, in the above example I
> alert in a low
> state (changing the categories) for this rule and it gets kept in
> the DB for the
> stats each month. BUT if I see the actual shell header coming
> back from port 80
> (ie. the backdoor they created) then this rings the all the alarm
> bells at a
> high state and gets me out of bed. Of course this does give some
> FPs if you
> have webpages that contain windows shell headers. I guess you
> could then match
> these to the original alert with flowbits?
> 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.
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net
More information about the Snort-sigs