[Snort-sigs] Sig Not Firing

Todd Wease twease at ...435...
Tue Jul 7 23:05:59 EDT 2009


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
>>>
>>>
>>>        
>>      
>
>
> Bill Scherr IV, GSEC, GCIA
> Principal Security Engineer
> EWA Information and Infrastructure Technologies
> bscherr at ...3384...
> bscherr at ...3385...
> 703-478-7608
>
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20090707/6d0bef3b/attachment.html>


More information about the Snort-sigs mailing list