Cover V10, I03
Table 1


Freeware Security Web Tools

Gary Bahadur

In today's e-commerce-enabled environment, a company's Web site is of paramount importance. Web sites are subject to daily attacks. Everything from defacement to denial of service attacks are launched against small "DotComs" and large multi-national corporations. The purpose of this article is to look at some freeware Linux tools the security-conscious administrator can use in the war against cyber attacks.

There are numerous freeware tools available for all four phases of securing a Web server. However, in the commercial arena, there are not many tools available. You probably already know some of the commercial tools such as Cybercop (, ISS (, and Retina (

There are three facets to securing a Web server. The first is the network on which it resides; the second is the operating system on which it is running; and the third is the applications running on the Web server. In this article, I will discuss in detail some tools that you can use to increase your security posture. These tools deal mainly with the version of the Web server running. For a detailed analysis of network and application security, please see "Securing Your Web Server", Sys Admin magazine, June 1999.

Web server security testing is best done with a structured approach. If you administer a small network, you probably already know the operating system on each machine and what services it is running. For administrators who have large networks, the composition of each server may not be known. Take the following steps to perform an assessment of Web servers on the network:

1. Footprint Analysis -- Scan the environment for operating systems, applications, and running services.

2. Vulnerability Analysis -- Determine potential vulnerabilities in services, applications, and running operating systems.

3. Penetration Testing -- Attempt to exploit vulnerabilities found in the Vulnerability Analysis phase.

4. Securing -- Fix the weaknesses found in the Penetration Testing phase and institute procedures to minimize future weaknesses in the environment.

The first two phases will be discussed in this article.

Footprint Analysis

Footprint Analysis is always the first step in performing a security assessment. What does this actually mean? Before testing a system, you must know what the operating system is and what services and applications are running on it. These details about the system will help uncover potential vulnerabilities. To do this, the tools are basically the same as for performing a network security assessment. First, determine the operating system and open ports to determine what services are running. This will focus our assessment activities.

Operating System Identification

Nmap is a great tool for port scanning and operating system identification. Open ports are services running on the system:

 #nmap -sT -O
 Starting nmap V. 2.54BETA5 ( )
 TCP Sequence Prediction: Class=truly random
 Difficulty=9999999 (Good luck!)
 Remote operating system guess: Linux 2.0.32-34
This output says that the target Web server is Linux. Nmap determined the operating system by the responses it received from packets sent.

Port Scanning

Port scanning looks for open ports that can allow potential connection to the system. If a connection can be made to the system, a vulnerability may exist if the service is running on that open port:

 #nmap -sT
 Starting nmap V. 2.54BETA5 ( )
 Intesting ports on (
 (The 1529 ports scanned but not shown below are in state: closed)
 Port State Service
 19/tcp open chargen 
 21/tcp open ftp 
 23/tcp open telnet 
 25/tcp open smtp 
 37/tcp open time 
 79/tcp open finger 
 80/tcp filtered http 
 113/tcp open auth 
 443/tcp filtered https 
 1723/tcp filtered pptp 
 Nmap run completed -- 1 IP address (1 host up) scanned in 12 seconds
This output indicates that the Web server has a number of open ports. We have just narrowed the potential range of vulnerabilities to the Linux operating system and services (ftp, http, auth, https, pptp, telnet, chargen, smtp, finger). Our concern is mainly for the Web server ports 80 and 443. However, all open ports can pose a risk to the Web server.

In addition to TCP port scanning, we need to know what UDP ports are open. UDP ports can pose a threat in the same manner as TCP ports:

 #nmap -sU
 Starting nmap V. 2.54BETA5 ( )
 Port State Service
 37/udp open time 
 53/udp open domain 
 67/udp open bootps 
 69/udp open tftp 
 94/udp open objcall 
 111/udp open sunrpc 
After we have determined the operating system and available ports on the Web server, we have to identify the type of Web server that is running. There are several methods to do this, all of which require connecting to the Web server port (normally 80).


Netcat (nc) is a tool to allow raw socket connection to ports. Over a raw connection, data can be sent and received. In this case, we are sending an html head request, and the Web server version can be retrieved:

 #nc 80
 HTTP/1.1 400 Bad Request
 Server: Microsoft-IIS/4.0
 Date: Wed, 06 Dec 2000 00:45:56 GMT
 Content-Type: text/html
 Cache-control: Private
The netcat command allowed us to make a raw connection to port 80 and request header information. The header information says that the version of the Web server is Microsoft IIS 4.0. We can now limit the scope of our assessment to the operating system, the Web server version, and the applications running on the server.

If this were a network security assessment, we would have to connect to all open ports and determine what each service is and what versions are running to lead us to the next phase -- Vulnerability Assessment. For most Web servers, the tcp and udp ports, which are open in the above example, can hold numerous vulnerabilities. Open ports should be strictly limited to necessary ports. The more open ports, the greater the potential risk of exploitation. Open ports can be very dangerous, so close all unnecessary ports. If this were a complete assessment of the server, all ports would have to be investigated and secured. The Web server should have a minimum amount of ports open. To completely secure all aspects of the server, perform a full network assessment.

Now that we know what the operating system is and the services that are running, we can move on to the next phase, Vulnerability Analysis.

Vulnerability Analysis

Vulnerability Analysis can focus on two areas: the operating system, and the applications. We will focus only on the applications, however. Operating system vulnerabilities will matter to us only as it pertains to the Web server software. When installed, Web server software can make modifications to the operating system that can create an exploitable weakness in the server. A Web server can be insecure through both the applications and the operating system. A security assessment is incomplete without reviewing both of these areas, however, this article focuses just on vulnerabilities related to the Web server software.

Vulnerability Scanning

We can launch scanner software that goes through a list of known vulnerabilities in Web server software. Most of these programs will aggregate exploits from different Web server software and launch the scan based on all these checks. Most are not very discriminating in selecting specific checks based on application. Each of the following programs has been compiled and executed from a Linux Redhat 6.2 system.


Whisker is a very good Web server scanning software that is updated relatively frequently and has a comprehensive list of checks.

 #./ -h -i -v
 -- whisker / v1.4.0 / rain forest puppy / --
 - Loaded script database of 1968 lines
 = - = - = - = - = - =
 = Host:
 + 404 Object Not Found: HEAD /
 = Server: Microsoft-IIS/4.0
 - Appending ::\, %2E, or 0x81 to URLs may give script source
 - Also try +.htr and %20%20.htw tricks
 - Security settings on directories can be bypassed if you use 8.3 names
 + 404 Object Not Found: GET /cfdocs/
 + 403 Access Forbidden: GET /scripts/
 + 403 Access Forbidden: GET /scripts/
 + 404 Object Not Found: GET /
 + 404 Object Not Found: GET /cfide/Administrator/startstop.html
 + 404 Object Not Found: GET /cfappman/index.cfm
 + 404 Object Not Found: GET /cgi-bin/
 + 404 Object Not Found: GET /whisker.ida
 + 404 Object Not Found: GET /whisker.idc
 + 404 Object Not Found: GET /whisker.idq
 + 404 Object Not Found: GET /whisker.htw
 + 404 Object Not Found: GET /whisker.htr
 + 403 Access Forbidden: GET /scripts/cpshost.dll
 + 404 Object Not Found: GET /samples/search/queryhit.htm
 + 404 Object Not Found: GET /adsamples/config/
 + 403 Access Forbidden: GET /scripts/counter.exe
 + 404 Object Not Found: GET /scripts/repost.asp
 + 404 Object Not Found: GET /scripts/postinfo.asp
 + 403 Access Forbidden: GET /scripts/fpadmcgi.exe
 + 403 Access Forbidden: GET /scripts/samples/
 + 403 Access Forbidden: GET /scripts/samples/search/webhits.exe
 + 403 Access Forbidden: GET /scripts/iisadmin/
 + 403 Access Forbidden: GET /scripts/iisadmin/ism.dll
 + 404 Object Not Found: GET /msadc/
 + 404 Object Not Found: GET /Sites/
 + 404 Object Not Found: GET /SiteServer/Publishing/viewcode.asp
 + 404 Object Not Found: GET /advworks/equipment/catalog_type.asp
 + 404 Object Not Found: GET /iisadmpwd/aexp4b.htr
 + 403 Access Forbidden: HEAD /scripts/samples/details.idc
 + 403 Access Forbidden: HEAD /scripts/samples/ctguestb.idc
 + 200 OK: HEAD /scripts/tools/newdsn.exe
 - this can be used to make DSNs, useful in use with our ODBC exploit
 - and the RDS exploit (with msadcs.dll)
 + 403 Access Forbidden: GET /scripts/iisadmin/bdir.htr
 + 404 Object Not Found: HEAD /carbo.dll
 + 403 Access Forbidden: HEAD /scripts/proxy/
 + 403 Access Forbidden: HEAD /scripts/proxy/w3proxy.dll
 + 404 Object Not Found: HEAD /prd.i/pgen/
 + 404 Object Not Found: HEAD /cgi-win/
 + 403 Access Forbidden: HEAD /scripts/nlog-smb.cgi
 + 403 Access Forbidden: HEAD /scripts/wwwboard/
 + 404 Object Not Found: HEAD /wwwboard/
 + 403 Access Forbidden: HEAD /scripts/
 + 403 Access Forbidden: HEAD /scripts/wwwboard/
 + 403 Access Forbidden: HEAD /scripts/wwwboard.cgi
 + 403 Access Forbidden: HEAD /scripts/wwwboard/wwwboard.cgi
 + 404 Object Not Found: HEAD /logs/
 + 404 Object Not Found: HEAD /database/
 + 404 Object Not Found: HEAD /databases/
 + 403 Access Forbidden: HEAD /scripts/campas
 + 403 Access Forbidden: HEAD /scripts/guestbook.cgi
 + 403 Access Forbidden: HEAD /scripts/
 + 403 Access Forbidden: HEAD /scripts/
 + 403 Access Forbidden: HEAD /scripts/webbbs.cgi
 + 403 Access Forbidden: HEAD /scripts/whois_raw.cgi
 + 404 Object Not Found: HEAD /webcart/
 + 404 Object Not Found: HEAD /webcart-lite/
 + 403 Access Forbidden: HEAD /scripts/AnyBoard.cgi
 + 403 Access Forbidden: HEAD /scripts/admin.php
 + 403 Access Forbidden: HEAD /scripts/code.php
 + 403 Access Forbidden: HEAD /scripts+ 403 Access \
  Forbidden: HEAD /scripts/bnbform.cgi
As we can see in the Whisker output, there are several problems associated with this Web server. There are three basic results in this output, 200 OK, 403 Access Forbidden, and 404 Object Not Found. These mean the following:

200 OK -- This result means that the exploit check was successful. The server is vulnerable to attack. This server has potential vulnerabilities in the newdsn.exe, htr, filenames, and appending characters at the end of URLs. An attacker can attempt to compromise this server through three different attacks.

403 Access Forbidden -- The scanner has found the file that the exploit is checking, but the user does not have access to the file to attempt exploitation. This is both good and bad. It is good because the attacker can not compromise the system through this method, but because the file is still there, the system may be compromised using this file in the future.

404 Object Not Found -- The scanner was not able to find the exploitable file. This is very good because the vulnerable file has been removed from the system and can not be attacked.

The scanning software goes through known security vulnerabilities that get posted to places such as Foundstone (, Security Focus (, and Packetstorm ( These program writers implement checks as the exploit becomes available to the general public.

There are a number of other Web security scanners. Some are not as comprehensive as others or do not get updated as frequently. These have varying degrees of functionality and usability. The output from several of these tools is listed below. is a Perl-based scanner that has good logging functionality and pulls back header information:

 CGI scanner [in Perl] v1.1
 HTTP Port [80]:
 Log Session?(y/n)n
 Press [enter] to check the httpd version...
 HTTP/1.1 200 OK
 Server: Microsoft-IIS/4.0
 Date: Wed, 01 Nov 2000 19:57:13 GMT
 Content-Type: text/html
 Cache-control: private
 Press [enter] to check for CGI vulnerabilities...
 Searching for UnlG - backdoor : Not Found
 Searching for THC - backdoor : Not Found
 Searching for phf : Not Found
 Searching for Count.cgi : Not Found
 Searching for test-cgi : Not Found
 Searching for nph-test-cgi : Not Found
 Searching for nph-publish : Not Found
 Searching for php.cgi : Not Found
 Searching for handler : Not Found
 Searching for webgais : Not Found
 Searching for webdist.cgi : Not Found
 Searching for faxsurvey : Not Found
 Searching for htmlscript : Not Found
 Searching for pfdisplay : Not Found
 Searching for perl.exe : Not Found
 Searching for : Not Found
 Searching for www-sql : Not Found
 Searching for view-source : Not Found
 Searching for campas : Not Found
 Searching for aglimpse : Not Found
 Searching for glimpse : Not Found
 Searching for : Not Found
 Searching for AT-admin.cgi : Not Found
 Searching for : Not Found
 Searching for : Not Found
 Searching for jj : Not Found
 Searching for info2www : Not Found
 Searching for : Not Found
 Searching for finger : Not Found
 Searching for bnbform.cgi : Not Found
 Searching for survey.cgi : Not Found
 Searching for AnyForm2 : Not Found
 Searching for : Not Found
 Searching for classifields.cgi: Not Found
 Searching for wguest.exe : Not Found
 Searching for bdir - samples : Not Found
 Searching for CGImail.exe : Not Found
 Searching for newdsn.exe : Found!
 Searching for fpcount.exe : Not Found
 Searching for counter.exe : Not Found
 Searching for visadmin.exe : Not Found
 Searching for openfile.cfm : Not Found
 Searching for exprcalc.cfm : Not Found
 Searching for dispopenedfile : Not Found
 Searching for sendmail.cfm : Not Found
 Searching for codebrws.asp : Not Found
 Searching for codebrws.asp : Not Found
 Searching for showcode.asp : Not Found
 Searching for search97.vts : Not Found
 Searching for carbo.dll :Not Found
 Server may have CGI vulnerabilities.
This scanner found only one of the problems discovered with Whisker. The other major difference is the way the output has been displayed. As seen with Whisker, there is a difference in if a file was found but not accessible (Access Forbidden), and if the file did not exist at all (Object Not Found). The Whisker output provides greater details about files found.


Malice is a Perl-based scanner that has some built-in IDS evasion functionality and large list of checks:

 Malice .5.2
 Anti IDS scanner that uses null scans with HEAD requests
 Much props to doom for editing this.
 Port: 80
 HTTP/1.1 200 OK
 Server: Microsoft-IIS/4.0
 Date: Wed, 01 Nov 2000 20:02:45 GMT
 PICS-Label: (PICS-1.0 "" l by \
  "" on "1998.10.20T15:20-0400" exp "1999.10.20T12:00-0400" r \
  (v 0 s 0 n 0 l 0))
 Content-Type: text/html
 Cache-control: private
 Checking for CGI holes.....:
 Exploit Found: /scripts/tools/newdsn.exe
 Location: /scripts/tools/newdsn.exe
 Exploit Found: /?PageServices
 Location: /?PageServices
 Exploit Found: WebDAV transversal
 Location: /secret/secret/sql_tool.shtml
 Exploit Found: default.asp
 Location: /default.asp
Malice is different from the other scanners in that it has some checks that were not in the other scanners and that can try to evade IDS systems. It didn't find two checks that were not found by Whisker or the other scanners. Another difference is that it is not displaying the checks as they are being executed and checks that have failed are not being displayed. There is a lot of benefit to displaying all activity as it is being executed.


Md-webscan is a scanner that falls somewhere in the middle of the road and has the most common checks.

 #./md-webscan -h
 md-webscan: A scanner for a few well-known CGI vulnerabilities.
 By: -=[Mordrian]=-
 Email: <>
 Version: 1.0.0
 Scanning for THC Backdoor: Not Present
 Scanning for UnlG Backdoor v1.: Not Present
 Scanning for UnlG Backdoor v1.: Not Present
 Scanning for gH.cgi: Not Present
 Scanning for The old phf: Not Present
 Scanning for Count.cgi: Not Present
 Scanning for test-cgi: Not Present
 Scanning for nph-test-cgi: Not Present
 Scanning for nph-publish: Not Present
 Scanning for php.cgi: Not Present
 Scanning for PHP's executable: Not Present
 Scanning for handler: Not Present
 Scanning for webgais: Not Present
 Scanning for websendmail: Not Present
 Scanning for webdist.cgi: Not Present
 Scanning for faxsurvey: Not Present
 Scanning for htmlscript: Not Present
 Scanning for pfdisplay.cgi: Not Present
 Scanning for perl.exe in cgi-b: Not Present
 Scanning for perl in cgi-bin: Not Present
 Scanning for Not Present
 Scanning for wwwboard.cgi: Not Present
 Scanning for www-sql: Not Present
 Scanning for view-source: Not Present
 Scanning for campas: Not Present
 Scanning for aglimpse: Not Present
 Scanning for glimpse: Not Present
Md-Scan did not have as many checks as Whisker and did not find any problems with the Web server. Again, the other difference is that it did not differentiate between a file not being present and access being denied to the exploitable file. The result Not Present doesn't tell us if the file isn't present or if access is not allowed.

When running scanner sofware, a lot of value can be had from watching the log files on the target server to see what is actually showing up. If real time IDS systems are being used, it is very important to watch the traffic to understand what is being recorded and what the IDS system thinks is happening. In almost all cases, IDS systems will not correctly identify all the attacks. It is important to know what the IDS thinks all the attacks are. Frequently, IDS systems will report false positive results.

Once the scanning phase has completed, we have a list of potentially exploitable Web programs. As seen by the checks, exploitable programs can be cgi, perl, asp, etc. These can be shipped with the Web server software or be third-party software. The last two phases, Penetration Testing and Securing, take the data gathered from the first two phases to determine actual vulnerabilities, perform the exploitation to prove it is viable, and then fix them.

The programs in Table 1 are just some of the more popular ones available freely on the Internet. Because these are freeware, the updates are sporadic. Whisker is probably the best freeware scanner currently. There are other Web security-testing tools that will be useful to the conscientious administrator. A five-minute search of the Internet will have you inundated with all forms of security testing tools.


The Footprint Analysis phase first focuses our assessment against running applications and a known operating system. The Vulnerability Analysis phase highlights potential weaknesses in the Web server, based on the service running and the operating system. The Penetration Testing phase then takes advantage of vulnerabilities and proves whether they are real or not. Not all discovered checks can be easily exploited. There may be false positive results from these tools that may not be a real problem. Securing the server is the last phase.

For the systems administrator who is limited on resources and security expertise, programs such as the ones described here can help bridge the gap between insecure and secure systems. Security is an ongoing concern. These tools should not just be run once. Security assessments should be performed on a continuous basis to keep the environment safe.

Gary Bahadur is the Chief Information Officer for Foundstone Inc. ( Foundstone specializes in security consulting and training. Gary has been performing Attack and Penetration testing for more than five years.