Polymorphic URLs

The word polymorphic means an object having many forms. We coined the term polymorphic URLs to refer to URLs that relate to the same resource but are written in many different ways.

In Chapter 3 we discussed the structure of URLs and how characters not allowed in the URL character set can be encoded and used. If we look at the structure of URLs closely, we see that a single URL can be represented in a number of ways. The purpose of rewriting URLs in different ways obviously is to bypass signature analysis.

Let's illustrate this point by an example. We again consider the scenario where the attacker is on 10.0.0.1 and the target server is on 192.168.7.203. Snort is running on a system called "webspy," which is listening on the same network segment as that of 192.168.7.203. We use RDS/MDAC as the attack pattern. The RDS/MDAC IIS attack involves requesting the resource msadcs.dll on a server running IIS. We make the following HTTP request to determine whether msadcs.dll exists on a particular system:

root@10.0.0.1~# nc 192.168.7.203 80

GET /msadc/msadcs.dll HTTP/1.0

HTTP/1.1 200 OK

Server: Microsoft-IIS/4.0

Date: Mon, 22 Apr 2002 11:54:07 GMT

Content-Type: application/x-varg

Content-Length: 6

 W   ?  ?  ?

The resource requested is http://192.168.7.203/msadc/msadcs.dll. The response received from the server indicates that the resource is indeed present and that the request was successful. As soon as this request was sent, an alert was written in webspy's logs that an attack had been detected by the IDS. The alert message was:

Apr 22 11:54:09 webspy snort[640]: [1:1023:3] WEB-IIS msadc/msadcs.dll access

 [Classification: access to a potentially vulnerable web application]

 [Priority: 2]: {TCP} 10.0.0.1:1195 -> 192.168.7.203:80

In the snort rule set file for IIS attacks, the following rule is responsible for detecting access to /msadc/msadcs.dll:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80

(msg:"WEB-IIS msadc/msadcs.dll access"; flags: A+;

uricontent:"/msadc/msadcs.dll"; nocase; reference:cve,CVE-1999-1011;

reference:bugtraq,529; classtype:web-application-activity; sid:1023; rev:3;)

This rule looks for the pattern /msadc/msadcs.dll in the URI string of the HTTP request. If we can rewrite the HTTP request for msadcs.dll so that it doesn't match this pattern, the attack would go by unnoticed.

Of the several ways of rewriting this request, the most common techniques are:

Hexadecimal encoding of characters

Illegal Unicode/superfluous encoding of characters

Adding fake paths

Inserting slash-dot-slash

Using nonstandard path separators

Using multiple slashes

Hexadecimal Encoding

In Chapter 3, we described how characters not allowed directly in URL strings can be encoded with a two-digit hexadecimal representation of their ASCII codes. The formal URL specifications state that only characters that cannot be represented directly should be encoded by using hexadecimal encoding by Web browsers. However, Web servers decode any character encoded in hexadecimal, including alphabets and numbers. Using hexadecimal encoding, the request

GET /msadc/msadcs.dll HTTP/1.0

can be rewritten as

GET /%6D%73%61%64%63/%6D%73%61%64%63%73%2E%64%6C%6C HTTP/1.0

The end result is the same. Snort, however, can't be fooled by hexadecimal encoding. Snort includes an HTTP preprocessor that acts like a URL decoder in order to match any encoded URLs with the stored signatures.

Illegal Unicode/Superfluous Encoding

For servers running IIS, HTTP requests encoded with illegal Unicode encoding or superfluous encoding can be sent. We discussed illegal Unicode encoding in Chapter 5. The following list shows how /msadc/msadcs.dll can be encoded with such encoding techniques.

Encoding	Encoded string
2-byte unicode	%C0%AF%C1%AD%C1%B3%C1%A1%C1%A4%C1%A3%C0%AF %C1%AD%C1%B3%C1%A1%C1%A4%C1%A3%C1%B3%C0%AE %C1%A4%C1%AC%C1%AC
3-byte unicode	%E0%80%AF%E0%81%AD%E0%81%B3%E0%81%A1%E0%81%A4 %E0%81%A3%E0%80%AF%E0%81%AD%E0%81%B3%E0%81%A1 %E0%81%A4%E0%81%A3%E0%81%B3%E0%80%AE%E0%81%A4 %E0%81%AC%E0%81%AC
Double encode	%25%32%46%25%36%44%25%37%33%25%36%31%25%36%34%25 %36%33%25%32%46%25%36%44%25%37%33%25%36%31%25%36 %34%25%36%33%25%37%33%25%32%45%25%36%34%25%36%43 %25%36%43

Snort's HTTP preprocessor also handles decoding of illegal Unicode and superfluous encoding techniques. It generates alerts when it sees such requests being sent through the network.

Adding Fake Paths

If a "../" string appears in a URL, it means that the directory before the string is backed out. This condition allows attackers to insert fake paths or fake directory names and then back them out by using "../" in the URL. Adding fake paths can foil the pattern-matching mechanism in the signature analysis engine. The following code snippet shows how fake paths can be inserted in the request for /msadc/msadcs.dll:

GET /junk/../msadc/morejunk/../msadcs.dll HTTP/1.0

Here, the pattern /msadc/msadcs.dll is broken by the addition of "morejunk/../" between /msadc/ and msadcs.dll. Snort fails to detect the RDS/MDAC attack request in this case. However, Snort is able to detect that an illegal directory traversal character was inserted in the URL string, which is cause for an alert because normal URLs never contain the "../" string.

Inserting Slash-Dot-Slash Strings

Another way of obfuscating a URL is by inserting "/./" strings in the path specification. The "./" string, when prepended to a file specification, indicates that the file specification originates from the current working directory. The following code snippet shows the /msadc/msadcs.dll request rewritten with slash-dot-slash string combinations:

GET /./msadc/./msadcs.dll HTTP/1.0

GET /././msadc/././msadcs.dll HTTP/1.0

GET /./././msadc/./././msadcs.dll HTTP/1.0

GET /.//./msadc/.//./msadcs.dll HTTP/1.0

All these strings pass through, undetected by snort. A quick fix involves inserting a signature rule in snort for the string "/./". Snort already contains the string "../" in its signature rule. The slash-dot-slash string can be added in the same category in the rule set "web-misc.rules", as follows:

web-misc.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80

(msg:"WEB-MISC http slash-dot-slash string"; flags: A+; content: "/./";

classtype:attempted-recon; sid:9999; rev:1;)

Using Nonstandard Path Separators

Servers such as Microsoft IIS allow the use of the backslash character "\" as a path separator for specifying URLs. Microsoft has used the backslash character as a file path separator since DOS days, and it chose to ignore the HTTP/1.0 and HTTP/1.1 specification of allowing only the forward slash character to be a path separator.

Hence all HTTP requests for IIS can be rewritten with the "\" character as a path separator. The request for /msadc/msadcs.dll rewritten with the "\" character is:

GET /msadc\msadcs.dll HTTP/1.0

As no pattern matches msadc\msadcs.dll in the snort rule sets, this request goes unnoticed. To fix this oversight, any IIS rule that contains a path separator in its pattern has to be rewritten with the "\" separator as well. A better approach is to write a custom preprocessor for snort that translates all "\" characters in the URL to "/".

Using Multiple Slashes

Instead of using a single slash character as a path separator, we can use multiple slash characters and have the URL work exactly as it would originally. The net effect is that intrusion detection systems such as snort get fooled with URLs having multiple slashes as path separators. The following requests are equivalent to the original request for /msadc/msadcs.dll:

GET //msadc//msadcs.dll HTTP/1.0

GET ///msadc///msadcs.dll HTTP/1.0

Mixing Various Techniques

More URLs can be derived by using a combination of the techniques discussed here. Examples of such URLs include:

GET /.\msadc/.\msadcs.dll HTTP/1.0

GET /\msadc/\msadcs.dll HTTP/1.0

GET //\\msadc//\\msadcs.dll HTTP/1.0

For effective intrusion detection, an IDS needs to have a proper HTTP decoder or preprocessor for dealing with such techniques.