- The Client
- The Preliminary Investigation: Day 1, Afternoon
- Penetration Testing: Day 1, Night
- Owned by Joe, Mary, Pete, and I Think My Mother
- Hacker Scripts
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.