[Snort-sigs] Sig Not Firing

Bill Scherr IV bschnzl at ...3374...
Tue Jul 7 22:43:06 EDT 2009


Todd (et al)...

   So, establishing a session to a named pipe with NULL credentials is not an exploit?  (pg. 107, 
Vista_Network_Attack_Surface_RTM.pdf, Symantec Advanced Threat Research)  That to me is an elevation of privilege, in as much as I 
now can use that connection as a side road in.  This is particularly true if my target's IDS does not react to it.  At a minimum it tells an 
attacker what is running!  I certainly want to be alerted if a bind request is issued from a network where it shouldn't be.

   This is a problem of using signature based detectors, without the entirety of the session available.  I know false positives are a problem, 
but don't discount false negatives.  Just from keeping up with all the vulnerabilities, there have to be more than 20K ways to elevate 
privilege on any given platform.  I have just under that number of rules running now, and that includes several private sources of rules.  
There is no way it can cover three platforms.  Great, we have reduced what we see to a managable level.  Maybe we can tighten down 
the blinders and reduce our staff, thereby reducing costs.  Yeah...  >>You don't increase security by limiting where you look.<<

   There will be lulls in the action when the analysis team should go looking for additional sigs.  This is awfully hard to do without full 
packet capture of some number of days.  But it is darn near impossible without some clue as to where to look (some of those false 
positives may well be "too difficult to handle now").  I am not talking about archiving the data for posterity.  I'm talking about increasing the 
size of the pool of signature contributers.  We (the defenders) are seriously lagging as it is.

   In any case, the breadth of coverage is ultimately up to the owner of the deployed system.  Hamstringing a preprocessor just puts the 
defenders at an additional disadvantage.  There should be a configuration that allows you to open (or close) your tool.  (see 
http://www.avolio.com/papers/7tenets.html)

   And, I might add that IDABench makes it easy to detect these "probes".  That is where I found them.  There just might be something 
else to them...  </rant>

B.

Circa 19:23, 7 Jul 2009, a note, claiming source Todd Wease <twease at ...435...>, was sent to me:

Date sent:	Tue, 07 Jul 2009 19:23:42 -0400
From:	Todd Wease <twease at ...435...>
To:	bschnzl at ...3374...
Copies to:	snort-sigs at lists.sourceforge.net
Subject:	Re: [Snort-sigs] Sig Not Firing

> Because the exploits lie in the requests/responses not the bind.  The 
> dce_iface rule option is a way to correlate a request/response with a 
> bound interface.  So when Snort sees a request/response with a 
> particular opnum it can correlate it to the appropriate interface that 
> the operation is being performed on - this is mainly to reduce false 
> positives that were being created with the use of flowbits.
> 
> As for your rule, I would guess if you took out the "distance:34" it 
> might work.  The major version field on ports 1024:2048 will be the 
> first byte in the payload, not the 34th (I'm just guessing that's what 
> that content is for).  You might also want to account for the case where 
> the interface uuid is represented in big-endian: "|af a8 bd 80 7d 8a 11 
> c9 be f4 08 00 2b 10 29 89|".
> 
> As far as being a recon activity, I don't really think it is until a 
> client has made a "request" to the rpcmgmt interface to actually get rpc 
> management information from it.
> 
> 
> For your rule to fire
> 
> On 07/07/2009 05:53 PM, Bill Scherr IV wrote:
> > Todd (et al)...
> >
> >     Izat so?  So, do I depart from the dcerpc preprocessor, and use the straight content parser?  Will the
> > dceprc preprocessor interfere with the content parser?  Do I need to present a proper bind response to
> > illicit an alert?
> >
> >     Along those lines, given what is said in the references, wouldn't it make sense to alert on this bind?  It
> > allows unauthenticated connection, and interaction with the target.  It is not the first time I have seen this
> > in the wild.
> >
> >     I have another rule, and more similar packets that are also not firing.  I was pointed in the direction of
> > the dcerpc prepropecessor.  It seems then that this is a dead end, and should not be.
> >
> >     Here is the other rule:
> > alert tcp $EXTERNAL_NET ANY ->  $INTERNAL_NET 1024:2048 (msg:"NETBIOS DCERPC rpcmgmt
> > ifids Unauthenticated Access"; flow:established,to_server; content:"|05|"; distance:34; content:"|80 bd a8
> > af 8a 7d c9 11 be f4 08 00 2b 10 29 89|";
> > reference:url,www.symantec.com/avcenter/reference/Vista_Network_Attack_Surface_RTM.pdf;
> > reference:url,www.blackhat.com/presentations/win-usa-04/bh-win-04-seki-up2.pdf;
> > reference:url,seclists.org/fulldisclosure/2003/Aug/0432.html; classtype:attempted-recon; sid:2999001;
> > rev:1;)
> >
> >     Sadly, it does not fire either...
> >
> >     Either way, it seems that not firing until after the bind is a gap...
> >
> > B.
> >
> > Circa 16:26, 7 Jul 2009, a note, claiming source Todd Wease<twease at ...435...>, was sent to
> > me:
> >
> > Date sent:      	Tue, 07 Jul 2009 16:26:52 -0400
> > From:           	Todd Wease<twease at ...435...>
> > To:             	bschnzl at ...3374...
> > Copies to:      	snort-sigs at lists.sourceforge.net
> > Subject:        	Re: [Snort-sigs] Sig Not Firing
> >
> >    
> >> It won't alert on the bind, but a request using that bind's context.
> >>
> >>
> >> Bill Scherr IV wrote:
> >>      
> >>> Hi Folks...
> >>>
> >>> Why wont this rule fire???
> >>>
> >>> Here is the rule:
> >>> alert tcp $EXTERNAL_NET ANY ->  $HOME_NET 1024:2048 (msg:"NETBIOS DCERPC
> >>> rpcmgmt ifids Unauthenticated Access"; flow:established,to_server; content:"|05|";
> >>> dce_iface:afa8bd80-7d8a-11c9-bef4-08002b102989;
> >>> reference:url,www.symantec.com/avcenter/reference/Vista_Network_Attack_Surface_RTM.pdf;
> >>> reference:url,www.blackhat.com/presentations/win-usa-04/bh-win-04-seki-up2.pdf;
> >>> reference:url,seclists.org/fulldisclosure/2003/Aug/0432.html; classtype:attempted-recon;
> >>> sid:2999001; rev:1;)
> >>>
> >>> Here is the packet Hex:
> >>> 0000  00 14 bf 52 fe 40 00 d0 2b 77 75 01 08 00 45 20   ...R. at ...202...+wu...E
> >>> 0010  00 70 14 b4 40 00 6b 06 xx xx dc a3 fc 38 43 a6   .p.. at ...3383...
> >>> 0020  xx xx 04 27 04 00 00 84 61 c8 c9 20 c2 24 50 18   xx.'....a.. .$P.
> >>> 0030  ff ff e0 a3 00 00 05 00 0b 03 10 00 00 00 48 00   ..............H.
> >>> 0040  00 00 01 00 00 00 d0 16 d0 16 00 00 00 00 01 00   ................
> >>> 0050  00 00 00 00 01 00 80 bd a8 af 8a 7d c9 11 be f4   ...........}....
> >>> 0060  08 00 2b 10 29 89 01 00 00 00 04 5d 88 8a eb 1c   ..+.)......]....
> >>> 0070  c9 11 9f e8 08 00 2b 10 48 60 02 00 00 00         ......+.H`....
> >>>
> >>>        
> >
> > {snipped}
> >
> >    
> >>>      Ctx Item[1]: ID:0
> >>>          Context ID: 0
> >>>          Num Trans Items: 1
> >>>          Abstract Syntax: MGMT V1.0
> >>>              Interface: MGMT UUID: afa8bd80-7d8a-11c9-bef4-08002b102989
> >>>              Interface Ver: 1
> >>>              Interface Ver Minor: 0
> >>>          Transfer Syntax[1]: 8a885d04-1ceb-11c9-9fe8-08002b104860 V2
> >>>              Transfer Syntax: 8a885d04-1ceb-11c9-9fe8-08002b104860
> >>>              ver: 2
> >>>        
> >
> > {sig snip}
> >
> >
> >
> > Bill Scherr IV, GSEC, GCIA
> > Principal Security Engineer
> > EWA Information and Infrastructure Technologies
> > bscherr at ...3384...
> > bscherr at ...3385...
> > 703-478-7608
> >
> >    
> 
> 


Bill Scherr IV, GSEC, GCIA
Principal Security Engineer
EWA Information and Infrastructure Technologies
bscherr at ...3384...
bscherr at ...3385...
703-478-7608





More information about the Snort-sigs mailing list