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
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
Stealth can also scan a range of web servers. However, 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.
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.
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.
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.
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.
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.
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.
This post first appeared on Network Security | Cryptographic Building B, please read the originial post: here
