#96 URL reference with BleedingSnort rules

BASE
closed-fixed
Interface (166)
9
2005-08-06
2005-08-06
No

This may very well be a "known problem" or "not a bug,
it's a feature", but I thought I would point out this
little annoyance...

Using the above combination, the resulting BASE alert
displays the message text from the rule, and prefixes
it with URL links for the reference tags (url, buqtraq,
cve, etc). However, many of them are *NOT* properly
linked with URL links, only the reference type "word"
and no link.

For example (using text, not pasting html, so bear with
me), the bleeding-sig 2000900, which I'll twist around
so the exact spacing of the reference tags are clear:

> alert udp $HOME_NET 3531 -> $EXTERNAL_NET 3531
> msg: "BLEEDING-EDGE Malware JoltID Agent Probing or
Announcing UDP";
> reference: url,www.joltid.com;
> reference:
url,forum.treweeke.com/lofiversion/index.php/t597.html;
> classtype: trojan-activity;
>
reference:url,securityresponse.symantec.com/avcenter/venc/data/adware/p2pnetworking.html;
> sid: 2000900; rev:3; )

This is rendered in BASE with:

> [url] url url[snort] BLEEDING-EDGE Malware JoltID
Agent Probing or Announcing UDP

Only the first [url] is really a hyperlink. The other
two urls are, well, just the word url. The rendered
html from BASE shows:

> <TD>&nbsp;&nbsp;
> <FONT SIZE=-1>[
> <A
HREF="http://securityresponse.symantec.com/avcenter/venc/data/adware/p2pnetworking.html"
> TARGET="_ACID_ALERT_DESC">url</A>]</FONT> url url
> <FONT SIZE=-1>[
> <A
HREF="http://www.snort.org/pub-bin/sigs.cgi?sid=2000900"
> TARGET="_ACID_ALERT_DESC">snort</A>]</FONT>
> BLEEDING-EDGE Malware JoltID Agent Probing or
Announcing UDP
> </TD>

Apparently the reference: tags are pushed out in the
opposite order they appear in the rule, but I don't
care what order they come in. I just want the
hyperlinks to survive intact - the 'url' words without
a real hyperlink also drop any semblance of the
original reference.

What appears to cause this is the presence or absence
of a space between the "reference:" in the rule and the
reference type. e.g., 'reference:url,www.foo.bar'
works, 'reference: url,www.foo.bar' fails.

So I'm not sure who is at fault here :-) It shows up
in BASE. But the underlying alert database is also at
fault -- we find the reference types appear twice(!) --
once with a leading space, once without:

> mysql> select * from reference_system;
> +---------------+-----------------+
> | ref_system_id | ref_system_name |
> +---------------+-----------------+
> | 1 | cve |
> | 2 | arachNIDS |
> | 3 | bugtraq |
> | 4 | url |
> | 5 | nessus |
> | 6 | McAfee |
> | 7 | cvs |
> | 8 | url |
> | 9 | arachnids |
> | 10 | cve |
> | 11 | bugtraq |
> | 12 | mcafee |
> +---------------+-----------------+
> 12 rows in set (0.00 sec)

Could this be the database plugin? The sid-message.map
file is consistent, so posting to the database via
Barnyard might not have this behavior (I don't know, I
don't have barnyard).

Could this be snort parsing the reference tags in the
rule differently? I don't feel up to source digging at
the moment so that one will be left as an exercise for
the reader (or a comment from sourcefire :-) ).

The easy fix is to blame bleedingsnort for the
occasional space after the reference: tag (which
sourcefire doesn't appear to have), but this could
wreak havoc on existing databases and archives.
Doesn't particularly bother me, but might bother
someone else.

Comments?

Jeff

Discussion

  • Kevin Johnson

    Kevin Johnson - 2005-08-06
    • labels: --> Interface
    • milestone: --> BASE
    • priority: 5 --> 9
    • assigned_to: nobody --> secureideas
     
  • Kevin Johnson

    Kevin Johnson - 2005-08-06

    Logged In: YES
    user_id=836228

    Fixed in CVS. Will be part of 1.1.4

     
  • Kevin Johnson

    Kevin Johnson - 2005-08-06
    • status: open --> open-fixed
     
  • Kevin Johnson

    Kevin Johnson - 2005-08-06
    • status: open-fixed --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks