 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 (www.nai.com), ISS
(www.iss.net), and Retina (www.eeye.com).
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 192.168.1.1
Starting nmap V. 2.54BETA5 ( www.insecure.org/nmap/ )
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 192.168.1.1
Starting nmap V. 2.54BETA5 ( www.insecure.org/nmap/ )
Intesting ports on 192.168.1.1 (206.135.57.167):
(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 192.168.1.1
Starting nmap V. 2.54BETA5 ( www.insecure.org/nmap/ )
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
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 192.168.1.2 80
GET HEAD/HTTP1.0
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/4.0
Date: Wed, 06 Dec 2000 00:45:56 GMT
Content-Type: text/html
Set-Cookie: ASPSESSIONIDQGGQQQPO=MJMCGMIAPIHOGLBNLFJPKCAH; path=/
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
Whisker is a very good Web server scanning software that is updated
relatively frequently and has a comprehensive list of checks.
#./whisker.pl -h 192.168.1.2 -i -v
-- whisker / v1.4.0 / rain forest puppy / www.wiretrip.net --
- Loaded script database of 1968 lines
= - = - = - = - = - =
= Host: 192.168.1.2
+ 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/cfcache.map
+ 404 Object Not Found: GET /cfcache.map
+ 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/site.csc
+ 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/wwwboard.pl
+ 403 Access Forbidden: HEAD /scripts/wwwboard/wwwboard.pl
+ 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/guestbook.pl
+ 403 Access Forbidden: HEAD /scripts/edit.pl
+ 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 (www.foundstone.com),
Security Focus (www.securityfocus.com), and Packetstorm (www.packetstorm.securify.com).
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.
Cgichk.pl
Cgichk.pl is a Perl-based scanner that has good logging
functionality and pulls back header information:
#./cgichk.pl
CGI scanner [in Perl] v1.1
Host: 192.168.1.2
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
Set-Cookie: ASPSESSIONIDQQQQQGZZ=HGECMCCDEJALHKKHHCPMJLEP; path=/
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 wwwboard.pl : 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 man.sh : Not Found
Searching for AT-admin.cgi : Not Found
Searching for filemail.pl : Not Found
Searching for maillist.pl : Not Found
Searching for jj : Not Found
Searching for info2www : Not Found
Searching for files.pl : 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 textcounter.pl : 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
Malice is a Perl-based scanner that has some built-in IDS evasion
functionality and large list of checks:
./malice5.2.pl
Malice .5.2
Anti IDS scanner that uses null scans with HEAD requests
Much props to doom for editing this.
Host: 192.168.1.2
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 "http://www.rsac.org/ratingsv01.html" 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
Set-Cookie: ASPSESSIONIDQQQQQGZZ=OHECMCCDJGGMODLBHBIEDKGO; path=/
Cache-control: private
Checking 192.168.1.2 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
Md-webscan is a scanner that falls somewhere in the middle of
the road and has the most common checks.
#./md-webscan -h 192.168.1.2
md-webscan: A scanner for a few well-known CGI vulnerabilities.
By: -=[Mordrian]=-
Email: <mordrian@hotmail.com>
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 wwwboard.pl: 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.
Conclusion
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. (www.foundstone.com). Foundstone specializes in security consulting
and training. Gary has been performing Attack and Penetration testing
for more than five years.
| 
