[Snort-sigs] Sig Not Firing

Todd Wease twease at ...435...
Tue Jul 7 19:23:42 EDT 2009


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
>
>    

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


More information about the Snort-sigs mailing list