How to Detect Whether You re Under Attack

[Previous] [Next]

The simplest way to detect whether you're under attack is to use audit logs and an intrusion detection tool.

Enabling Audit Logs

It's paramount that you enable logging in Windows 2000, IIS, and Microsoft SQL Server, as described in the following sections.

Auditing in Windows 2000

In Windows 2000, you can set auditing policy on a local machine if it's not running in a domain. If the machine is running in a domain, you can make the policy global. Take the following steps:

1. In the Security Policy tool, navigate to Local Policies, Audit Policy.
2. Set the policy you want by using the settings listed in Table 12-4.

Table 12-4. Windows 2000 audit settings.

Policy	Setting
Audit account logon events	Success, Failure
Audit account management	Success, Failure
Audit directory service access	Failure
Audit logon events	Success, Failure
Audit object access	Failure
Audit policy change	Success, Failure
Audit privilege use	Failure
Audit process tracking	No auditing
Audit system events	No auditing

Auditing in IIS

You can configure audit logging in IIS by following these steps:

1. In the IIS Microsoft Management Console (MMC) snap-in, right-click the Web site in question (such as the Default Web Site node) and choose Properties from the context menu.
2. Be sure that Enable Logging is selected and that the active log format is W3C Extended Log File Format.
3. Click the Properties button next to the Active Log Format drop-down list box.
4. Select a new log time period. Select the Use Local Time For Naming And Rollover option if you don't want to use the default UTC (or GMT) timing.
5. Click the Extended Properties tab.
6. Be sure that the following are enabled:

• Client IP Address
• User Name
• Method
• URI Stem
• URI Query
• Protocol Status
• Win32 Status
• Bytes Sent (optional)
• Bytes Received
• Time Taken (optional)
• User Agent

7. Click OK twice.

Auditing in SQL Server

You can configure security logging in SQL Server 7 as follows:

1. In the SQL Server Enterprise Manager, choose Microsoft SQL Servers, SQL Server Group.
2. Open the server in question.
3. Right-click the server, and choose Properties from the context menu.
4. Click on the Security tab.
5. Be sure that Audit Level: All is selected, and then click OK.

Analyzing IIS logs

The first logs you should look at if an attack is Web-based are the IIS logs. People often try to perform attacks using scripts for old vulnerabilities that have been fixed. Examples of such attacks are listed in Table 12-5.

Table 12-5. Common attacks on IIS based on vulnerabilities that have been fixed.

Attack	Comments
"::$DATA" bug	Allows the attacker to view the source code of ASP files.
"." bug	Same as above, but the file being accessed has a "." at the end.
".htr" buffer overflow	A specially crafted request to an .htr file executes arbitrary code in the security context of the Web server.
RDS exploit	A specially crafted Remote Data Services request executes arbitrary code at the server.
Samples	Some samples contain code for viewing source code. Never install samples on a production server.

You might be under attack if you see any lines in your IIS logs that look like those listed in Table 12-6.

Table 12-6. Examples of suspicious activity recorded in the IIS logs.

Attack	Log File Example(s)
"::$DATA" bug	15:59:09 218.216.157.240 - W3SVC1 207.46.171.196 80 GET /default.asp::$DATA
"." bug	15:59:09 218.216.157.240 - W3SVC1 207.46.171.196 80 GET /default.asp. (Note the "." at the end of default.asp.)
".htr" buffer overflow	15:59:09 218.216.157.240 - W3SVC1 207.46.171.196 80 GET / iisadmpwd/aexp.htr (You should consider access to any file ending in .htr suspicious.)
RDS exploit	16:55:54 228.153. 98.189 - W3SVC1 207.46.171.196 80 POST /msadc/msadcs.dll hr=800a1004,CSoapStub::HttpExtensionProc, 200 271 679 18:48:21 216.118.25.150 - W3SVC1 207.46.171.196 80 GET /msadc/msadcs.dll - 404 3395 387 15:33:57 219.213.116.121 - W3SVC1 207.46.171.196 80 GET /msadc/msadcs.dll/VbBusObj.VbBusObjCls.GetRecordset+HTTP/1.1 - 401 3417 460 15:35:45 219.123.163.22 - W3SVC1 207.46.171.196 80 GET /msadc/msadcs.dll/AdvancedDataFactory.Query+HTTP/1.1 - 401 3417 452 (All of the above are valid RDS entries and should all be treated as suspicious.)
Samples	15:59:09 218.216.157.240 - W3SVC1 207.46.171.196 80 GET /IISSamples

You can use the following Perl code to look for these attempted attacks on your server. Save this file as Attacks.pl; usage is Attacks.pl logfile(s). You can use wildcards in the names of log files.

 $SUMMARY_ONLY = 0; # Set to 0 to display all offending lines. %hits=(RDS => 0, DOLLAR_DATA => 0, DOT => 0, SAMPLES => 0, SHOWCODE => 0, HTR => 0, DOT_DOT => 0, SAM_ACCESS => 0, INDEX => 0, BOOT_INI => 0); foreach (<$ARGV[0]>) { print "Opening log $_\n"; warn unless open FILEHANDLE, "<" . $_; # Read each line. while (<FILEHANDLE>) { print "$lines lines processed.\r" if ++$lines % 500 == 0; if (/msadcs/i) { print "[RDS EXPLOIT] $_\n" unless $SUMMARY_ONLY; $hits{RDS}++; } elsif (/::\$DATA/i) { print "[::\$DATA EXPLOIT] $_\n" unless $SUMMARY_ONLY; $hits{DOLLAR_DATA}++; } elsif (/.*GET \/.*\.asp\./i) { print "['.' EXPLOIT] $_\n" unless $SUMMARY_ONLY; $hits{DOT}++; } elsif (/sam\._/i) { print "[ACCESSING SAM] $_\n" unless $SUMMARY_ONLY; $hits{SAM_ACCESS}++; } elsif (/\.ida|\.idq|\.htw/i) { print "[INDEX SERVER] $_\n" unless $SUMMARY_ONLY; $hits{INDEX}++; } elsif (/boot\.ini/i) { print "[ACCESSING BOOT FILE] $_\n" unless $SUMMARY_ONLY; $hits{BOOT_INI}++; } elsif (/iissamples/i) { print "[SAMPLES] $_\n" unless $SUMMARY_ONLY; $hits{SAMPLES}++; } elsif (/showcode\.asp/i) { print "[SHOWCODE] $_\n" unless $SUMMARY_ONLY; $hits{SHOWCODE}++; } elsif (/htr/i) { print "[HTR EXPLOIT] $_\n" unless $SUMMARY_ONLY; $hits{HTR}++; } elsif (/\.\./) { print "[\.\. EXPLOIT] $_\n" unless $SUMMARY_ONLY; $hits{DOT_DOT}++; } } close FILEHANDLE; } # Print the summary results. print "\n\n--------------\nAttack Summary\n--------------\n"; print "$lines lines processed\n\n"; @keys = sort {int $hits{$b} <=> int $hits{$a} } keys %hits; foreach $key (@keys) { $value = $hits{$key}; $percent = ($value / $lines) * 100; printf "%12s = %7d (%0.4f%%) attempts\n",$key,$value,$percent; } 

You should run this script, available on the companion CD, regularly to determine whether you're being attacked or probed, but don't be too alarmed by occasional activity. To quote Chapman and Zwicky in their excellent book Building Internet Firewalls, "Once is an accident; twice is a coincidence; three times is enemy action."

Buffer Overflows

You might have noticed that we referred to the ".htr" bug as a buffer overflow bug. A buffer overflow is simply a coding problem whereby a large amount of data is copied into a small space. Look at the following C/C++ code:

 #include "stdio.h" #include "string.h" void CopyData(char *str) { char buff[64]; strcpy(buff,str); } void main(int argc, char* argv[]) { char cLargeString[80]; memset(cLargeString,'*',80); cLargeString[79] = 0; CopyData(cLargeString); puts("Data copied"); } 

As you can see, when the CopyData function is called, it tries to copy at least 80 bytes into a 64-byte space. In the best case, an access violation occurs and the operating system shuts down the application. In fact, that's what this code does. In the worst case, the attacker might be able to execute arbitrary code. Here's how.

When one function calls another, it places (the correct term is pushes) the address of the next instruction onto the stack. When the function returns, it " pops " the address off the stack and continues execution at the new address. Look at the buff variable in CopyData. If you know C or C++, you know that this is a stack-based variable. In other words, buff is right next to the return address for this function on the stack. Also on the stack is the only argument to CopyData, a pointer to a series of characters: char *str. In memory, the stack looks like that shown in Figure 12-5.

Figure 12-5. A healthy stack.

You'll notice another unit of data called the SFP, or stack frame pointer. We won't cover this, but you must take its size into consideration in a real attack.

The secret to an attack is the content of the 80-byte block, which is specially crafted so that it overwrites the return address to point to the contents of the 64-byte buffer. The attacker places executable assembly language instructions in the buffer. After a successful attack, the stack looks like that shown in Figure 12-6.

Figure 12-6. A stack after an attack.

This is often referred to as "smashing the stack." The preeminent paper on the subject is called "Smashing the Stack for Fun and Profit" by AlephOne in issue 49 of Phrack magazine (www.phrack.com). Another great article is "The Tao of Windows Buffer Overflow" by DilDog, available at www.cultdeadcow.com/cDc_files/cDc-351.

Analyzing Windows 2000 logs

You should also monitor the Windows 2000 logs; especially suspicious are the security events described in Table 12-7.

Table 12-7. Security event log entries that you should monitor.

Security Event ID	Comments
612	The audit policy has changed, perhaps maliciously.
640	A change has been made to the SAM database. (Was it you?)
531	An attempt was made to log on using a disabled account. (Why would anyone want to do this?)
539	A logon attempt was made and rejected because the account was locked out. (Why would anyone want to do this?)
529	An attempt was made to log on using an unknown user account or using a valid user account but with an invalid password. (An unexpected increase in the number of these audits might indicate an attempt to guess passwords.)
517	The audit log has been cleared. (Is an attacker attempting to cover her tracks?)
624	A user account has been created. (Was it created by a trusted person?)
628	A user account's password has been set. (Was this done by a trusted person?)

Note that you can filter the event log in Windows 2000. To monitor for 529 events, take these steps:

1. In the Event Viewer, right-click the Security log and choose New Log View from the context menu.
2. Select the new log view, press F2, and type Security - 529.
3. Right-click the new log view, and choose Properties from the context menu.
4. Click the Filter tab.
5. Set the following fields:

• Event Source: Security
• Category: Logon/Logoff
• Event ID: 529

6. Click OK.

You should set up a filter for any other events that are of interest to you.

If you deal with many computers, you might want to use the Dump Event Log (or Dumpel) tool that comes with the Microsoft Windows 2000 Server Resource Kit. This command line tool dumps an event log for a local or remote system into a tab-separated or comma-separated text file.

You can also use the tool to filter certain event types. For example, the following will dump security events 529 and 531 from the security event log on a server called \\major into a file called seclog.txt:

 Dumpel -f seclog.txt -s \\major -l security -m security -e 529 531 

You can then easily parse this file to look for suspicious activity.

Analyzing SQL Server logs

SQL Server has two log types, the Windows 2000 event log and its own text files, called errorlog.nnn, in the \MSSQL7\LOG directory. The event log entries are always the same regardless of whether the logon was validated; only the text varies. The entries are in the Application log. Source is MSSQLServer, Category is Logon, and Event ID is 17055. This makes them a little difficult to analyze. However, the text files are quite easy to analyze. They look something like this:

 1999-12-17 12:48:16.16 logon Login succeeded for user 'DOM\Squirt'. Connection: Trusted. 1999-12-17 12:49:09.64 logon Login failed for user 'sa'. 1999-12-17 12:55:00.34 logon Login succeeded for user 'sa'. Connection: Non-Trusted. 

The first entry shows a valid trusted connection from a user called Squirt on the DOM domain. Connection: Trusted means that the account was authenticated using Windows authentication. Connection: Non-Trusted means that the account used the built-in SQL Server authentication.

You can quickly parse these files by entering the following at the command line in the SQL Server log file directory:

 findstr /i "login.failed" err*.* 

Note the period between login and failed. Without it, findstr would look for the words login or failed in the files.

Using Performance Monitor to detect an attack

You should also consider monitoring resource load—most notably, CPU load—using Performance Monitor. If the system peaks at 100 percent CPU use, the computer might be under a DoS attack. Of course, the server might just be very busy!

Intrusion Detection Tools

Intrusion detection tools are programs that look for attack "fingerprints" and log the results in an audit file or notify an administrator. Thankfully, these tools are becoming commonplace in many organizations. A good analysis of these tools is available at www.networkcomputing.com/1023/1023f1.html.

There are many tools to choose from, including the following:

• RealSecure from Internet Security Systems (www.iss.net)
• BlackICE from Network Ice (www.networkice.com)
• Intruder Alert and NetProwler from Axent Technologies (www.axent.com)

Figure 12-7 shows a computer monitored by BlackICE coming under serious attack.

Figure 12-7. The BlackICE intrusion detection tool showing a series of attacks.

The seven oldest events are probes, not attacks, although the Telnet abuse might be one or the other. If the probes were just Telneting to port 80 to find out the Web server version, it's part of the information-gathering exercise; however, if they were typing in some illegal characters to, say, an RPC port to attempt to get the RPC service to crash, it might be an attack.

The TCP OS Fingerprint event is interesting. Operating systems can behave differently when they receive certain types of specially crafted IP packets. By sending these packets to a server and evaluating the response, a program can determine with some accuracy which operating system is running on the remote computer. The most common tool for performing this is called NMAP. For more details about OS fingerprinting and NMAP, go to phrack.infonexus.com/search.phtml?view&article=p54-9.

The top two events, SynDrop and Fragment overlap, are attacks, both of which were mentioned in "Some Common Attacks."

Many tools also have excellent documentation explaining each attack in detail. Figure 12-8 shows an example of the BlackICE online documentation for a SYN flood attack.

It's quite easy to see whether you're under a SYN flood attack without an intrusion detection tool by using the netstat utility included with Windows 2000. This tool provides statistics about the TCP/IP protocol suite, but more importantly, it can display the status of all TCP/IP connections to and from your computer and the state of each connection.

Figure 12-8. BlackICE's online documentation for a SYN flood attack.

For example, if you enter netstat-n-p tcp at the command line, you'll see output like this if you're under attack:

 Proto Local Address Foreign Address State TCP 127.0.0.1:1030 127.0.0.1:1032 ESTABLISHED TCP 127.0.0.1:1032 127.0.0.1:1030 ESTABLISHED TCP 10.57.8.190:21 10.57.14.154:1256 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1257 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1258 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1259 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1260 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1261 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1262 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1263 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1264 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1265 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1266 SYN_RECEIVED TCP 10.57.8.190:4801 10.57.14.221:139 TIME_WAIT 

Note the number of connections in the SYN_RECEIVED state. Be aware that the foreign address is probably fake.

Another issue to be aware of is the coordinated or DDoS attack. Hosts around the world can coordinate to mount a massive attack on a single host. For more information, go to www.cert.org/incident_notes/IN-99-07.html.

Integrity tools

Another tool that you should seriously consider using is an integrity tool. Integrity tools check that resources such as files, access controls lists, and Registry settings haven't been tampered with. If they have, the tools can perform actions such as e-mailing administrative staff.

Two such tools we've used are

• Tripwire from Tripwire Security Systems Inc. (www.tripwiresecurity.com). Tripwire is well known in the UNIX world and has been ported to Windows NT and Windows 2000. At the Tripwire Web site, be sure to get a copy of the excellent "Common Security Exploits and Vulnerability Matrix" poster, which is a superb reference.
• Intact from Pedestal Software (www.pedestalsoftware.com). Intact was designed for Windows NT and Windows 2000. It not only monitors files, Registry entries, and ACLs, but it also monitors user and group account manipulation.

Here's some sample output from Intact 2.0 indicating that a file has been changed. (The file size has grown.) Was the change benign or malicious? Has a hacker left some new wording on your home page? You should check whether changes such as this were made by your Web development team!

 INFO: MSG: CONFIG: Intact Intelligence Version 2.0 INFO: MSG: CONFIG: Current User EXAIR\WebAdmin INFO: MSG: CONFIG: INTACT CHECK START 09/03/99 22:33:12 CHANGED: FILE: c:\Web\Default.html Last write time changed: was: September 02, 1999 13:53:21 is: September 02, 1999 23:12:54 Size has changed was: 1022 is: 1431 DIGEST1 is different was: (MD5: 27 00 70 A8 DC C4 C6 D1 AE F0 08 92 C8 3B 39 C2) is: (MD5: 02 A9 25 77 87 E3 1E FD 0F 39 EA 6E 17 36 11 9D) DIGEST2 is different was: (SHA1: 38 DE FA 26 78 7E 66 EB 88 D7 6B A7 21 46 A6 B1 A1 2F 0D 63) is: (SHA1: 71 FD 44 E8 FA 1A BC C8 81 E4 EE 01 8A 11 00 00 17 11 2B FE)