Welcome to Volume 5, Issue 4 of The Internet Security Conference Newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.
TISC is about sharing clue. So is this newsletter. We promise to provide something useful each issue. If we don't, flame me. If you like the issue, let us know!
Enjoy, and be safe,
Dave
Most organizations disable most inbound port on their Internet-facing firewalls ñ except ports that support web applications (e.g., http/80, https/443 or portmapped equivalents; SMTP/email, DNS and other support applications may also be opened). Naturally, these ports, especially http/80 have become the most common vectors for attacks. Web attacks exploit inadequate validation of input to forms, web server and operating system configuration errors, default configurations that expose files and executables that were not intended for general access and use, and more.
Auditing your web services platforms, servers, and inbound firewall policies is a critical phase of deployment and routine assessment. Automating these processes can be A Good Thing, if you appreciate the value vs. limitations of the tools, and document the auditing methodology you choose to perform, so that you can duplicate or modify the process and preserve the security policy validation you set out to accomplish when you audit.
Todayís column identifies readily available tools that automate web auditing by injecting malicious and malformed strings as URLs into your web server. It is reprinted here, courtesy of Watchguard Technologies, for whom I originally wrote the column. We thank Watchguard for allowing us to share this with you.
Affordable Web Server Vulnerability Scanning
What is the most important initiative for Web security staff right now? Informed observers can differ on the most important next step, but with cross site scripting attacks more commonplace, complex, and malicious than ever, certainly one important initiative for keeping your Web site secure is this: timely inventory, review, and control of Common Gateway Interface (CGI) code. CGIs are those Perl, C/C++, Java, Visual Basic and shell commands your Web staff uses to create dynamic content. With the right scanners, assessing the security of CGI scripts doesn't have to be expensive. Generally speaking, Web vulnerability scanners are auditing tools specifically designed to help Web and security administrators identify potential threats to Web servers. While these tools have many purposes, we'll consider how you can use them proactively to reduce your exposure to cross-site scripting attacks.
The CGI- and URL-scanning components of Web vulnerability scanners help you answer several critical questions:
… Where are the scripts stored? Depending on the nature of your server, you may have numerous CGI directories; depending on your Web admin's file system access control policy and competency, lots of directories may not only have scripts, but other executables (.bat and .ini files) and data files (passwd, sam) you don't want publicly accessible. Web scanners help you enumerate common and frequently exploited CGI programs. Good ones let you add program names (your own, or the names of newly exploited programs). Web scanners look in the directories where CGI programs are commonly stored; several let you add directories to their databases.
Scanners automate the cataloging process, but once your auditing tool reports its findings, your work has just begun. Now you must ask:
… What is the origin of these scripts? Web servers come with many scripts, conveniently provided to help you test server functions or to shorten the time required to get your Web site live on line. But many of these scripts leave you vulnerable to common exploits. They leave terrific clues for the Web attacker, helping him identify server type and functions you've implemented (password-based authentication, shopping carts, SQL access, etc.) Your Web development staff or consultants may have written scripts from scratch, but they might have based their code on a script downloaded from www.freescripts-u-can-trust-really.com (or some such questionable source). Even custom code can provide shaky security if built from a faulty foundation.
… Why are they here? How many of the scripts you've found are necessary for proper Web site operation? Any script your staff can't associate with a necessary process should be removed, including test scripts, obsolete scripts, and many scripts loaded as part of a default Web server installation. These are the detritus Web attackers love to find and exploit.
After the enumeration and filtering processes, the scripts that remain from your report should be reviewed to answer two obvious but routinely overlooked questions:
(1) What does the script do?
(2) Does the script only do what it's intended to do?
First determine that the script performs the function required. Scripts sometimes have debug statements, functions that have been commented out rather than deleted, and possibly functions that should no longer be permitted. Consider removing these. Then make certain that the script validates input parameters from the URLs submitted by an attacker. Attackers study URLs carefully to gather information about what scripts are used and how. They then try invalid input and clever URL encoding (e.g., abusing Unicode) to see what validation checks your scripts perform. In many cases, input validation is lacking, the scripts have overly generous access permissions, et violý, the attacker discovers he can retrieve arbitrary files, execute arbitrary commands and programs, and poison or alter databases and other information on your Web that should be "read only."
If this overview of common scripting vulnerabilities has piqued your interest in auditing your Web site, I have good news. There are several very fine Web vulnerability scanners. Like their general-purpose vulnerability scanner counterparts, the commercial versions can be expensive. There are many freeware and shareware Web vulnerability scanners that run on Windows 2000 and XP, but many turn out to be crankier and more difficult to use than I'm willing to recommend, and some, in all candor, come from sources too questionable to recommend. For all or any of these reasons, I suggest you resist the temptation to download AATools, Atelier Web Security Port Scanner, Leviathan, TWWWscan, VoidEye CGI scanner, and WWWhack. Instead, choose one of the following:
Cerberus Information Scanner (CIS, freeware)
CIS is one of two general-purpose vulnerability scanners I've recommended in the past as an NT auditing tool. CIS's Win32 user interface has been updated to run on Windows 2000. Recent improvements include CGI scanning (over 125 Web Checks) and a batch mode of operation (so you can scan large numbers of servers at once). CIS also scans for MS SQL vulnerabilities. Use the Web to view the current complete list of checks or download the tool itself. If you haven't used CIS for CGI scanning, try it.
GNIT Vulnerability Scanner (Freeware)
This simple, effective scanner now runs on Windows 2000. GNIT checks for 84 vulnerable URL structures, but you can add your own directories and files to GNIT's ASCII URL database file to make it as comprehensive and customized as you wish. It runs from the DOS command line.
N-Stealth 3.5 (Free Edition)
This Win32 and Linux application is
interesting for several reasons. It's multi-lingual (nine languages). It claims
to perform over 19,000 checks and you can even use it to test whether your
intrusion detection system recognizes attempts to evade it. N-Stealth reports
(www.nstalker.com/nstealth/phantom.nstalker.com.html) offer a bit more
information about the nature of the vulnerability and exposure than other tools
I've tested.
Whisker V1.4 and
Nikto (Open Source)
Whisker is the security auditor's
(and Web attacker's) tool of choice, the canonical Swiss army knife of Web
scanners. Whisker is a Perl program. Run it via a DOS command line under the
recommended ActivePerl (www.activestate.com/Products/ActivePerl). Whisker's
long list of options is initially mystifying, perhaps even intimidating. My
recommendation is that you run the program and try all the options until you
find the one that suits your needs best. Try
whisker.pl -v -I -W -h
<webserver_address> > myreport.html
This provides a verbose output in
HTML format.
Nikto is one of several interesting
Perl command line programs that build on the basic libwhisker scanning library. Nikto
claims to have incorporated many more checks than Whisker itself. Unless you
study this arcane art form, it's impossible to verify such a claim. Moreover,
numerous scan
scripts are freely available for Whisker, and you can define your own, so
don't get caught up in the testosterone-inspired "I have more checks than
you" thing script writers have going.
All these tools generate basic HTML
reports with sufficient enumeration of suspicious CGIs and their locations to
satisfy the purposes we've outlined here. To use Whisker and Nikto, you should
be familiar with HTTP status
codes. You may also find it helpful to consult the Common Vulnerability and
Exposures (CVE) projects and database to
learn more about the nature and kinds of exploits hitherto perpetrated through
scripts. This may help you recognize similar vulnerabilities in your own
scripts.
Frankly, about all you should expect
from the scanners I've mentioned are enumeration and a terse explanation of the
vulnerabilities associated with commonly exploitable scripts. Detailed
descriptions of vulnerabilities and hyperlinks to vendor patches are rare. Even
if present, these would only address part of the problem, since a fair number
of scripts used at many Web sites are home brew or customized.
Many scanners began as tools
attackers used to identify easy targets. Attackers apply the brain cycles after
automated target acquisition. So must you. You can leave scripts on your Web
site as challenging puzzles for Web attackers to play with and solve, or you
can engage your Web staff in the process and work together to eliminate
potential trouble sources before they are exploited.
Want to raise awareness of the
threats CGIs pose and the value of CGI scanning in the process? Ask your Web
staff to write down all the scripts they think they're running on your
servers. Then run your Web scanner. Compare the results. They may be
unsettling, but you'll rest easier knowing you discovered and remedied these
vulnerabilities before, well, someone else discovered them.
Dave Piscitello is the President of Core Competence, Inc. His bio can be found at his personal web site. You may also find his weblog useful.