|
snort http_inspect alerts info: msg#00090security.intrusions
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> |
|---|---|---|
| Previous by Date: | RE: Traffic SNMP: 00090, Smith, Donald |
|---|---|
| Next by Date: | [LOGS] Summary of large-scale portscanning detects: 00090, Ken . Connelly |
| Previous by Thread: | "LOGS: GIAC GCIA Version 3.4 Practical Detect Tuong Dam".i: 00090, Tuong Dam |
| Next by Thread: | LOGS: GIAC GCIA Version 3.5 Practical Detect James Affeld: 00090, James Affeld |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |