Whisker

Whisker

One of the first robust, automated Web checking tools available, Whisker has garnered somewhat of a cult following over the years and rightly so. This tool contains a sizable list of Web vulnerabilities that have been discovered to date. Collected by RFP from a variety of sources, including Nomad Mobile Research Center (NMRC), World Wide Web Consortium (W3C), Fyodor's Insecure.org, Rootshell.com, Bugtraq, cgichk.c, Network Associates' CyberCop, Packetstorm, ucgi.c, and various other sources, the tool is a robust Web vulnerability checker that you should know intimately.

Whisker runs on both Windows and UNIX platforms, making it highly usable by Windows and UNIX diehards alike (thus its popularity). Whisker works by attempting to connect to the target Web server with every entry in its scan.db file, which defines the checks to perform. If the connection is successful and the output from the server is in the expected format, Whisker will claim that it is vulnerable. Although the engine isn't the most intelligent and can produce false positives on occasion, it's one of the most robust Web checkers available.

To use it, we simply run it from the command line:

C:\nt\whisker\v1.4>whisker.pl -h 192.168.0.5

-- whisker / v1.4.0 / rain forest puppy / www.wiretrip.net -- = - = - = - = - =

= Host: 192.168.0.5

= Server: Apache/1.3.12 (Win32) ApacheJServ/1.1

mod_ssl/2.6.4 OpenSSL/0.9.5a mod_perl/1.22

+ 200 OK: HEAD /cgi-bin/printenv

+ 200 OK: HEAD /manual/

Here, Whisker connected to the Web server on port 80 of 192.168.0.5 and identified it as an Apache/1.3.12 for Windows (Win32). It identified four programs running on the Web server: ApacheJServ/1.1, mod_ssl/2.6.4, OpenSSL/0.9.5a, and mod_perl/1.22. All of this information can assist an attacker. Whisker also found two links that could potentially provide an attacker an entr e into the server (/cgi-bin/printenv and /manual/). As shown in Figure 15-1, when we used the first link, we obtained the following output.

Figure 15-1. Output from the /cgi-bin/printenv link

As we have stated throughout this book, the information leaked by this link is enormously helpful to an attacker. The output shows a server name, a couple of path disclosures, and even path information. If you get this type of output from one of your Web servers, you should be frightened to death. The second link found was the /manual link. Browsing this link we found the Apache HTML manual online. Although not directly damaging, these files shouldn't be there.

Rarely is either of those types of default files required on a Web server. If they appear, they should be removed immediately.

Brute Force

Whisker has the ability to brute force username and passwords when a Web site uses authentication to control access. For example, if you browse to a Web site and are greeted with something similar to Figure 15-2, you are being prompted for an HTTP Basic authentication.

Figure 15-2. Authentication prompt

Now with Whisker, you can perform HTTP Basic brute forcing with the " U" and " L" parameters. The U parameter applies a list of usernames created by listgen.pl (in the Whisker distribution) to attempt a connection with those usernames. This technique really works only on UNIX Web servers having an old form of state and user management, but it can be helpful under certain other circumstances.

Once a username is known (either through username brute forcing or poking around), the L parameter will attempt to brute force the user's password. To run this in Whisker, we do the following:

C:\> whisker.pl -h 192.168.0.5 -p 82 -L / -a test

-- whisker / v1.4.0 / rain forest puppy / www.wiretrip.net --

- Brute forcing authentication for user 'test' on url:

- /

= - = - = - = - = - =

= Host: 192.168.0.5

= Valid auth combo 'test:test' on following URL:

= http://192.168.0.5/

The "user test" is being brute forced, and Whisker has cycled through its password file to find that the user test has the password "test." By default, Whisker uses the password file (pass.txt) in the \lists directory. So we can add or remove entries in that list as needed.

Previously we had used Whisker to brute force HTTP Basic authentication on a Web server. However, we need to worry about a couple of other forms of authentication namely, NTLM and form-based authentication brute forcing. We can determine the authentication technique in a couple of ways, but one of the simplest is via the authentication dialog box sent back to the client browser. For example, Figure 15-3 shows a standard NTLM authentication dialog box from Internet Explorer.

Figure 15-3. NTLM authentication dialog box

We can tell that this is an NTLM prompt for authentication because it contains a Domain field. This field is used by Windows to authenticate a user to a particular domain.

Form-based authentication is quite different and takes on a much different form when brute force is attempted. Figure 15-4 shows a simple login page for form-based authentication.

Figure 15-4. Form-based authentication page

Form-based authentication is by far the most difficult of the three authentication mechanisms to brute force, particularly in an automated way. The popular program Brutus is one of the very few tools that can perform form-based authentication brute forcing.