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

SoloNet Newsfeed newsfeed at ...1411...
Wed Jun 4 07:57:00 EDT 2003


Actually, the fix is still triggering false positives on webmail programs:

http://mail.someplaceelse.com/wm/mail/read.html?sessionid=4074abfd6118ac6e379ff6527e923009&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
>
>
>  
>






More information about the Snort-sigs mailing list