logo       

snort http_inspect alerts info: msg#00090

security.intrusions

Subject: snort http_inspect alerts info

I've noticed there's a paucity of info on these alerts
on the web. Most of it is available in
doc/README.http_inspect

Here's a summary for future Googling: hope it is
helpful.

----
HTTP preprocessor messages

#define HI_EO_CLIENT_ASCII_STR
\
"(http_inspect) ASCII ENCODING"
>From README.http_inspect: "The ASCII decode option
tells us whether to decode
encoded ASCII chars, a.k.a%2f = /, %2e = ., etc. I
suggest you don't log alerts
for ASCII since it is very common to see normal ASCII
encoding usage in URLs."

#define HI_EO_CLIENT_DOUBLE_DECODE_STR
\
"(http_inspect) DOUBLE DECODING ATTACK"
This looks for a '%' character after decoding,
which would be "double
decoding" That means that there is another layer of
obfuscation, which
definitely shows hostile intent.

#define HI_EO_CLIENT_U_ENCODE_STR
\
"(http_inspect) U ENCODING"
from the high_norm.c :"%u encoding works by specifying
the
** exact codepoint to be used. For example, %u002f
would be /. So this
** all seems fine. BUT, the problem is that IIS maps
multiple codepoints
** to ASCII characters. So, %u2044 also maps to /."
extra obfuscation available to IIS exploiters, no
valid reason to use it.

#define HI_EO_CLIENT_BARE_BYTE_STR
\
"(http_inspect) BARE BYTE UNICODE ENCODING"
from README.http_inspect: "Bare byte encoding is an
IIS trick that uses
non-ASCII chars as valid values indecoding UTF-8
values. This is NOT in the
HTTP standard, as all non-ASCIIvalues have to be
encoded with a %. Bare byte
encoding allows the user to emulate an IIS server and
interpret non-standard
encodings correctly."
Basically, you are seeing odd character encoding.

#define HI_EO_CLIENT_BASE36_STR
\
"(http_inspect) BASE36 ENCODING"
This is a fairly unusual encoding scheme apparently
used in Asian versions of
Windows. From README.http_inspect: "This is an option
to decode base36 encoded
chars. I didn't have access to a server with this
option, since it appears that
this is related to certainAsian versions of windows.
I'm going off of info
from:http://www.yk.rim.or.jp/~shikap/patch/spp_http_decode.patch
So I hope that works for any of you with this option.
Please note that if you
have enabled %u encoding, this option will not work.
You have to use the
base36 option with the utf_8 option. Don't use the %u
option, because base36
won't work. When base36 is enabled, so is ascii
encoding to enforce correct
behavior."

#define HI_EO_CLIENT_UTF_8_STR
\
"(http_inspect) UTF-8 ENCODING"
>From README.http_inspect
"As for alerting, you may be interested in knowing
when you
have an utf-8 encoded URI, but this will be prone to
false positives as
legitimate web clients use this type of encoding."

#define HI_EO_CLIENT_IIS_UNICODE_STR
\
"(http_inspect) IIS UNICODE CODEPOINT ENCODING"
"We check here for IIS codepoints that map to ASCII
chars."
Rationale: why represent ASCII in IIS
codepoints/unicode? obfuscation

#define HI_EO_CLIENT_MULTI_SLASH_STR
\
"(http_inspect) MULTI_SLASH ENCODING"
Multiple slashes may be used to obfuscate attack
signatures.From
README.http_inspect:"foo/////////bar" get normalized
to "foo/bar".
Really not a legit reason to use multiple slashes.

#define HI_EO_CLIENT_IIS_BACKSLASH_STR
\
"(http_inspect) IIS BACKSLASH EVASION"
Normalize backslashes to slashes. This is again an
IIS emulation. So a
request-URI of "/foo\bar" gets normalized to
"/foo/bar".
Alerts if this is used. Clueless MS addicts might do
this with good intentions.

#define HI_EO_CLIENT_SELF_DIR_TRAV_STR
\
"(http_inspect) SELF DIRECTORY TRAVERSAL"
"This option normalizes directory traversals and
self-referential directories.
So, "/foo/this_is_not_a_real_dir/../bar" get
normalized to "/foo/bar". Also,
"/foo/./bar" gets normalized to "/foo/bar". If a user
wants to configure an
alert, then specify "yes", otherwise "no". This alert
may give false positives
since some web sites refer to files using directory
traversals."
This strikes me as odd, though- why would you refer to
./file as foo/../file?

#define HI_EO_CLIENT_DIR_TRAV_STR
\
"(http_inspect) DIRECTORY TRAVERSAL"
"This option normalizes directory traversals and
self-referential directories.
So, "/foo/this_is_not_a_real_dir/../bar" get
normalized to "/foo/bar". Also,
"/foo/./bar" gets normalized to "/foo/bar". If a user
wants to configure an
alert, then specify "yes", otherwise "no". This alert
may give false positives
since some web sites refer to files using directory
traversals."
This strikes me as odd, though- why would you refer to
./file as foo/../file?


#define HI_EO_CLIENT_DIR_TRAV_STR
\
"(http_inspect) DIRECTORY TRAVERSAL"
"This option normalizes directory traversals and
self-referential directories.
So, "/foo/this_is_not_a_real_dir/../bar" get
normalized to "/foo/bar". Also,
"/foo/./bar" gets normalized to "/foo/bar". If a user
wants to configure an
alert, then specify "yes", otherwise "no". This alert
may give false positives
since some web sites refer to files using directory
traversals."
This strikes me as odd, though- why would you refer to
./file as foo/../file?

#define HI_EO_CLIENT_APACHE_WS_STR
\
"(http_inspect) APACHE WHITESPACE (TAB)"
from README.http_inspect:
"* apache_whitespace [yes/no] *
This option deals with non-RFC standard of tab for a
space delimiter. Apache
uses this, so if the emulated web server is Apache you
need to enable this
option. Alerts on this option may be interesting, but
may also be false
positive prone."

#define HI_EO_CLIENT_IIS_DELIMITER_STR
\
"(http_inspect) NON-RFC HTTP DELIMITER"
from README.http_inspect: "I originally started out
with \n being IIS specific,
but Apache takes thisnon-standard delimiter was well.
Since this is common, we
always take this as standard since the most popular
web servers accept it. But
you can stillget an alert on this option."
In other words, fairly common usage, both Apache and
IIS, so don't worry.

#define HI_EO_CLIENT_NON_RFC_CHAR_STR
\
"(http_inspect) NON-RFC DEFINED CHAR"
This is one you have to configure. You can tell it to
alert on particular
bytes, which is powerful, but could fill your logs in
a heartbeat if you pick
the wrong bytes.
>From README.http_inspect: "This option let's users
receive an alert if certain
non-RFC chars are used ina request URI. For instance,
a user may not want to
see NULL bytes in therequest-URI and we can give an
alert on that. Please use
this option withcare, because you could configure it
to say, alert on all '/' or
somethinglike that. It's flexible, so be careful."

#define HI_EO_CLIENT_OVERSIZE_DIR_STR
\
"(http_inspect) OVERSIZE REQUEST-URI DIRECTORY"
There are IDS evasion techniques that send extremely
large URI directory
requests, attempting to put the attack signature past
the end of the buffer
subject to IDS inspection.
(whisker -I
4.http://www.ussrback.com/docs/papers/IDS/whiskerids.html
An optimization of some raw ID systems is to only look
within the first xx bytes
of the request. Generally this works well, since the
first line of the request
needs to contain the URI. However, we can exploit this
by submitting a request
along the lines of:
    GET /rfprfp<lots of
characters>rfprfp/../cgi-bin/some.cgi HTTP/1.0"

Some news caching, such as Yahoo, will have directory
paths > 300 bytes and trip
this alert

#define HI_EO_CLIENT_LARGE_CHUNK_STR
\
"(http_inspect) OVERSIZE CHUNK ENCODING"
>From README.http_inspect:
"This option is an anomaly detector for abnormally
large chunk sizes. This
picksup the apache chunk encoding exploits, and may
also alert on HTTP tunneling
that uses chunk encoding"

#define HI_EO_CLIENT_PROXY_USE_STR
\ "(http_inspect) UNAUTHORIZED PROXY
USE DETECTED"
This simply checks for the use of proxy servers that
you haven't defined when
enabling this alert.

#define HI_EO_ANOM_SERVER_STR
\
"(http_inspect) ANOMALOUS HTTP SERVER ON UNDEFINED
HTTP PORT"
This has to be enabled- inspects all traffic looking
for http commands, alerting
on any ports not defined as http.




__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
_______________________________________________
Intrusions mailing list
Intrusions@xxxxxxxxxxxxxx
http://www.dshield.org/mailman/listinfo/intrusions



<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise