Re: More sid 1841

[Matt Kettler <mkettler () EVI-INC COM>]

At 12:03 AM 2/21/2003 -0600, Schmehl, Paul L wrote:
> Correct me if I'm wrong, but since double quotes have to be escaped
> inside a content statement, perhaps this is the problem with rule 1841 -
> content:"javascript://\" is seen as an open-ended statement.  (The
> closing double quote is "escaped" by the preceding backslash.)
>
> This rule appears to be triggering on "javascript://", not on
> "javascript://\".
>
> I'm very curious about the example (Fig. 2.11) in the rules section of
> the online documentation.
> (<http://www.snort.org/docs/writing_rules/chap2.html#content-list%20exam
> ple>)  Just prior to that example, the doc clearly states that ", : and
> | must be escaped in content statements.  If I understand this
> correctly, then Fig. 2.11 is misleading.  It reads:
>
> alert tcp any any -> 192.168.1.0/24 143 (content: "|90C8 C0FF
> FFFF|/bin/sh";
>
> Whereas it *should* be:
>
> alert tcp any any -> 192.168.1.0/24 143 (content: "\|90C8 C0FF
> FFFF\|/bin/sh";
>
> Correct?
WRONG. The above rule is correct as designed.

They aren't trying to find the literal text |90C8 C0FF FFFF| in the packet, 
they are trying to find the hex bytes 90c8 c0ff ffff in the data.

The usage of the | here is to indicate that the data desired is a hex 
value, not a text string. The only time you need a \ in front of | is when 
you want to look for | in the data instead of indicating that you want to 
find a hex pattern.

So if I wanted to look for the text "| more" in a packet I'd need to use 
"\| more" in my rule. If I wanted to look for the hex value 0a (which is a 
linefeed) in my packet I'd use "|0a|".

The reason that you "need" the escaping is to tell snort that your not 
trying to switch over to hex patterns and that you really are looking for a 
| character.


The Javascript rule you keep running in circles around is also 
intentionally laid out that way. The \ is there to indicate that the : is 
literally a : So "javascript\://" is looking for javascript://, and that is 
exactly what the rule is designed to look for, and alert on.

Unfortunately javascript:// is safe in a few cases, but dangerous in a lot 
of others. There's no good way for a snort rule to tell the difference 
between a hostile attack, and an unusual, but safe, piece of javascript. 
This is very true of a lot of snort rules.

There are some ways of improving this rule by adding some "exceptions" for 
the common "safe" usages of this string. But there's a lot of exceptions to 
the general rule.

One example that adds an exclusion for the most common FP case is this rule:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"EXPERIMENTAL
WEB-CLIENT javascript URL host spoofing attempt";
flow:to_client,established; content:"javascript\://";
content:!"javascript\://\"";nocase; classtype:attempted-user;
reference:bugtraq,5293; sid:1001841; rev:1;)

but Svein Erik Søberg correctly points out

"The remaining alerts all contain some variations of 
'href="javascript://Scroll up"' (or 'Privacy', 'Disclaimer' and so on)."

So even that rule does still have false positives.

Of course, this is why sid 1841 is *experimental* in the first place :)













-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users