Vulnerability Scanners
|
| < Day Day Up > |
|
Web servers such as Apache, iPlanet, and IIS have gone through many revisions and security updates. A web vulnerability scanner basically consists of a scanning engine and a catalog. The catalog contains a list of common files, files with known vulnerabilities, and common exploits for a range of servers. For example, a vulnerability scanner looks for backup files (such as renaming default.asp to default.asp.bak) or tries directory traversal exploits (such as checking for ..%255c..%255c). The scanning engine handles the logic for reading the catalog of exploits, sending the requests to the web server, and interpreting the requests to determine whether the server is vulnerable. These tools target vulnerabilities that are easily fixed by secure host configurations, updated security patches, and a clean web document root.
Nikto
Whisker, created by RFP, was created to add to a Perl-based scanning library rather than as a solo tool that would be further developed. Nikto, by Sullo, is based on the next generation LibWhisker library. From the start, it offers support for the Secure Sockets Layer (SSL), proxies, and port scanning.
Implementation
As a Perl-based scanner, nikto runs on Unix, Windows, and Mac OS X. It uses standard Perl libraries that accompany default Perl installations. You can download nikto from http://www.cirt.net. Nikto also requires LibWhisker (LW.pm), which is simple to install.
LibWhisker A fully functional copy of LibWhisker comes with the nikto tar file. Otherwise, you can always download the latest version from http://www.wiretrip.net/rfp/2/index.asp. Installation is simple, but it does vary ever so slightly from most CPAN modules. After untarring the download, enter the directory and make the library. Once that is done, install LW.pm into your Perl directory. You can do this in three commands:
$ cd libwhisker-current $ perl Makefile.pl lib $ perl Makefile.pl install
LibWhisker might seem redundant because it apes the functionality of several Perl modules that already exist, such as LWP, Base64, and HTML::Parser. The advantage of LibWhisker is that it is lean (a smaller file size than all the other modules it replaces), simple (a single module), focused (handles only HTTP and HTTPS requests), and robust (provides a single interface for handling request and response objects). It is also more legible than the original whisker! LibWhisker has also joined the legions of open source code on the sourceforge.net servers, so it shouldn’t be too hard to find.
Scanning To get started with nikto you need only to specify a target host with the -h option. As the engine discovers potential vulnerabilities, notes accompany the output to explain why a finding may be a security risk:
--------------------------------------------------------------------------- - Nikto 1.30/1.15 - www.cirt.net + Target IP: 10.0.1.14 + Target Hostname: + Target Port: 80 + Start Time: Thu Sep 25 17:07:36 2003 --------------------------------------------------------------------------- - Scan is dependent on "Server" string which can be faked, use -g to override + Server: Apache-AdvancedExtranetServer/2.0.44 (Mandrake Linux/11mdk) mod_perl/1.99_08 Perl/v5.8.0 mod_ssl/2.0.44 OpenSSL/0.9.7a PHP/4.3.1 + All CGI directories 'found' - assuming invalid responses and using none (use -a to force check all possible dirs) + Allowed HTTP Methods: GET,HEAD,POST,OPTIONS,TRACE + HTTP method 'TRACE' is typically only used for debugging. It should be disabled. + mod_ssl/2.0.44 appears to be outdated (current is at least mod_ssl/2.8.15) (may depend on server version) + OpenSSL/0.9.7a appears to be outdated (current is at least 1.15) + PHP/4.3.1 appears to be outdated (current is at least PHP/4.3.3) + mod_ssl/2.0.44 OpenSSL/0.9.7a PHP/4.3.1 - mod_ssl 2.8.7 and lower are vulnerable to a remote buffer overflow which may allow a remote shell (difficult to exploit). CAN-2002-0082. + PHP/4.3.1 - PHP below 4.3.3 may allow local attackers to safe mode and gain access to unauthorized files. BID-8203. + /~root - Enumeration of users is possible by requesting ~username(responds with Forbidden for real users, not found for non-existent users) (GET). + / - TRACE option appears to allow XSS or credential theft. See http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details (TRACE) + 1161 items checked - 2 items found on remote host + End Time: Thu Sep 25 17:10:03 2003 (147 seconds) ---------------------------------------------------------------------------
Table 7-1 lists the basic options necessary to run nikto. The most important options are setting the target host, the target port, and the output file. Nikto accepts the first character of an option as a synonym. For example, you can specify –s or –ssl to use the HTTPS protocol, or you can specify –w or –web to format output in HTML.
| Nikto Option | Description |
|---|---|
| -host | Specify a single host. Nikto does not accept files with hostnames, as in the –H option for whisker. |
| -port | Specify an arbitrary port. Take care; specifying port 443 does not imply HTTPS. You must remember to include –ssl. |
| -verbose | Provide verbose output. This cannot be abbreviated (-v is reserved for the virtual hosts option). |
| -ssl | Enable SSL support. Nikto does not assume HTTPS if you specify target port 443. |
| -generic | Instruct nikto to ignore the server's banner and run a scan using the entire database. |
| -Format | Format output in HTML, CSV, or text. Must be combined with |
| -output | Log output to a file. For example, |
| -id | Provide HTTP Basic Authentication credentials. For example, |
| -vhost | Use a virtual host for the target web server rather than the IP address. This affects the content of the HTTP Host: header. It is important to use this option in shared server environments. |
| -evasion | IDS evasion techniques. Nikto can use nine different techniques to format the URL request in an attempt to bypass unsophisticated string-matching intrusion detection systems. |
You should remember a few basics about running nikto: specify the host (-h), port (-p), and SSL (-s), and write the output to a file. A handful of additional options are described in Table 7-2. For the most part, these options widen the scope of a scan’s guessing routines.
| Option | Description |
|---|---|
| -allcgi | Scan all possible CGI directories. This disregards 404 errors that nikto receives for the base directory. See the “Config.txt” section for instructions on how to configure which directories it will search. |
| -cookies | Print the cookies returned by the server. This either produces too much unnecessary information or very useful information depending on how the server treats unauthenticated users. |
| -mutate | Mutated checks are described in the “Config.txt” section. |
| -root | Prepend the directory supplied with –root to all requests. This helps when you wish to test sites with "off by one" directory structures. For example, many language localization techniques will prepend a two-character language identifier to the entire site. |
| -findonly | Scan the target server. The scan can use nmap or internal Perl-based socket connections. |
| -nolookup | Do not resolve IP addresses to hostnames. |
| -timeout N | Stop scanning if no data is received after a period of N seconds. The default is 10. |
| -useproxy | Use the proxy defined in the config.txt file. Previous versions of nikto required you to turn this option on or off in the config.txt file. This is more convenient. |
| -debug | Enable verbose debug messages. This option cannot be abbreviated. It basically enumerates the LibWhisker request hash for each URL nikto retrieves. This information quickly becomes overwhelming; here's just a small portion of the information printed: |
| -dbcheck | Perform a syntax check of the main scan_database.db and user_scan_database.db files. These files contain the specific tests that nikto performs against the server. You should need this only if you decide to customize one of these files (and if you do, consider dropping the nikto team an e-mail with your additions). This option cannot be abbreviated. |
| -update | Update nikto's plug-ins and find out whether a new version exists. This option cannot be abbreviated. |
The –update option makes it easy to maintain nikto. It causes the program to connect to http://www.cirt.net and download the latest plug-ins to keep the scan list current:
$ ./nikto.pl –update + No updates required. + www.cirt.net message: Please report any bugs found in the 1.30 version
Config.txt Nikto uses the config.txt file to set certain options that are either used less often or are most likely to be used for every scan. This file includes a dozen settings. An option can be unset by commenting the line with a hash (#) symbol. Here are the default settings:
CGIDIRS=/bin/ /cgi/ /mpcgi/ /cgi-bin/ /cgi-sys/ /cgi-local/ /htbin/ /cgibin/ /cgis/ /scripts/ /cgi-win/ /fcgi-bin/ #CLIOPTS=-g –a #NMAP=/usr/bin/nmap KIPPORTS=21 111 #PROXYHOST=10.1.1.1 #PROXYPORT=8080 #PROXYUSER=proxyuserid #PROXYPASS=proxypassword DEFAULTHTTPVER=1.1 #PLUGINDIR=/usr/local/nikto/plugins MUTATEDIRS=/....../ /members/ /porn/ /restricted/ /xxx/ MUTATEFILES=xxx.htm xxx.html porn.htm porn.html GOOGLERS=password passwd login
The CGIDIRS setting contains a space-delimited list of directories. Nikto tries to determine whether each directory exists before trying to find files within it, although the –allcgi option overrides this behavior.
The CLIOPTS setting contains command-line options to include every time nikto runs, which is useful for shortening the command line by placing the –generic, –verbose, and –web options here.
NMAP and SKIPPORTS control nikto’s port-scanning behavior (-findports). If the nmap binary is not provided (which is usually the case for Windows systems), nikto uses Perl functions to port scan. The SKIPPORTS setting contains a space-delimited list of port numbers never to scan.
Use the PROXY* settings to enable proxy support for nikto.
Although there is rarely a need to change the DEFAULTHTTPVER setting, you may find servers that support only version 1.0.
The PLUGINDIR setting points to the directory for default and user-defined plug-ins (equivalent to whisker scan.db files). By default, nikto looks for the /plugins subdirectory in the location from which it is executed.
The MUTATE* settings greatly increase the time it takes to scan a server with the –mutate option. MUTATEDIRS instructs nikto to run every check from the base directory or directories listed here. This is useful for web sites that use internationalization, whereby the /scripts directory becomes the /1033/scripts directory. The MUTATEFILES settings instructs nikto to run a check for each file against every directory in its current plug-in. Note that there are two mutate techniques, -mutate-3 and –mutate4, that ignore these values. Technique 3 performs user enumeration against Apache servers by requesting /~user directories, which takes advantage of incorrectly configured public_html (UserDir module) settings in the httpd.conf file. Technique 4 is similar, but it uses the /cgi-bin/cgiwrap/~ method.
The GOOGLERS setting provides some fun Google searches for finding sensitive information. This technique is better accomplished with a browser and slightly more sophisticated searches. It serves more a role of curiosity in nikto as opposed to important functionality.
| Tip | If you are interested in wading through Google’s cache, try these War-Googling or “Wargling” queries: |
 |
As an administrator, you should be running vulnerability scanners against your web servers as part of routine maintenance. After all, it would be best to find your own vulnerabilities before someone else does. On the other hand, how can you tell if someone is running these tools against you? An intrusion detection system (IDS) can help, but an IDS has several drawbacks: it typically cannot handle high bandwidth, it relies on pattern-matching intelligence, it cannot (for the most part) watch encrypted SSL streams, and it is expensive (even the open-source snort requires a team to maintain and monitor events). The answer, in this case, is to turn to your logfiles. You enabled robust logging for your web server, right?
Common Signatures Logfiles are a security device. They are reactionary, meaning that if you see an attack signature in your file, you know you've already been attacked. If the attack compromised the server, web logs will be the first place to go for re-creating the event. Logs also help administrators and programmers track down bugs or bad pages on a web site—necessary to maintain a stable web server. With this in mind, you should have a policy for turning on the web server's logging, collecting the logfiles, reviewing the logfiles, and archiving the logfiles.
The following table lists several items to look for when performing a log review. Many of these checks can be automated with simple tools such as grep.
| Excessive 404 response codes | A 404 in your logfile usually means one of three things: a typo or error is in a page on the site, a user mistyped a URI, or a malicious user is looking for “goodies.” If you see several requests from an IP address that resulted in a string of 404 errors, check the rest of your logs for that IP address. You may find a successful request (200 response) somewhere else that indicates malicious activity. |
| Unused file extensions | This is a subset of the excessive 404s, but it's a good indicator of an automated tool. If your site uses only *.jsp files, requests for files with *.asp would be out of place. |
| Excessive 500 response codes | Any server error should be checked. This might mean the application has errors, or a malicious user is trying to submit invalid data to the server. |
| Sensitive filenames | Search the logs for requests that contain passwd, cmd.exe, boot.ini, ipconfig, or other system filenames and commands. IDSs often key off of these values. |
| Examine parameters | Web server attacks also hide within requests that return a 200 response. Make sure that your web server logs the parameters passed to the URI. |
| Directory traversal | Search for attacks that try to break directories, such as ..., .., or %2e%2e. |
| Long strings | Search for long strings (more than 100 characters) submitted as a parameter. For example, a username with the letter A repeated 200 times probably indicates someone's attempt to break the application. |
| Unix shell characters | Check for characters that have special meaning in shells or SQL. Common characters are ' ! | < > & * ; |
| Strange User-Agent headers | Check for strings that do not correspond to the most common version of Internet Explorer, Mozilla, Opera, or Safari. For example, nikto produces this User-Agent header: |
Bear in mind that IIS records the URL in its final, parsed format. For example, the Unicode directory traversal attack appears as /scripts/..Á..Á..Ácmd.exe?/c+dir, whereas an Apache logfile captures the raw request, /scripts/..%c0%af..%c0%af..%c0%afcmd.exe?/c+dir?. For IIS logging, make sure to turn on the options for recording the uri-stem and uri-query.
|
Stealth
Stealth is a vulnerability scanning tool created by Felipe Moniz. It uses the Windows GUI and therefore doesn’t have the cross-platform capability of nikto. Stealth’s strength lies in its number of checks and, like nikto, ease of updating its database. More than 13,000 checks currently populate the Stealth database, although only about 5000 of them are unique. These checks range from URLs that break obscure devices with embedded web servers to the most current IIS vulnerabilities.
Implementation
Figure 7-1 shows the interface for scanning a single IP address. By default, Stealth uses the “normal” Scan Rule, which contains roughly 6500 checks. This screen is accessed by clicking the Scanner button in the Stealth application window.
Figure 7-1: Default Stealth scan against a target
| Tip | Even though Stealth provides an option to change the target port from the default of 80, it does not negotiate SSL connections. Setting the target port to 443 will not suffice. |
Stealth can also scan a range of web servers. However, as shown in Figure 7-2, the range must be a list of sequential IP addresses. It is not possible to load a custom list of target IP addresses. This slows down scans that target a network, because Stealth must first identify a web server before scanning it. When servers are distributed across networks, this is even slower.
Figure 7-2: Scanning a range of IP addresses with Stealth
One more note about scanning a range: Any time Stealth encounters an error, it pops up a message box that requires manual intervention to close. In short, Stealth is not the best tool for scanning multiple servers at once.
The IDS Test button works much like nikto’s IDS evasion techniques. Stealth offers 13 different evasion techniques. Select which techniques you want to use, and then choose CGI Setup | Use IDS Evasion. Figure 7-3 illustrates how to enable IDS evasion.
Figure 7-3: Enabling IDS evasion
When Stealth finishes a scan, it prompts the user to save the report. A Stealth report is an HTML file that lists any potential vulnerability it discovered. This is a quick, straightforward tool that assumes you want to run 6500 checks against a web server every time.
Creating New Rules
Rule construction for Stealth is simple. You specify the URL, the request method, and the expected HTTP return code. For example, to look for a backup index.html file, you would create a file with these contents:
#INF Backup index.html file #GET /index.html.bak #200
The #GET method could also be #HEAD or #POST. The #200 return code can be any HTTP response. Stealth does not use custom arrays, so files within a set of directories must be listed individually. Both #GET and #200 are assumed by default and can be omitted. Thus, the basic URL checking of Stealth is not as robust as whisker. Stealth does try to simplify the vulnerability development process with its Stealth Exploit Development Tool.
The Exploit Development Tool is a GUI utility that prompts you for each of the possible fields that can be created for a vulnerability check. Figure 7-4 shows the configuration settings for our simple index.html.bak check.
Figure 7-4: Configuring a vulnerability check
The Options tab is where you specify a string that would indicate the check returned a false positive or specify a User-Agent. Some web applications rely on the User-Agent header for determining whether a browser can access the site. Some browsers do not support JavaScript, ActiveX, or Java that would cause the application to disallow access. Figure 7-5 shows these options.
Figure 7-5: Options for a vulnerability check
Another cool Stealth technique is the buffer overflow test. A buffer overflow attack can be crafted against any URL in a web application that has a parameter list. The Stealth rule for a buffer overflow has four components:
-
bofgen The URL, encased in double-quotation marks.
-
bofstr A placeholder for the buffer overflow string. The bofstr value is replaced by the actual attack.
-
bytes The number of times to repeat the buffer overflow character.
-
chars The buffer overflow character.
For example, here’s the rule to check for a buffer overflow condition in a web application’s login page:
#INF Login.asp buffer overflow check bofgen=/login.asp?user=%bofstr&passwd=none","bytes=999","chars=A"
In the HTTP request that Stealth sends, the %bofstr string is replaced by 999 As.
Once any exploit is created, you must still instruct Stealth to use it. If you place the file in the Db subdirectory of the Stealth installation directory, Stealth will find the exploit and load it. To check this manually, or to create a new exploit, click the Database button in the Stealth application window and select the Stealth User’s Exploits tab. Checkmark the exploit to enable it. Figure 7-6 shows an example exploit called Sourcedis that is not currently enabled.
Figure 7-6: Adding custom checks to Stealth
Pitfalls to Avoid
As mentioned, Stealth’s ability to scan a range of web servers automatically is severely limited. Stealth occasionally generates DNS errors, which usually happens when scanning a server with virtual hosts or when it scans a server with multiple IP addresses (as is the case for many large, load-balanced sites). A DNS error is innocuous, but it requires that you close the pop-up message box Stealth generates.
The majority of Stealth’s checks rely on the HTTP return code from the server. This is useful when you’re checking for the existence of a vulnerable script, but it does not necessarily indicate that a script is vulnerable. For example, many of the viewcode.asp vulnerabilities in IIS sample files have been fixed in recent updates, but Stealth merely checks for their presence and often produces false positives. Even though Stealth can parse the output of a check for a specific string, few of the checks seem to do so. Relying on the HTTP return code doesn’t mean that Stealth will miss vulnerabilities, but it does mean that it will produce a large number of false positives.
A GUI-based tool does not play well with others. It is difficult to create a script that generates a list of web servers or systems with port 80 open, input that list to Stealth, and then perform some file parsing on Stealth’s output. A command-line tool, on the other hand, doesn’t mind being wrapped in FOR loops and having data piped into it from other programs or sending its output to your favorite parsing tool. Remember the ease with which we manipulated the output from whisker with the tee and grep commands?
Finally, Stealth cannot handle SSL connections. This is a simple drawback to overcome. As we’ll show in the next section in this chapter, an SSL proxy easily solves this problem.
|
| < Day Day Up > |
|
EAN: 2147483647
Pages: 189