Be the hacker

A good intrusion-detection system is one way to fight off hackers. Studying news of security threats and installing the latest patches is another excellent idea. Hacking your own Web site to verify that it's secure is yet another.

If you hack your own network, make sure to give yourself a safe environment. Making back-up copies of server files and configuration data can be a  lifesaver when your hacking attempts succeed beyond your wildest expectations. And make sure the appropriate people know what you're doing beforehand. In your status reports and memos, however, don't refer to your activities as hacking. Use the term "auditing" - it sounds better. Nonetheless, ethical hacking is what you'll be doing.

During a recent project to improve security at a Microsoft  Internet Information Server (IIS) 5.0-based Web site, we used five hacking tools:

•  @stake's  NetCat 1.1; a script-driven utility that connects to Web sites, sends HTML requests and shows the Web sites' responses.

•  Rain Forest Puppy's  Whisker 2.1 for Unix and Whisker 1.4 for Windows; Web site checking tools that obtain Web site contents, run programs on the Web server and crack Web site passwords.

•  HooBie's  Brutus AET2 and EliteSys' Entry 2.7; superlative, fast password crackers.

•  Tennyson Maxwell Information Systems'  Teleport Pro 1.29; a Web spider that discovers and copies Web server files.

Our self-hacking game plan was to gain access to the Web site by bombarding it with badly formed URLs, cut through authentication barricades by guessing passwords and copy Web site files once we'd cracked the site's security. The five tools helped by revealing operating system and other files on the Web server, defeating password protections and even obtaining (simulated) credit card files.

Some really bad characters

Our research, in combination with NetCat's documentation, suggested that we could break in by using the UniCode IIS bug. This Microsoft IIS vulnerability was discovered in October 2000, but many sites have yet to apply the security patches that fix it.

It works this way: A hacker tries to access the network via a particular type of badly formed URL, which can cause the Web server to give the hacker access to directories containing files and executables. The hacker can then copy the files or download the executable and launch it remotely.

Our first goal was to gain some basic information about the Web site. In a typical Web server interaction, a client's browser sends a "GET/Default.htm" request to the Web server, along with some browser identification data (such as Mozilla/4.0+ compatible; +MSIE+5.5; +Windows +NT +4.0). The Web server responds with a return code of 200, which indicates success, some identifying information of its own and the contents of the Default.htm Web page.

Examining the Web server's responses told us volumes about that specific Web server. We easily discovered details that let us access its operating system files, data files, script programs and databases.

An example of this dangerous type of URL is www.sitenamehere.com/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+d:\. Unless patched, the Web site responds to this URL with a list of directories and files on the server's D: drive.

We were able to use special characters (illegal Unicode encodings of the "/" character) inside bizarre-looking URLs to gain access to directories that we shouldn't have had access to, such as the directory\WINNT\System32. Inside that directory, we found the server's command shell CMD.EXE program.

In separate tests, we experimented with Unix and Linux machines running Apache Web server software. We found that Unix and Linux files also are at risk. For example, a server might have a Perl CGI  script index program as part of the site's search feature. Sending a www.site.com/index.cgi?page=index.cgi GET request to the server revealed the source code for the index.cgi program. We could glean quite a bit of information about a site by examining the Perl script that implements its search feature.