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