Re: newbie quetsions (on how much Snort sucks)

[Martin Roesch <roesch () sourcefire com>]

Dave,

I'm interested to know if you think Snort's stream reassmbler can't  
handle your 1-byte segment test *by design* or as the result of a  
*bug*?  Now, clearly it appears that you don't have anything  
approaching respect for my abilities as a developer of IDS technology  
or for the development effort that goes into Snort, but even assuming  
that I'm the worst C coder to ever fire up vi, if you spend more than a  
nanosecond to think about it you'd probably come to the conclusion that  
this just might be unplanned behavior even if a complete fuckwit like  
myself implemented it.  That being the case, if you were in the "open  
source spirit" I would probably expect to see a bug report someplace  
like snort-users or snort-devel or even in my inbox rather than blanket  
statements like "Snort's stream reassembler is horrible because it  
failed my test case" in forums like this one.  You could even take an  
extra step and actually help out (really getting into the open source  
spirit now!) by making a simple pcap of the failed session so that we  
could do the debugging for you and let you know what's going on if you  
didn't want to take an hour and figure it out yourself.  BTW, 'snort -l  
. -b' will generate a pcap in the local directory and Snort will take  
BPF filters at the command line if you need to filter out other  
traffic.

Now, just off the top of my head I suspect I know what the problem is,  
but really, couldn't you do anything more than just show up here and  
talk about how badly we suck?

As for the fragmented DCERPC records, you're right, you got us there.   
Interestingly enough, we have made allowances for just this sort of  
thing in Snort by building several APIs that allow you to extend  
Snort's functionality in case something like this comes along that we  
didn't think of when we first developed Snort.  In this particular  
case, I'd say we need to normalize the DCERPC calls which would  
indicate to me that a Snort DCERPC normalization preprocessor would be  
the appropriate route to solving this problem.  If you were interested  
in addressing the problem so that people everywhere could benefit, you  
could even implement such a thing and contribute it to the project,  
we'd be glad to evaluate it for inclusion as a part of Snort with full  
props to you for your efforts.  It sounds like you're pretty well  
versed in DCERPC (MSRPC) so you'd have a leg up on me personally on  
getting it done relatively quickly, especially since I'm incapable of  
even coding "hello, world" without introducing buffer overflows.   
Barring that, perhaps the community will respond and develop one or  
maybe even possibly one of the developers here at Sourcefire could do  
it.

Open source is a community effort, we rely on constructive criticism,  
bug reporting and community contribution/feedback to constantly improve  
the technology.  What you've been doing on this list is more like a  
drive-by on an elementary school, not exactly what I would call "in the  
spirit community of the community", but hey, who am I to criticize....

     -Marty

P.S. I've been working on a new stream reassembler since November  
that'll be introduced to Snort RSN.  If you look at the new IP  
defragmenter that I implemented which was checked into Snort CVS back  
in November, you can probably get an idea where I'm headed with the new  
stream reassembler.

P.P.S.

#include <stdio.h>

int main(int argc, char *argv[])
{
    char *buf = "Hello, world!\n";

    printf(buf);

    return 0;
}

Right?


On Jan 6, 2005, at 9:57 AM, Dave Aitel wrote:

> Jason wrote:
>
> > Dave Aitel wrote:
> >
> > > Although, keep in mind, Snort completely fails the CRI test, and  
> > > does horrible TCP reassembly, let alone SMB or MSRPC reassembly. It  
> > > just isn't up to the job of detecting an attacker who's gone to some  
> > > work to bypass this sort of thing.
> >
> >
> > This statement is misleading and implies that there are systems that  
> > do
> > better and can stand up to the same assault. A better statement might
> > be, there is no IDS/IPS up to the job of detecting the attacker who's  
> > gone to some work to bypass it.
> I would agree, if I had spent some time with Snort/NFR/ISS/etc ahead  
> of time, and gone through the work of modeling them to see what they  
> miss. However, I didn't do that. I simply implemented some realistic  
> parts of the SMB/MSRPC protocol, and made a little slidey bar to help  
> control it. There are systems that DO stand up better to these minor  
> changes, and those systems are currently known to be: NFR and ISS.  
> This is because those companies have teams that sit around  
> implementing hard protocols like MSRPC and making sure they cover  
> those bases and they've had these teams for 5 years.
>
>
> > The reality is that every IDS has evasion potentials and if you are  
> > able
> > to control the environment enough that you can influence the view of  
> > the
> > network then you can win, as simple as that.
> Yes, but for a lot of Snort rules, you can split your tcp packets into  
> 1 byte sends (i.e. userspace, not fragrouter) and evade them  
> completely. This means if you build an NIPS on top of the Snort  
> engine, it is literally trivial to evade. I'm not talking about  
> "advanced attacks" here. "Advanced attacks" tend to fail in the wild.  
> I'm talking more about basic competance.
>
> > Lets put it out there for consideration.
> >
> > - All major IDS players fail in the MSRPC space when challenged with a
> > capable attacker.
> Not actually proven true. At least two survived the first round. Then  
> again, I'm not that capable an attacker. I wasn't trying to emulate  
> anything complex with the CRI.
>
> > - No IDS can handle proper TCP state tracking when confronted with a
> > capable attacker. If you are not constrained by 5 hops between you  
> > and the endpoint with at least one of those endpoints being a system  
> > charged with noise elimination ( Checkpoint, PIX, iptables, screen  
> > router... ) you can own any state machine.
>
> TCP state tracking is hard to evade too. I have to actually do work,  
> maybe even learn how to install fragrouter. The evasions implemented  
> in the CRI are much easier to do and much more effective. I'm not  
> messing with a state machine. I'm just using standard protocols. You  
> can a third of the CRI test on any machine by setting your MTU small  
> enough. That'll completely bypass any snort-like system with one  
> command line call to ifconfig.
>
> > Moving beyond the detection space. Active technologies suffer from  
> > the same shortcomings in that they must make compromises to achieve a  
> > larger goal. IIRC Canvas will report success on an Win32 Apache  
> > Chunked encoding attack against a FreeBSD Apache server, for example.
>
> Hahaha. Yeah. Although it's likely to have just checked for port 80 to  
> be open. CANVAS is not Nessus. Now if it pulls a shell back, then we  
> have problems! :>
>
> > The moral of the story is that you have decisions to make and with  
> > open source you at least have an opportunity to make a difference.  
> > With all of the systems that compete with Snort you have no  
> > opportunity to make a difference unless you have a few million  
> > dollars and staff capable of isolating a problem. I can tell you from  
> > experience that everyone that I compete with cannot stand up to  
> > controlled environments and advanced evasion tactics.
> I guess the interesting thing is that you actually bought something  
> for your millions of dollars. Or perhaps it's a look into the Speed  
> vs. Accuracy trade off. Lots of other people have spent millions of  
> dollars on professional engines, but still fail the simple tests like  
> this because all nss.co.uk is testing for is extremely old attacks and  
> whether an IDS can take the load of millions of packets at once. This  
> is going to favor Snort-like systems largely at the expense of parsing  
> engines. I think it's telling that nss doesn't test MSRPC at all. It's  
> funny how the IDS industry has tuned itself. But set your MTU low  
> enough, and you can bypass some systems even if you're the only  
> packets on the wire. Doing SMB fragmentation basically guarantees it.
>
> If you're looking for a misleading test, the NSS.CO.UK tests are what  
> you want. They're not open tests. They're outdated. They largely test  
> for things you don't care about, such as pushing packets down a wire.  
> No scientific test should be non-repeatable, and no scientific test  
> should require such large amounts of money to change hands.
>
> What the CRI says is this: If what you're trying to detect is worms,  
> then you're perfectly fine with a Snort-like system. If you're trying  
> to detect attackers, you need to purchase a system from someone who  
> spent some cash on the problem. This is a somewhat surprising  
> conclusion for most people, such as yourself, I guess, since you feel  
> that Snort does the job.
>
> Dave Aitel
> VP R&D
> Immunity, Inc.
>
>
> ----------------------------------------------------------------------- 
> ---
> Test Your IDS
>
> Is your IDS deployed correctly?
> Find out quickly and easily by testing it with real-world attacks from  
> CORE IMPACT.
> Go to  
> http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to  
> learn more.
> ----------------------------------------------------------------------- 
> ---
--
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Discover.  Determine.  Defend.
roesch () sourcefire com - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org


--------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from 
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 
to learn more.
--------------------------------------------------------------------------