Detecting Web Attacks

 < Day Day Up > 

Detecting a web attack can be as simple as reviewing web server log files for tens, maybe hundreds of attempts to access files and directories that might or might not exist. Better yet, using log files in combination with a full-blown network IDS, such as Cisco IDS sensor, to detect attacks gives an administrator extensive detail. This section examines some examples of reviewing log files and a Cisco IDS sensor while attempting to penetrate and test a web server.

To start, perform a basic directory traversal attack and check for symptoms first in the web server logs and then in the IDS sensor. Next, execute a classic automated vulnerability scanner (Whisker) against the web server, and look for symptoms it exhibits. Figure 7-31 displays the network used in this test.

Figure 7-31. Network Map


The Cisco PIX Firewall is statically mapping port 80 to the internal IIS 5.0 web server's port 80. All other ports on the PIX Firewall have been disabled, similar to a normal run-of-the-mill production system.

The Windows 2000 IIS server is configured with no service packs and default settings. This is less common on the Internet these days as larger sites upgrade to IIS 6.0 and apply every patch possible to the system. However, there is still a significant number of IIS 5.0 on the Internet and even more remain in use hosting company intranets. By default, IIS creates new log files once per day and saves them in the C:\WINNT\System32\LogFiles\W3SVC1 folder. You can adjust the location and file creation settings within the IIS Service Manager if needed, as shown in Figure 7-32.

Figure 7-32. IIS Logging Properties


The IIS log format is a standard text file that records source IP address, destination IP address, the basic request, and finally the result. However, several other items can be recorded if desired, but as the quantity of data recorded increases, so too does the disk space required to store the logs.

Detecting Directory Traversal

Directory traversal is a common attack against Windows IIS 4.0 and 5.0 web servers that allows hackers to execute or touch files outside of the designated web server folders. For example, directory traversal can allow a hacker to execute the cmd.exe /c command to retrieve directory information or run just about any executable program available on your web server. Consider a basic attack to see what comes up on the log files.

From the web browser, enter the following command to test the vulnerability of the web server and to see if the server will return information you actually should not see:

http://172.16.0.2/scripts/..%255c../winnt/system32/cmd.exe?/c+dir+c:\

Figure 7-33 shows that the directory listing is successfully returned.

Figure 7-33. Directory Traversal Results


Now look into the Windows IIS 5.0 log file, which shows the following information:

2005-02-09 22:11:05 172.16.0.13 - 192.168.200.21 80 GET /scripts/..%5c../winnt/ system32 /cmd.exe /c+dir+c:\ 200

This clearly shows a nonstandard HTTP GET request attempting to point to cmd.exe. If you are continuously monitoring your production log files, you will commonly see these traversal type entries in them even if you are no longer vulnerable. Hackers, script kiddies, and even some viruses attempt directory traversal on websites to see if there is an easy way in. If you see a lot from a single IP address, however, you should take some blocking action or contact the ISP before these attack sources discover some other vulnerability with your site.

The Cisco IDS 4215 sensor detects directory traversals quite accurately. Figure 7-34 displays what the Realtime Dashboard shows from the single traversal attempt made.

Figure 7-34. Directory Traversal IDS Detected


As you can see, six different events were triggered from the sensor, with each event complaining about a different part of the traversal attack. You can view more detail than just the triggered event in IDS Event Viewer (IEV) by right-clicking the event and selecting Show Context. IEV displays the Decoded Alarm Context, showing the exact syntax sent to the web server that triggered the alarm. (See Figure 7-35.) This is useful when tracing back though the alarms trying to piece together what the hacker was actually sending the server and perhaps even what he did to the server.

Figure 7-35. IDS Decoded Alarm Context


Detecting Whisker

This next detection is with an old but popular CGI vulnerability scanner called Whisker. This tool, like dozens of other automated testing tools, typically executes every possible attack against a web server in the arsenal of a hacker, resulting in tens if not hundreds or even thousands of alarms and events triggered. The rest of this section shows what a standard Whisker attack might look like.

To launch Whisker from the Perl script, you need to have an interpreter installed, such as ActivePerl from http://www.ActiveState.com. Next, run Whisker against the target host 172.16.0.2 with the following command:

C:\whisker>whisker.pl -h

Example 7-16 displays the Whisker output against a basic IIS 5.0 install on a Windows 2000 server.

Example 7-16. Whisker Attack Results
C:\whisker>whisker.pl -h 172.16.0.2 [ Whisker not officially installed; reading from current directory ] ---------------------------------------------------------------------------- Whisker 2.0 beginning test against http://172.16.0.2 ---------------------------------------------------------------------------- Title: Notice Whisker scans for CGIs by checking to see if the server says a particular URL exists. However, just because a URL exists does not necessarily mean it is vulnerable/exploitable--the vulnerability might be limited to only a certain version of the CGI, and the server might not be using the vulnerable version. There is also the case where many scripts use the same generic CGI name (like count.cgi); in this case, the exact CGI being used may not be the same one that contains the vulnerability. Thus, the actual vulnerability of the CGI must be verified in order to get a true assessment of risk. Whisker only helps in pointing out the problem areas. The next step after scanning with whisker is to review each found CGI by reviewing the reference URLs or searching for the CGI name on SecurityFocus.com or Google.com. ---------------------------------------------------------------------------- Id: 100 Informational: the server returned the following banner:         Microsoft-IIS/5.0 ---------------------------------------------------------------------------- Whisker is currently crawling the website; please be patient. ---------------------------------------------------------------------------- Whisker is done crawling the website. ---------------------------------------------------------------------------- Id: 750 Found URL: /_vti_inf.html See references for specific information on this vulnerability. ---------------------------------------------------------------------------- Id: 753 Found URL: /_vti_bin/shtml.dll See references for specific information on this vulnerability. ---------------------------------------------------------------------------- Id: 755 Found URL: /_vti_bin/shtml.exe See references for specific information on this vulnerability. ---------------------------------------------------------------------------- Id: 778 Found URL: /_vti_bin/_vti_aut/author.dll See references for specific information on this vulnerability. ---------------------------------------------------------------------------- Id: 779 Found URL: /_vti_bin/_vti_aut/author.exe See references for specific information on this vulnerability. ---------------------------------------------------------------------------- Whisker scan completed in less than 1 minute C:\whisker>

As you can see, Whisker took only a minute to find five possible vulnerabilities against the IIS computer. Using a newer library of tools might result in the discovery of even more vulnerabilities. Example 7-17 displays some of the 500+ entries that Whisker generated in the IIS Log file.

Example 7-17. Whisker Output
2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /Default.asp - 200 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /CLTCmODBUzKorDA - 404 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /Default.asp - 200 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /global.asa |- |ASP_0220|Requests_for_GLOBAL.ASA_Not_Allowed 500 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /Default.asp - 200 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /carbo.dll - 500 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /prd.I/pgen/ - 404 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /cgi-local/ - 404 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /htbin/ - 404 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /cgi/ - 404 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /cgis/ - 404 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /cgi-win/ - 404 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /bin/ - 404 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /_vti_inf.html - 200           whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /_vti_bin/_vti_aut/            author.dll - 200 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /_private/ - 403 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /_vti_bin/ - 403 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /_vti_pvt/ - 404 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /_vti_log/ - 403 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /_vti_txt/ - 404 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /_vti_cnf/ - 404 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /_private/ - 403 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /_vti_bin/ - 403 whisker/2.0 2005-03-23 22:22:27 172.16.0.13 - 192.168.200.21 80 GET /_vti_log/ - 403 whisker/2.0

As you can see from this log file, Whisker is probing for web pages and other possible vulnerabilities. The entries with a code of 200 (highlighted in the preceding output) relate to a successful page found and can be seen in the Whisker vulnerability report. Another thing worth noting is that the name Whisker is left within the log file, making it easy to spot activity from anyone using this tool to check out the website.

Next, look at the Cisco IEV Realtime Dashboard in Figure 7-36 to see how the IDS sensor reacts when this scanner is used.

Figure 7-36. Whisker Alarms Detected by IDS


As you can see, the Cisco IDS does an excellent job of detecting attacks against our web server. If you look closely, you see that Whisker also launched attacks based on Apache vulnerabilities against the IIS web server. Although these do not work against an IIS system, IDS does not discriminate and records the alarm event anyway. An unconfigured, automated tool such as Whisker basically just throws everything it has at a server, causing a lot of log and alarm noise before it finishes. This makes it relatively easy to detect when it is used against your network.

Note

Whisker has been around for quite some time. A newer tool to keep an eye out for is called Nikto. It, too, runs as a Perl script and can be used as a vulnerability scanner against web servers.


As you can see, detecting is not too difficult because almost everything is logged within IIS log files. However, it takes effort and time to view your log files for errors and possible attacks being initiated against your servers. Investment in an IDS to assist in recognizing attacks can be invaluable if you have heavily accessed web-based systems or numerous web servers. Remember that IDS does not usually detect Day Zero alarms, so a periodic review of the standard log file should remain part of your detection strategy.

     < Day Day Up > 


    Penetration Testing and Network Defense
    Penetration Testing and Network Defense
    ISBN: 1587052083
    EAN: 2147483647
    Year: 2005
    Pages: 209

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net