Thursday, August 25, 2011

This is why we have nice things

A lot of people have been freaking out about the "Apache Killer" tool released on Full-Disclosure last Friday. While it's an effective way to cause a Denial of Service (DoS) against an Apache web server, and readily accessible to your average malfeasant, the good news is you don't need to let your hair catch fire over it, because the VRT had it covered before the tool was even released.

Specifically, the http_inspect preprocessor has an option to detect overly long header fields. Since the "Range:" header sent by the tool in order to exploit the bug is well over a packet's length in size, it easily triggers GID 119, SID 19 in Snort, which is set to go off for headers over 750 bytes in the standard open source configuration. For those using the Sourcefire corporate product, by default this option is set to 0 (disabled); this can of course easily be turned on, with a value as high as 1,500, and still catch the attack.

Meanwhile, we've included GID 1, SID 19825 in today's release, which looks for "Range:" headers broken in the specific way that this tool exploits. Not only will this make it easy to tell your boss you've got coverage in place for this crazy new tool, it will help anyone who may be in an environment where the long header preprocessor rule generates false positives.

You may now return to your regularly scheduled programming.

Tuesday, August 16, 2011

Rawbytes is not the modifier you're looking for

I spend a lot of time working with Sourcefire customers and open-source Snort users who write their own custom rules. Many of them are extremely astute, and some of them write rules good enough to be in the official VRT set. Others, well, not so much.

One of the biggest issues I see with custom rules is incorrect use of content modifiers. Missing out on the latest http_* buffer, of course, is totally understandable - the Snort team's constant refinement of that preprocessor has made a lot of things work better, even if it is occasionally a chore to keep up with. Mixing up depth, offset, distance, and within makes sense, too - everyone who writes Snort rules usually takes a little time to sort all those out in their brains. The one I don't understand at all, though, is people's obsession with rawbytes, especially in HTTP rules.

Seriously people, WTF? You're going out of your way to introduce rule evasion cases. The rawbytes modifier only exists because it was useful for some Telnet-related issues back in the day, and there are all of two rules outside the Telnet category that make use of it today - both of which are obscure edge cases where the rule is doing something truly unusual. No respectable Snort rule-writing class teaches you to use it; you've had to invest extra effort to even realize it exists, let alone decide to use it. Worst of all, using it to look at an HTTP header (or, heaven forbid, a URI) undoes all of the useful normalizations and de-obfuscation work done by the http_inspect preprocessor, making your rule "t%72iv%69a%6c" to avoid in the wild. Why waste your already limited time resources on breaking your rules?

So next time you think about including rawbytes in a rule, ask yourself this first: is there absolutely, positively, 100% for sure no other way to write this rule, and no chance I'm introducing an evasion in the process? If you can, without a doubt, answer yes to that question, sure, go right ahead and use rawbytes - we haven't deprecated it because the Internet is a strange place, and every so often you may run into a situation where you need it. If there's a shadow of a doubt in your mind, though, do IDSes around the world a favor, and just say no.