TMS zl Module IPS/IDS Signature Reference Guide RLX.10.2.2.94

ProCurve TMS zl Module IPS/IDS Signature
Reference Guide Version RLX.10.2.2.94
62
Signature ID: 355
HTTP Mis-Formatted URI with Many White Space as Separator
Threat Level: Information
Signature Description: The Hypertext Transfer Protocol (HTTP) is an application-level protocol, with its version 1.1
defined in RFC 2616. HTTP header fields, which include general-header, request-header, response-header, and entity-
header fields, follow the same generic format as that given in RFC 822. The Request-Line begins with a method token,
followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by space
(SP) characters. No CR or LF is allowed except in the final CRLF sequence. A general HTTP request should look like:
Method SP Request-URI SP HTTP-Version CRLF. This log corresponds to an anti IIPS evasion technique. A smart ID
system could feasibly extract the URI of a request by using SP (spaces) as separators, and adjust accordingly.
Interestingly enough, Apache (and perhaps earlier versions) allow you to specify a slightly different syntax:
Method<any number of spaces> URI < any number of spaces> HTTP/ Version CRLF CRLF. This will ruin any
processing dependant on the 'assumed' RFC format of a request. This implies that there can be extra spaces charactors
in the URI and IDS may miss some exact match. This rule triggers the alarm on receiving a HTTP request with many
space characters as separator. The administrator should check the web server for corresponding log.
Signature ID: 356
HTTP Invalid Version String vulnerability
Threat Level: Information
Industry ID: CVE-2008-3257
Signature Description: The Hypertext Transfer Protocol (HTTP) is an application-level protocol, with its version 1.1
defined in RFC 2616. HTTP header fields, which include general-header, request-header, response-header, and entity-
header fields, follow the same generic format as that given in RFC 822. The Request-Line begins with a method token,
followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by space
(SP) characters. No CR or LF is allowed except in the final CRLF sequence. A general HTTP request should look like:
Method SP Request-URI SP HTTP-Version CRLF; where HTTP-version should be HTTP/x.y. This rule triggers an
alarm when the version string is not found in the form, it is described above. This alert may not indicate any attack as
such. But as a precaution, the administrator should check the web server logs.
Signature ID: 357
HTTP Header with Very Big Content Length vulnerability
Threat Level: Critical
Signature Description: Hypertext Transfer Protocol is a communications protocol for the transfer of information on the
Internet. Its use for retrieving inter-linked text documents (hypertext) led to the establishment of the World Wide Web.
In HTTP request, a content length header indicates how many bytes of data follows. This rule will trigger if IIPS
receives a very big content length in the request header. This log may not represent any attack, but should be
monitored.
Signature ID: 359
DOS/Win Directory Path Syntax in URI vulnerability
Threat Level: Information
Nessus: 10843
Signature Description: This is an anti IIPS evasion technique. Microsoft windows separates directories using '\' unlike
Unix. However, if you notice in the HTTP RFC, the syntax calls for '/'. So MS Windows must silently convert from '/'
to '\' internally in IIS (as well as all other DOS/Windows based web servers). Interestingly enough, we can still use '\' in
our requests, since they are still valid as directory separators. This implies that on DOS/Windows platforms, we can use
requests such as "/cgi-bin\some.cgi", which will not match a typical "/cgi-bin/some.cgi" signature. Using such
techniques, an attacker can bypass IDS/IPS, even though there is some relevant rules for the attack or malicious
attempt.