[Snort-sigs] SID 1882 False Posiitives : "ATTACK-RESPONSES i d check returned userid "

SoloNet Newsfeed newsfeed at ...1411...
Wed Jun 4 10:45:11 EDT 2003


I still think there is a problem with the rule itself, mainly there are 
A LOT of webmail programs that pass this in the URL string, simply 
mucking about with a pass rule is not the most elegant way of handling 
this. I'm sure if anybody running a number of webmail programs (either 
as a host or as a network manager looking out to the live world) will 
see similar patterns. They are false positives on a number of sites. The 
rule itself is a bit simplistic, and I think could test for this effect 
a bit more thoroughly. However, without having a TCPDUMP playback of the 
actual exploit this is checking for, I'm not the best person to rewrite 
a better version of the rule.

Esler, Joel Contractor wrote:

>Create a pass rule
>
>Pass any any -> $SMTP_SERVERS any (content:"uid=";
>byte_test:5,<65537,0,relative,string; content:"gid="; distance:1; within:15;
>byte_test:5,<,65537,0,relative,string;)
>
>Then restart snort with the -o option and add the following line into your
>snort.conf  == 
>"config order: pass log alert activation dynamic"
>
>J
>
>
>-----Original Message-----
>From: SoloNet Newsfeed [mailto:newsfeed at ...1411...] 
>Sent: Wednesday, June 04, 2003 10:54 AM
>To: snort-sigs at lists.sourceforge.net
>Subject: Re: [Snort-sigs] SID 1882 False Posiitives : "ATTACK-RESPONSES id
>check returned userid "
>
>
>Actually, the fix is still triggering false positives on webmail programs:
>
>http://mail.someplaceelse.com/wm/mail/read.html?sessionid=4074abfd6118ac6e37
>9ff6527e923009&uid=189&msgid=15&mbox=user.duh.
>
>since the signature (even on the new replacement signature) here is 
>looking for both UID and GID in the content, it's getting mussed up on 
>MSGID (or message ID)
>
>alert ip $HOME_NET any -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES id check
>returned userid"; content:"uid="; byte_test:5,<,65537,0,relative,string;
>content:"gid="; distance:1; within:15;
>byte_test:5,<,65537,0,relative,string; classtype:bad-unknown; sid:1882;
>rev:7;)
>
>I guess some tuning may be required...
>
>
>David
>
>
>
>SoloNet Newsfeed Processor wrote:
>
>  
>
>>in the recent rule updates, it seems that SID 1882 has now begun 
>>generating false positives. It's search string "uid=" gets triggered on 
>>long URLs, which was evidenced by a number (20K +) alerts we received 
>>this morning.
>>
>>alert ip $HOME_NET any -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES id 
>>check returned userid"; content:"uid="; 
>>byte_test:5,<,65537,0,relative,string; classtype:bad-unknown; sid:1882;
>>rev:4;)
>>
>>I belive the byte test is incorrect, but I'm not sure how to fix it 
>>since I'm not as knowledgeable about the exploit it's trying to pick 
>>up. ANybody want to chime in on this?
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: ObjectStore.
>>If flattening out C++ or Java code to make your application fit in a 
>>relational database is painful, don't do it! Check out ObjectStore. Now 
>>part of Progress Software. http://www.objectstore.net/sourceforge
>>_______________________________________________
>>Snort-sigs mailing list
>>Snort-sigs at lists.sourceforge.net 
>>https://lists.sourceforge.net/lists/listinfo/snort-sigs
>>
>>
>> 
>>
>>    
>>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
>thread debugger on the planet. Designed with thread debugging features
>you've never dreamed of, try TotalView 6 free at www.etnus.com.
>_______________________________________________
>Snort-sigs mailing list
>Snort-sigs at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/snort-sigs
>
>
>  
>



More information about the Snort-sigs mailing list