Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Snort-Signatures
[Top] [All Lists]

Re: [Snort-sigs] false +ves on IMAP fetch overflow attempt: sid 3070

Subject: Re: [Snort-sigs] false +ves on IMAP fetch overflow attempt: sid 3070
Date: Wed, 26 Jan 2005 09:38:08 +1300
On Mon, 2005-01-24 at 22:17 -0600, Frank Knobbe wrote:
On Tue, 2005-01-25 at 15:05 +1300, Russell Fulton wrote:
I am seeing many hits on this rule for what appear to be perfectly
normal IMAP requests.

[...] My understanding of this is that we are looking for a newline within 
100
characters of 'FETCH' and alerting if we don't find it.  Unfortunately
there are many legitimate FETCH requests that are longer than 100 chars.
[..] I will be disabling this rule.

Russell,

instead of disabling it, why not just increase the amount of characters?
Perhaps... say... 300? That should be less noisy but still catch
attempts of people trying to overflow the server with long packets.

I've looked up the details on Security Focus and the exploits use 260
bytes of padding before approx 200 chars of shell code so changing the
length to 260 would appear to be safe to catch this exploit while very
substantially reducing the number of FPs. 

Would one of the good folk at SourceFire care to do this?

I am also seeing lots of FPs on "IMAP append literal overflow attempt"
sid: 3065 which is linked to the same BID.  This one has me puzzled:

alert tcp $EXTERNAL_NET any -> $HOME_NET 143 (msg:"IMAP append literal
overflow attempt"; flow:established,to_server; content:"APPEND"; nocase;
pcre:"/\sAPPEND\s[^\n]*?\s\{/smi";
byte_test:5,>,256,0,string,dec,relative; reference:bugtraq,11775;
classtype:misc-attack; sid:3065; rev:1;) 

Again if I understand this correctly it looks for APPEND followed by
{<digits> with no LF between the D and { and then checks to see if the
number is > 256.  I have had a brief look at the IMAP RFC but failed to
find simple explanation of what the number represents.  We regularly see
numbers in the range of several 1000.  Eg:
 append "Sent" (\Seen) {5081+}

Which trigger this rule.

This would appear to be much more difficult to fix.

Russell.






-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs

<Prev in Thread] Current Thread [Next in Thread>