[Snort-sigs] SNMP Missing Community String Signature FP

Eric Hines eric.hines at ...1663...
Tue Jul 11 08:53:50 EDT 2006


Matt,

Awesome explanation, thanks. I'm going to find out what device is 
sending out this community string and complete a false positive report 
for it. I'm sure their are others that people may have ignored in the past.

Best Regards,

Eric S. Hines, GCIA, CISSP
CEO, President, Chairman
Applied Watch Technologies, LLC


--------------------------------------------------

Eric S. Hines, GCIA, CISSP
CEO, President, Chairman
Applied Watch Technologies, LLC

--------------------------------------------------

Email:   eric.hines at ...1663...
Address: 1095 Pingree Road
          Suite 213
          Crystal Lake, IL
          60014
Tel:     (877) 262-7593 ext:327
Local:   (847) 854-5831
Fax:     (847) 854-5106
Web:     http://www.appliedwatch.com

--------------------------------------------------
Security Management for the Open Source Enterprise





Matthew Watchinski wrote:
> Ah the wonders of ASN.1
> 
> RFC1157-SNMP DEFINITIONS ::= BEGIN
> 
> IMPORTS
>   ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
>   FROM RFC1155-SMI;
> 
> -- top-level message
> 
> Message ::=
>     SEQUENCE {
>             version
>                 INTEGER {
>                     version-1(0)
>                 },
> 
>                 community
>                 OCTET STRING,
> 
>         data
>                 ANY
>     }
> 
> whole packet graciously stolen from b63000a.cap from ethereal
> 
> 0000  08 00 37 15 e6 bc 00 12 3f 4a 33 d2 08 00 45 00   ..7.....?J3...E.
> 0010  00 44 aa 19 00 00 80 11 11 d2 ac 1f 13 36 ac 1f   .D...........6..
> 0020  13 49 3e 2c 00 a1 00 30 0c a5 30 26 02 01 00 04   .I>,...0..0&....
> 0030  06 70 75 62 6c 69 63 a0 19 02 01 26 02 01 00 02   .public....&....
> 0040  01 00 30 0e 30 0c 06 08 2b 06 01 02 01 01 02 00   ..0.0...+.......
> 0050  05 00
> 
> What we actually care about
> 
>                     30 26 02 01 00 04   .I>,...0..0&....
> 0030  06 70 75 62 6c 69 63 a0 19 02 01 26 02 01 00 02   .public....&....
> 0040  01 00 30 0e 30 0c 06 08 2b 06 01 02 01 01 02 00   ..0.0...+.......
> 0050  05 00
> 
> Ok Lets take a look at this.
> 
> 30 - Start of a SEQUENCE
> 
> 26 - length of the SEQUENCE
> 
> 02 - Start of an INTEGER
> 
> 01 - Length of the INTEGER
> 
> 00 - Value of INTEGER which is 00 for version 1
> 
> 04 - Start of OCTET STRING
> 
> 06 - Length of the OCTET STRING
> 
> 70 75 62 6c 69 63 - Value of OCTET STRING "public"
> 
> Ok now lets look at the rule.
> 
> alert udp $EXTERNAL_NET any -> $HOME_NET 161 (msg:"SNMP missing 
> community string attempt"; content:"|04 00|"; depth:15; offset:5; 
> reference:bugtraq,2112; reference:cve,1999-0517; classtype:misc-attack; 
> sid:1893; rev:4;)
> 
> 04 00 is the content.  This looks for a "OCTET STRING" with a zero LENGTH.
> 
> Ok now here is the problem and the wonders of ASN.1.  So ASN.1 is a Type 
> Length DATA (TLD) encoding scheme that allows for the encoding of pretty 
> much anything.  Given that it allows for just about anything to be 
> encoded it's not limited to a single byte length encoding you can do fun 
> stuff like the following.
> 
> 30 - START of SEQUENCE
> 82 - High bit set length field is now 2 bytes
> 00 - Byte 1 of length field
> 26 - Byte 2 of length field
> 02 - Start of INTEGER
> 01 - Length of INTEGER
> 00 - Value of INTEGER which is 00 for version 1
> etc.....
> 
> So lets say i do 8F now my length is 16 bytes, or
> 
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 26
> 
> Hum, that's fun.
> 
> That's why we do the depth:15 offeset:5 so we can try and not be 
> avoided.  It's still possible, but it's a compromise between false 
> positive and false negative cases.
> 
> For a perfect solution you'd need a snmp v1,2,3 decoder and a fast ASN.1 
> decoder.
> 
> Hope that explains it.
> 
> Cheers,
> -matt
> 
> Eric Hines wrote:
>> Nigel,
>>
>> Packet pasted below starting from UDP Header. You are correct, as Jon 
>> pointed out, the 5 byte offset was starting from the UDP header 
>> instead of the Payload.
>>
>> But it still begs to ask as to why the rule is firing when the payload 
>> does in fact contain the public community string. Why search for |04 
>> 00| ? What would the |04 00| be indicative of if the payload does 
>> contain the community string?
>>
>>
>> 0fdd 00a1 0033 d483 3029 0201 0004 0670         .......3..0).....p
>> 7562 6c69 63a0 1c02 0400 a063 f602 0100 0201    ublic......c......
>> 0030 0e30 0c06 082b 0601 0201 0103 0005 00      .0.0...+.........
>>
>>
>>
>> Best Regards,
>>
>> Eric S. Hines, GCIA, CISSP
>> CEO, President, Chairman
>> Applied Watch Technologies, LLC
>>
>>
>> --------------------------------------------------
>>
>> Eric S. Hines, GCIA, CISSP
>> CEO, President, Chairman
>> Applied Watch Technologies, LLC
>>
>> --------------------------------------------------
>>
>> Email:   eric.hines at ...1663...
>> Address: 1095 Pingree Road
>>          Suite 213
>>          Crystal Lake, IL
>>          60014
>> Tel:     (877) 262-7593 ext:327
>> Local:   (847) 854-5831
>> Fax:     (847) 854-5106
>> Web:     http://www.appliedwatch.com
>>
>> --------------------------------------------------
>> Security Management for the Open Source Enterprise
>>
>>
>>
>>
>>
>> Nigel Houghton wrote:
>>
>>> On  0, Eric Hines <eric.hines at ...1663...> wrote:
>>>
>>>> Hi Blake,
>>>>
>>>> Thanks for your insight. Actually. the packet was provided from 
>>>> Snort. I cut the IP header for security reasons. What you are 
>>>> looking at is starting from the first byte of the payload.
>>>>
>>>> In speaking to a few others, we're noticing offset is being used 
>>>> after depth instead of before, does the order matter? It looks as if 
>>>> the contributor(s) for the rule are Brian, Nigel/Sourcefire Research 
>>>> Team.
>>>>
>>>> Can anyone from Sourcefire VRT explain whats happening with this 
>>>> rule and why its firing on these packets despite the depth/offset 
>>>> options?
>>>
>>>  
>>> Apologies for not replying sooner, I just got most of this thread in one
>>> fell swoop (not sure I actually have the whole thing yet, I still don't
>>> see the original message).
>>>
>>> I suspect you are also looking at the UDP header in the packet, don't
>>> forget that Snort knows about this and starts it's detection after the
>>> UDP header. The packet display from Snort will show you the whole thing.
>>>
>>> Anyway, not a lot more I can say without seeing the packets causing the
>>> event to occur.
>>>
>>> +--------------------------------------------------------------------+
>>>      Nigel Houghton      Research Engineer       Sourcefire Inc.
>>>                    Vulnerability Research Team
>>>
>>>          There is no theory of evolution, just a list
>>>             of creatures Vin Diesel allows to live.
>>>
>>>
>>> ------------------------------------------------------------------------- 
>>>
>>> Using Tomcat but need to do more? Need to support web services, 
>>> security?
>>> Get stuff done quickly with pre-integrated technology to make your 
>>> job easier
>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
>>> Geronimo
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>> _______________________________________________
>>> Snort-sigs mailing list
>>> Snort-sigs at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/snort-sigs
>>
>> -------------------------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job 
>> easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Snort-sigs mailing list
>> Snort-sigs at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eric.hines.vcf
Type: text/x-vcard
Size: 372 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20060711/cae582a4/attachment.vcf>


More information about the Snort-sigs mailing list