[Snort-sigs] Suggestions for new attack response rules

Jason security at ...704...
Fri Dec 3 13:38:01 EST 2004


Joe Patterson wrote:
> I wouldn't say it necessarily breaks down.  In situation 1, you don't care,
> because you don't care about these rules anyway.  In situation 2, an
> attacker has to, in their initial attack, not only compromise the server,
> but cause the server to change its handling of the cgi that it is *currently
> running* to non-parsed-header mode, and then send back a 4xx/5xx header.

This is trivial. exit(255) will cause a 500 server error.

> That may be possible, but I would say that it *really* raises the bar.
> Situation 3 raises the bar a bit less.  An attacker has to do all the normal
> work of compromising a server, and has to make sure that all of the replies
> he gets include that custom 404 message.

or return a 500 server error or any other code not considered 
successful, this is why any IDS that relies on server response to 
determine success will be trivially evaded.

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

You should be ignoring using suppression or contextualizing using known 
data to get this. Using rules will result in evasion cases that are far 
worse than the amount of data you are dealing with.

> 
> However, if someone were to (unbeknownst to me) stick an unpatched IIS box
> in the DMZ, and that same request came in and received a 200 OK response, I
> would absolutely want to know about it immediately.  That's what I see as
> the primary value of these rules.
> 

assuming the 200 OK response is the only possible response and that the 
request is not pipelined or chained on some other way like at the end of 
a keep-alive session...

http://www.mozilla.org/projects/netlib/http/pipelining-faq.html


> -Joe
> 
> 
>>-----Original Message-----
>>From: snort-sigs-admin at lists.sourceforge.net
>>[mailto:snort-sigs-admin at lists.sourceforge.net]On Behalf Of Jason
>>Sent: Thursday, December 02, 2004 10:33 PM
>>To: Joe Patterson
>>Cc: Brian; snort-sigs at lists.sourceforge.net
>>Subject: Re: [Snort-sigs] Suggestions for new attack response rules
>>
>>
>>The concept breaks down the moment the attacker instructs the server to
>>return a HTTP 404 error document with the content you need and then
>>spawns a shell to you.
>>
>>Joe Patterson wrote:
>>
>>>It's not simple, and it's certainly not perfect.  (if we only allowed
>>>perfect rules, we'd have a lot fewer rules than we do)  But
>>
>>even given that,
>>
>>>I think it could be usefull.  The primary utility lies in setting the
>>>flowbit for the http-based attacks.
>>>
>>>Given the following situations:
>>>1) you don't have any web servers, you're just monitoring
>>
>>traffic out to the
>>
>>>net in general.
>>>Then you would probably want to disable the 4 attack response
>>
>>rules, because
>>
>>>the web servers "out there" aren't under your control, and you don't
>>>necessarily care if they're actually compromised, you primarily care if
>>>someone in the network that *is* under your control is trying
>>
>>to hack other
>>
>>>people's boxes.
>>>
>>>2) you do have webservers, all of which are well-behaved and
>>
>>use http status
>>
>>>codes in appropriate ways.
>>>Wonderful, now you'll not only know when people attack, but when they
>>>succeed.
>>>
>>>3) you have webservers that aren't quite standards compliant.
>>
>>For instance,
>>
>>>I believe that IIS servers with a custom 404 page actually give
>>
>>a status of
>>
>>>200, but return the custom 404.
>>>This isn't too big a deal.  Edit the 4 signatures for attack
>>
>>responses so
>>
>>>that they will match anything that isn't your custom 404 page.  Perhaps
>>>something like 'content:!"404 page not found"' or whatever suits your
>>>environment.
>>>
>>>4) most of your webservers are compliant, but one or two are
>>
>>smoking crack,
>>
>>>and can't be trusted to return meaningful status codes for anything.
>>>Add a suppression by_src for these rules, and only care about the alerts
>>>from your more well-behaved webservers.
>>>
>>>I just can't think of a case where these rules would actually
>>
>>be *bad*, and
>>
>>>there are certainly quite a few places where they would be usefull.
>>>
>>>I guess the alternative is to use oinkmaster with a
>>
>>modification map for the
>>
>>>1K or so rules that I think need it to add the flowbits chunk.
>>
>>But I felt
>>
>>>like this was a usefull enough thing that it would be worth
>>
>>adding to the
>>
>>>main distribution.
>>>
>>>-Joe
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Brian [mailto:bmc at ...95...]
>>>>Sent: Wednesday, December 01, 2004 4:02 PM
>>>>To: Joe Patterson
>>>>Cc: snort-sigs at lists.sourceforge.net
>>>>Subject: Re: [Snort-sigs] Suggestions for new attack response rules
>>>>
>>>>
>>>>On Wed, Dec 01, 2004 at 03:51:25PM -0500, Joe Patterson wrote:
>>>>
>>>>
>>>>>alert tcp any $HTTP_PORTS -> any any (msg:"ATTACK-RESPONSES
>>>>
>>>>User attack OK
>>>>
>>>>
>>>>>response"; flow:from_server,established; pcre:"/^HTTP/1.1 (2|3)\d\d/";
>>>>>flowbits:isset,http-user-attack; classtype:successful-user;)
>>>>
>>>>Yes, I've thought about this for a long time.  Its not anywhere near
>>>>as simple as you suggest.
>>>>
>>>>Look at how nessus handles error codes.  MANY websites no longer use
>>>>200s for "good", and 300s & 400s for various errors, they use 200s for
>>>>EVERYTHING.
>>>>
>>>>Sure, you might get a good feeling for the one or two sites you are
>>>>looking at for reducing false positives.  In the rest of the world,
>>>>just looking at HTTP codes is NOT enough.
>>>>
>>>>Brian
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>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
>>>
>>
>>
>>-------------------------------------------------------
>>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
>>
>>
> 
> 
> 
> 
> -------------------------------------------------------
> 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