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

| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: [Snort-sigs] False negative in 3087.1 (WEB-IIS w3who.dll buffer overflow attempt), Brian |
|---|---|
| Next by Date: | [Snort-sigs] virus rules, John Hally |
| Previous by Thread: | Re: [Snort-sigs] false +ves on IMAP fetch overflow attempt: sid 3070, Frank Knobbe |
| Next by Thread: | [Snort-sigs] L3Retriever false positives, Javier Fernandez-Sanguino |
| Indexes: | [Date] [Thread] [Top] [All Lists] |