Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Web Server Scanners: Find Your Vulnerabilities Before Hackers Do

Robust firewall rules and strict router access control lists alone are not enough to protect a Web server. A strong Web server build policy is a must, and Web vulnerability scanners will address the security aspects of your build policy.


advertisement
hen deploying a web server and web applications, you must defend against malicious attackers who can identify and exploit the vulnerabilities in these servers and apps. The nimda worm and its predecessors painfully reminded us of that. After all, robust firewall rules and strict router access control lists alone will not protect a web server, which is why web vulnerability scanners are useful tools.

Running a web vulnerability scanner against your web servers will:

  • Identify default files and directories that hackers could exploit
  • Detect inadequate patch levels
  • Point out poor passwords
In this article, I show how scanners achieve this level of defense and how you can utilize them to strengthen the build policy of your web servers. I also offer a review of some of the better known scanners that are currently available.

Anatomy of a Web Vulnerability Scanner
Most Web vulnerability scanners consist of an engine and a database. The database contains a list of directories, file names, CGI scripts, and URLs that have known security risks. Name-your-hat hackers cull Bugtraq postings, vendor advisories, application documentation, or personal favorites to create these lists. The final database usually contains the A, B, and C lists of well-known vulnerabilities, such as the IIS Unicode string exploit (/msadc/..%c0%af..%c0%af..), the Netscape PageServices bug (?wp-html-rend), and /wwwboard/passwd.txt (perhaps running on Apache).



The vulnerabilities can be server-specific like the PageServices bug, which displays a directory listing, or they can be OS-agnostic and target CGI scripts, such as WWWBoard or PHP-Nuke, which expose any server (even Apache) to attacks.

The scanner's engine is merely a glorified method for making HTTP GET requests for each entry in the vulnerability database. A good engine, however, has some extra techniques for customizing requests. The homebrew crowd, for example, can put together a vulnerability scan using only the echo and nc (netcat) commands (e.g., echo -e "GET /wwwboard/passwd.txt HTTP/1.0\n\n" | nc -vv <target> 80).

Web Vulnerability Scanner in Your Build Policy
Web vulnerability scanners seem to be a favorite tool for malicious users, so why is including one when you deploy a web server so important? The scanner can address the security procedures of your web server build policy, in particular, the following:

  1. Testing input validation and removing unnecessary directories
  2. Removing unnecessary files and verifying the permissions on the files that rema
  3. in
  4. Ensuring strong, secure passwords
Test Input Validation and Remove Unnecessary Directories
Removing all unnecessary directories should be step one of the web server's build policy. A scanner can assist with this procedure and, to some degree, test a web application's resistance to input validation attacks. The IIS Unicode exploit is a good example of why this validation is important. A pre-emptive measure against this attack is to map the web document root to a different drive than the system volume (e.g., D:\InetPub vs. C:\Winnt\System32), which blocks command-line access via vulnerable directories such as /scripts/. Unfortunately, the /msadc/ is commonly mapped to C:\Program Files\Common Files\system\MSADC\, which is on the same drive as the system root. So if the sole security measure is re-mapping the web document root, then the server still will be vulnerable because a (very likely) unused directory remains enabled. A good vulnerability scanner will search for the IIS Unicode exploit against default and common directories—of which there can be more than 20.

Remove Unnecessary Files and Verify Permissions
The second step of a web server's build policy should be to remove unnecessary files and verify the permissions on the files that remain. The majority of checks that a vulnerability scanner conducts relate to sample files, default files, and incorrect file permissions. The default install of a Lotus Domino server, for example, places a slew of databases (.nsf files) within the web document root. Several of these files, especially the names.nsf file, contain sensitive information about the server that any anonymous Internet user may be able to read. You cannot blindly rely on Apache's security either.

An improper install of the WWWBoard message board application leaves the password file readable to anyone who cares to look for it. Older versions of the Big Brother system-monitoring tool expose arbitrary files outside of the Web document root or they allow command execution. Even improper permissions for .htaccess files give up user passwords.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date