[Snort-sigs] Sig Not Firing

Bill Scherr IV bschnzl at ...3374...
Wed Jul 8 22:04:13 EDT 2009


Todd (et al),

   Thanks for the rule!  I see what you guys are saying about the "distance" modifier now.  Here is the rule I have running now:

alert tcp $EXTERNAL_NET ANY -> $HOME_NET [135,139,445,1024:2048] (msg:"NETBIOS DCERPC rpcmgmt ifids 
Unauthenticated Access"; flow:established,to_server; content:"|05|"; content:"|80 bd a8 af 8a 7d c9 11 be f4 08 00 2b 10 29 89|"; 
distance:32; 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;)

The first payload byte is always 0x05.  I had the "distance" modifier following the first "content".  I think that is the source of the 
confusion here, and the where misfire occurred. ("distance" modifies the preceding "content".)  If I read the doc's right, snort will 
check the first byte to decide whether to go any further.  That should minimize the load, no?  

   It hasn't fired yet, but the attack hasn't happened again yet either.  (No false negative condition)

   You mentioned the big-endian case.  So I'll need two of these to cover.  What about the other four interfaces that allow NULL 
credentialed connection to the lsarpc, samr, and netlogon named pipes mentioned in Dr. Hoagland's analysis of Vista (and XP) 
attack surfaces?  These are not NULL sessions, but interactions with the authentication mechanisms just the same!  (All of the 
above are aliases for the "lsass" named pipe.)  That deserves an alert on an internet connection, IMHO.  Is it that hard to write a 
new switch for the preprocessor?   It sure would be nice to be able to "normalize" these. 

The interfaces Dr. Hoagland speaks of are (Fig. 6, pg 14):

12345778-1234-abcd-ef00-0123456789ab[v0.0] (LSA access(lsarpc))
12345778-1234-abcd-ef00-0123456789ac[v1.0] (samsrv)
3919286a-b10c-11d0-9ba8-00c04fd92ef5[v0.0] (LSA DS access(lsarpc))
c681d488-d850-11d0-8c52-00c04fd90f7e[v1.0] (efsrpc)

just incase someone wants to get ambitious and actually write the nine other rules currently needed.  OR, we could add them to 
the ruleset!?

Anyhow...   Thanks for your help.  I'll be back after the next DCE scan.

B.

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

Date sent:	Tue, 07 Jul 2009 23:05:59 -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

> If you just want to simply detect a bind, the following rule example 
> should suffice where the content is simply the interface uuid.
> 
> alert tcp $EXTERNAL_NET any -> $HOME_NET [139,445,1025:] (msg:"bind 
> attempt"; content:"<insert your interface uuid of choice>"; sid:1000001;)
> 
> NULL session setups (SMB) and binds (DCE/RPC) are two totally different 
> things.  A bind is not an authentication step.
> 
> 
> On 07/07/2009 10:43 PM, Bill Scherr IV wrote:
> > 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





More information about the Snort-sigs mailing list