[Snort-sigs] lots of false positives for "GPL SQL user name buffer overflow attempt"

Joel Esler (jesler) jesler at ...3865...
Tue Jan 21 09:11:02 EST 2014

isdataat reads a whole stream, so if packets are being reassembled as part of the Stream5 preprocessor, isdataat can cross those packet boundaries, while you may only receive one packet in the alert.

That may be the cause of it.  It doesn’t look that rule matches the rule in the official ruleset, yet another reason why ET forking these rules was a bad idea.

On Jan 21, 2014, at 8:48 AM, Cyrille Bollu <cyrille.bollu at ...2420...<mailto:cyrille.bollu at ...2420...>> wrote:


Signature 2102650 generates lots of false positives here.

alert tcp $EXTERNAL_NET any -> $SQL_SERVERS $ORACLE_PORTS (msg:"GPL SQL user name buffer overflow attempt"; flow:to_server,established; content:"connect_data"; nocase; content:"|28|user="; nocase; isdataat:1000,relative; content:!"|22|"; within:1000; reference:url,www.appsecinc.com/Policy/PolicyCheck62.html<http://www.appsecinc.com/Policy/PolicyCheck62.html>; classtype:attempted-user; sid:2102650; rev:3;)

It seems like the "isdataat:1000,relative" option is not taken into account, as packets are smaller than 1000 bytes.

For example, here are the last bytes of a matching packet: "(HOST=PC-MARIANNE)(USER=marianne))))".

I can provide you with a packet capture if you want



CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
Snort-sigs mailing list
Snort-sigs at lists.sourceforge.net

Please visit http://blog.snort.org for the latest news about Snort!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20140121/525cb615/attachment.html>

More information about the Snort-sigs mailing list