Home > Articles > Programming > Windows Programming

  • Print
  • + Share This
From the author of

The Preliminary Investigation: Day 1, Afternoon

The first thing I needed to do was determine the status of the network. In other words, I was looking for open ports that could indicate the presence of a rogue service or Trojan. The best tool to do this quickly and comprehensively is nmap, which I set up to perform a full 1–65,535 port scan of the entire IP address range. The command I used to do this is shown here:

nmap -sS -p 1-65535 -O 192.168.0.x-x ( where x represents the range within the subnet)

Once nmap was finished probing, I quickly scanned the output, looking for anything fishy or painfully obvious, such as port 31337, 12345, 21, 23, or anything else that represented a rogue service or popular Trojan port. While most of the computers did return positive results on ports 135–139, indicating NetBIOS and possible shares, it was the open on port 80 of the client's main server that got my attention (see Listing 1).

Listing 1-1: nmap Result of the Client's Main Server

Starting nmap V. 2.54BETA22 ( http://www.insecure.org/nmap/ )
 Interesting ports on (192.168.0.66):
(The ports scanned but not shown below are in state: closed)
Port      State     Service       
53/tcp    open      domain   
80/tcp    open      http       
135/tcp   open      loc-srv         
137/tcp   filtered  netbios-ns       
138/tcp   filtered  netbios-dgm       
139/tcp   filtered  netbios-ssn       
593/tcp   open      http-rpc-epmap     
1029/tcp  open      unknown         
1031/tcp  open      iad2          
1035/tcp  open      unknown         
1038/tcp  open      unknown         
1042/tcp  open      unknown         
1490/tcp  open      unknown             

Upon finding port 80 open, I immediately opened my browser and plugged in the server's IP address to see if this server was indeed providing Web pages, in addition to the many other things it was responsible for (port 80 is typically the port used by Web servers ). To my dismay, I found the default Internet Information Server (IIS) installation Web page. The next obvious step was to probe the Web server software for known vulnerabilities. So, I fired up a few of my favorite Web browser CGI scanners (whisker, Stealth, CGI4) and went to lunch.

When I got back, to my chagrin, I found that the IIS responded positively to most of the Unicode exploits tested by the scanners. In other words, a weakness in the Web server could be used by hackers and worms alike to infect and take over the server. Since the Unicode exploit is a rather old one, and because of the simple fact that this server was vulnerable, I was rather sure that it had not been patched in some time and was also missing the latest service packs (such as SP 6).

Unicode Explained

Unicode is one of several methods for encoding letters and numbers on a computer. What makes Unicode so distinct is that it provides a unique character for every possible letter or number, regardless of language, platform, or program. As a result, Unicode is supported by most major vendors, including Microsoft, which is responsible for the infamous IIS.

When a Web server is queried for information, it is supposed to return only resources that are located with in its allocated folders. It is not supposed to provide access to any other files on the server through directory traversal. For example, if you open Windows Explorer and make your way to the c:\windows\system32 folder, you will be presented with a file listing of this directory. However, if you go to the c:\windows\system32\..\..\ folder, you will find yourself staring at the c:\ root folder. The "\..\" tells the operating system to move up one level in the folder structure, or traverse the directory. This same technique can be used by Web servers, but it must be controlled to prevent Web users from accessing files and folders not within the Web servers root folder, which is typically c:\inetpub, in the case of IIS.

To control sneaky Web users, IIS programmers included code that reviewed the URL sent to the Web server and restricted directory traversal via the "/../" method. However, in this attempt to stop hackers, the programmers made one small oversight. They forget to include support for Unicode characters. As a result, hackers were able to use Unicode in the URL instead of the normal characters, thus bypassing the protective measures programmed into IIS. This oversight resulted in allowing a hacker to have full access to a server's files. In addition, it was discovered that the Unicode exploit gave its user the power to execute programs. This compounded the problem and made it one of the most serious threats to security that Microsoft ever faced.

  • + Share This
  • 🔖 Save To Your Account