Hacking Exposed Windows Server 2003: Windows Security Secrets & Solutions

So far in our assault on Windows Server 2003, we've identified targets and running services, and we have connected to certain services to enumerate system data. Now comes the moment you've all been waiting for: the break-in. As discussed in Chapter 2, the primary goal of remote Windows Server 2003 system penetration is to authenticate to the remote host. We can do this by

▼ Guessing username/password combinations

■ Eavesdropping on or subverting the authentication process

■ Exploiting a vulnerable network service or client ▲ Gaining physical access to the system

This chapter will discuss the first three items on this list, while the last one will be dis­cussed in Part IV of this book.

, SQL Server, and Terminal Server will be discussed individually in Chapters 10,11, and 12, respectively, due to the vast attention malicious hackers have historically paid to those services.

As we saw in Chapter 2, the core of the NT family authentication system includes the LAN Manager (LM) and Windows NT LAN Manager (NTLM) protocols (including NTLM version 2). These protocols were designed primarily for a protected internal envi­ronment. With Windows 2000, Microsoft adopted the widely used standard Kerberos version 5 protocol as an alternative to LM and NTLM in an attempt to broaden the scope of its authentication paradigm, and also in part to blunt longstanding criticism of security weaknesses in the proprietary LM/NTLM suite. All of these protocols are available by default in Windows Server 2003 (Kerberos is used only in certain circumstances to au­thenticate to domain controllers), and little has been changed to eliminate the longstand­ing weaknesses in LM/NTLM. All of these protocols are used more or less transparently by standard NT family clients, so the details of how they work is often irrelevant to at­tacks like password guessing, in most cases anyway. Furthermore, as we will see in this chapter, Microsoft has replicated known security vulnerabilities in the public Kerberos v5 standard that put it roughly on par with the LM/NTLM protocols in terms of security. This chapter is divided into the following sections:

▼ Guessing passwords

■ Eavesdropping on authentication

■ Subverting authentication via rogue server or man-in-the-middle (MITM) attacks ▲ Attacking vulnerabilities in Windows-specific services

GUESSING PASSWORDS

As unglamorous as it sounds, probably the most effective method for gaining access to Windows systems is good ol' fashioned password guessing. This section will discuss the inelegant but highly effective approach to Windows Server 2003 system penetration.

Before we begin discussing the various tools and techniques for password guess­ing, let's first review a few salient points to consider before embarking on an extended campaign:

▼ Closing existing null sessions to target

■ Reviewing enumeration output

■ Avoiding account lockout

▲ The importance of the administrator

Close Existing Null Sessions to Target

Before beginning password guessing against systems that have been enumerated, a little housekeeping is in order. Since the NT family does not support logging on with multiple credentials simultaneously, we must log off of any existing null sessions to the target by using the net use /delete command (or /d for short; the /y switch forces the connec­tions closed without prompting):

C:\>net use * /d /y

You have these remote connections:

\\victim.com\ipc$ Continuing will cancel the connections.

The command completed successfully.

And, ofcourse, ifyouhavenullsessions opento multiple machines, youcanclosespecific null connections by explicitly noting them in the request. Below, we close a null session with \\victim:

C:\>net use \\victim\ipc$ /d /y

Review Enumeration Results

The efficiency of password guessing is greatly increased by information gathered using the enumeration techniques discussed in Chapter 4. Assuming that user account names and features can be obtained by these techniques, they should be reviewed with an eye toward identifying the following information extracted over null sessions by tools such as enum, nete, userdump/userinfo, and DumpSec (see Chapter 4). This information can be used in manual password guessing attacks, or it can be salted liberally in username lists and password dictionaries fed into automated password-guessing tools.

Lab or Test Accounts How many of these exist in your environment? How many of these accounts are in the local Administrators group? Care to guess what the password for such accounts might be? That's right—"test" or "NULL."

User Accounts with Juicy Info in the Comment Field No lie, we've seen passwords written here in plaintext, ripe for the plucking via enumeration. Broad hints to the password are also found in the Comments field to aid those hapless users who just can't seem to re­member those darn passwords.

Members of the Administrators or Domain Admins Groups These accounts are often targeted because of their all-encompassing power over local systems or domains. Also, the local Administrator account cannot be locked out using default tools from Microsoft and makes a ripe target for perpetual password guessing.

Privileged Backup Application Service Accounts Many commercial backup software appli­cations create user accounts that have a high degree of privilege on a system, or that at least can read almost all of the files to provide a comprehensive backup of the system. We've listed some common account names in Table 5-1 a little later in the chapter.

Shared Group Accounts Organizations large and small have a propensity to reuse account credentials that grant access to a high percentage of the systems in a given environment. Account names like "backup" or "admin" are examples. Passwords for these accounts are rarely difficult to guess.

User Accounts that Haven't Changed Their Passwords Recently This is typically a sign of poor account maintenance practices on the part of the user and system administrator, indicating a potentially easy mark. These accounts may also use default passwords specified at ac­count creation time that are easily guessed. (For example, the use of the organization name or "welcome" for this initial password value is rampant.)

User Accounts that Haven't Logged on Recently Once again, infrequently used accounts are signs of neglectful practices such as infrequently monitored password strength.

Ivoid Account Lockout

Hackers and authorized penetration testers alike will want to avoid account lockout when engaging in password guessing. Lockout disables the account and makes it un­available for further attacks for the duration of the lockout period specified by a system administrator. (Note that a locked out account is different from a disabled account, which is unavailable until enabled by an administrator.)

Plus, if auditing has been enabled, lockout shows up in the logs and will typically alert administrators and users that someone is messing with their accounts. Furthermore, if the machine is running a host-based intrusion detection application, chances are that the num­ber of failed logins may trigger an alert that is sent to the security operations team.

How can you identify whether account lockout will derail a password-guessing audit? The cleanest way to determine the lockout policy of a remote system is to enumerate it via a null session. Recall from Chapter 4 that the enum utility's -P switch will enumerate the lockout threshold if a null session is available. This is the most direct way to determine whether an account lockout threshold exists.

IJW Recall that enumeration of password policies is disabled by default in Windows Server 2003, unless ^™ the system is a domain controller.

If for some reason the password policy cannot be divined directly, another clever ap­proach is to attempt password guesses against the Guest account first. As we noted in Chapter 2, Guest is disabled by default on Windows Server 2003, but if you reach the lockout threshold, you will be notified, nevertheless. Following is an example of what happens when the Guest account gets locked out. The first password guess against the ar­bitrarily chosen IPC$ share on the target server fails, pushing the number of attempts over the lockout threshold specified by the security policy for this machine:

C:\>net use \\mgmgrand\ipc$ * /u:guest

Type the password for \\mgmgrand\ipc$: System error 132 6 has occurred.

Logon failure: unknown user name or bad password.

Once the lockout threshold has been exceeded, the next guess tells us that Guest is locked out, even though it is disabled:

C:\>net use \\mgmgrand\ipc$ * /u:guest

Type the password for \\mgmgrand\ipc$: System error 1909 has occurred.

The referenced account is currently locked out and may not be logged on to.

Also note that when guessing passwords against Guest (or any other account) you will receive a differenterror message ifyou actuallyguess the correctpassword for a disabled account:

C:\>net use \\mgmgrand\ipc$ * /u:guest

Type the password for \\mgmgrand\ipc$: System error 1331 has occurred.

Logon failure: account currently disabled.

Amazingly, the Guest account has a blank password by default on Windows Server 2003. Thus, if you continuously try guessing a NULL password for the Guest account, you'll never reach the lockout threshold (unless the password has been changed). If fail­ure of account logon events is enabled, an "account disabled" error message will appear, even if you guess the correct password for a disabled account.

Making Guest Less Useful

Of course, disabling access to logon services is the best way to prevent password guessing, but assuming this is not an option, how can you prevent the Guest account from being so

Hacking Exposed Windows Server 2003: Windows Security Secrets & Solutions

useful to remote attackers? Well, you can delete it using the DelGuest utility from Arne Vidstrom (see "References and Further Reading" at the end of this chapter). DelGuest is not supported by Microsoft and may produce unpredictable results (although the authors have used it on Windows 2000 Professional for more than a year with no problem).

If deleting the Guest account is not an option, try locking it out. That way, guessing passwords against it won't give away the password policy.

The Importance of Administrator and Service Accounts

We will identify a number of username/password combinations in this chapter, includ­ing many for the all-powerful Administrator account. We cannot emphasize enough the importance of protecting this account. One of the most effective NT family domain exploitation techniques we have seen in our consulting experience involves the compro­mise of a single machine within the domain—usually, in a large domain, a system with a NULL Administrator password can be found reliably. Once this system is compromised, an experienced attacker will upload the tools of the trade, including the lsadump2 tool that we will discuss in Chapter 8. The lsadump2 tool will extract passwords for domain accounts that log on as a service, another common feature in NT family domains. After this password has been obtained, it is usually a trivial matter to compromise the domain controller(s) by logging in as the service account.

In addition, consider this fact: Since normal users tend to change their passwords ac­cording to a fairly regular schedule (per security policy), chances are that guessing regular user account passwords might be difficult—and guessing a correct password obtains only user level access.

Hmmmm. What accounts rarely change passwords? Administrators! And they tend to use the same password across many servers, including their own workstations. Backup ac­counts and service accounts also tend to change their passwords infrequently. Since all of these accounts are usually highly privileged and tend not to change their passwords nearly as frequently as users, they are the accounts to target when performing password guessing.

Remember that no system is an island in an NT family domain, and it takes only one poorly chosen password to unravel the security of your entire Windows environment.

Now that we've gotten some housekeeping out of the way, let's discuss some password-guessing attack tools and techniques.

P Manual Password Guessing

Popularity:


10

Simplicity:


9

Impact:


5

Risk Rating:


8

Once NT family authentication services have been identified by a port scan and shares enumerated, it's hard to resist an immediate password guess (or ten) using the command-line net use command. It's as easy as this:

C:\>net use \\victim\ipc$ password /u:victim\username

System error 1326 has occurred.

Logon failure: unknown user name or bad password.

Note that we have used the fully qualified username in this example, victim\ username, explicitly identifying the account we are attacking. Although this is not always necessary, it can prevent erratic results in certain situations, such as when net use commands are launched from a command shell running as LocalSystem.

The effectiveness of manual password guessing is either close to 100 percent or nil, depending on how much information the attacker has collected about the system and whether the system has been configured with one of the high probability username/ password combinations listed in Table 5-1.

Note in Table 5-1 that we have used lowercase for all passwords—since NT family passwords are case-sensitive, different case variations on the above passwords may also prove effective (by contrast, usernames are case-insensitive). Needless to say, these com­binations should not appear anywhere within your infrastructure, or you will likely be­come a victim sometime soon.

We will discuss countermeasures later in the section "Countermeasures to Password Guessing."

Account Name


High Probability Passwords

Administrator, admin, root


NULL, password, administrator, admin, root, system, machine_name, domain_name, workgroup_name

test, lab, demo


NULL, test, lab, password, temp, share, write, full, both, read, files, demo, test, access, user, server, local, machine_name, domain_name, workgroup_name

username


NULL, welcome, username, company_name

backup


backup, system, server, local, machine_name, domain_name, workgroup_name

arcserve


arcserve, backup

tivoli


tivoli, tmesrvd

symbiator


symbiator, as400

backupexec


backup, arcada

Table 5-1. High Probability Username/Password Combinations

Hacking Exposed Windows Server 2003: Windows Security Secrets & Solutions

Dictionary Attacks

^Popularity:


8

Simplicity:


9

Impact:


7

Risk Rating:


8

As the fabled John Henry figured out in his epic battle with technology (represented by the Steel Driving Machine), human faculties are quickly overwhelmed by the unthink­ing, unfeeling onslaught of automated mechanical processes. Same goes for password guessing—a computer is much better suited for such a repetitive task and brings such massive efficiency to the process that it quickly overwhelms human password selection habits. A number of methods are available for automating password guessing against SMB, which we will discuss in sequence here.

FOR loops The simplest way to automate password guessing is to use the simple for command built into the Windows Server 2003 console. This can hurl a nearly unlimited number of username/password guesses at a remote system with NT family authentica­tion services available. If you are the administrator of such a system, you may find your­self in John Henry's shoes someday. Here's how the FOR loop attack works.

First, create a text file with space- or tab-delimited username/password pairs. Such a file might look like the following example, which we'll call credentials.txt:

[file: credentials.txt] administrator "" administrator password administrator administrator

[etc.]

This file will serve as a dictionary from which the main FOR loop will draw usernames and passwords as it iterates through each line of the file. The term "dictionary attack" describes the generic usage of precomputed values to guess passwords or crypto­graphic keys, as opposed to "brute force" attacks, which generate random values rather than drawing them from a precomputed table or file.

Then, from a directory that can access credentials.txt, run the following commands, which have been broken into separate lines using the special * character to avoid having to type the entire string of commands at once:

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

More? && echo %time% %date% >> outfile.txtA

More? && echo \\victim.com acct: %i pass: %j >> outfile.txt

(Make sure to prepend a space before lines 3, 4, and 5, but not line 2.)

Let's walk through each line of this set of commands to see what it does:

▼ Line 1 Open credentials.txt, parse each line into tokens delimited by space or tab, and then pass the first and second tokens to the body of the FOR loop as variables %i and %j for each iteration (username and password, respectively).

■ Line 2 Loop through a net use command, inserting the %i and %j tokens in place of username and password, respectively.

■ Line 3 Redirect stderr to nul so that logon failures don't get printed to

screen (to redirect stdout, use 1>>).

■ Line 4 Append the current time and date to the file outfile.txt.

▲ Line 5 Append the server name and the successfully guessed username and password tokens to outfile.txt.

After these commands execute, if a username/password pair has been successfully guessed from credentials.txt, the outfile.txt will exist and will look something like this:

C:\>type outfile.txt

11:53:43.42 Wed 05/09/2001

\\victim.com acct: administrator pass: ""

The attacker's system will also have an open session with the victim server: C:\>net use

New connections will not be remembered.

Status Local Remote Network

OK \\victim.com\IPC$ Microsoft Windows Network

The command completed successfully.

This simple example is meantonlyas ademonstrationofone possible wayto perform password guessing using a FOR loop. Clearly, this concept could be extended further, with input from a port scanner like ScanLine (see Chapter 3) to preload a list of viable NT family servers from adjacent networks, error checking, and so on. Nevertheless, the main point here is the ease with which password-guessing attacks can be automated using onlybuilt-inNTfamilycommands. Ifyou're running unprotected NTfamilyauthentica-tion services, wipe that sweat from your brow!

One drawback to using command-line net use commands is that each command creates a dis­crete logon session that appears as a separate log entry on the target host. When using the NT family GUI to authenticate, multiple passwords guesses within the same session show up as only a single entry in the logs.

Hacking Exposed Windows Server 2003: Windows Security Secrets & Solutions

NAT—the NetBIOS Auditing Tool NAT is a freely available compiled executable that per­forms SMB dictionary attacks, one target at a time. It operates from the command line, however, so its activities can be easily scripted. NAT will connect to a target system and then attempt to guess passwords from a predefined array and user-supplied lists. One drawbacktoNATisthatonceitguesses apropersetofcredentials,itimmediatelyattempts 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

NAT is a fastand effective password guessingtool ifqualityusername and password lists are available. If SMB enumeration has been performed successfully, the username list is truly easy to come by.

SMBGrind NAT is free and generally gets the job done. For those who want commer-cial-strengthpassword guessing, NetworkAssociates Inc.'s old CyberCop Scannerappli-cation came with a utility called SMBGrind that is extremely fast, because it can set up multiple grinders running in parallel. Otherwise, it is not much different from NAT. Some sample output from the command-line version of SMBGrind is shown next. The -l in the syntax specifies the number of simultaneous connections—that is, parallel grind­ing sessions; if -u and -p are not specified, SMBGrind defaults to NTuserlist.txt and NTpasslist.txt, respectively.

C:\>smbgrind -i 192.168.234.24 -r victim

-u userlist.txt -p passlist.txt -l 20 -v

Host address: 192.168.234.240

Userlist : userlist.txt

Passlist : passlist.txt

Cracking host 192.168.234.240 (victim)

Parallel Grinders: 20

Percent complete: 0 Trying: administrator

Trying: administrator password Trying: administrator administrator Trying: administrator test [etc.]

Guessed: administrator Password: administrator Trying: joel

Trying: joel password

Trying: joel administrator

Percent complete: 25

Trying: joel test

[etc.]

Trying: ejohnson

Trying: ejohnson password

Percent complete: 95

Trying: ejohnson administrator

Trying: ejohnson ejohnson

Guessed: ejohnson Password: ejohnson Percent complete: 100

Grinding complete, guessed 2 accounts

This particular example took less than a second to complete, and it covers seven usernames and password combinations, so you can see how fast SMBGrind can be. Note that SMBGrind is capable of guessing multiple accounts within one session (here it nabbed administrator and ejohnson), and it continues to guess each password in the list even if it finds a match before the end (as it did with the Administrator account). This may produce unnecessary log entries, since once the password is known, there's no sense in continuing to guess for that user. However, SMBGrind also forges event log entries, so all attempts appear to originate from domain CYBERCOP, workstation \\CYBERCOP in the remote system's Security Log if auditing has been enabled. One of these days, Microsoft will update the NT family Event Logs so that they can track IP addresses.

enum's -diet Option We first discussed the enum tool in Chapter 4, where we noted that it had the ability to perform SMB dictionary attacks. Here's an example of enum running such an attack against a Windows 2000 system:

C:\>enum -D -u administrator -f Dictionary.txt mirage

username: administrator dictfile: Dictionary.txt server: mirage

(1) administrator |

return 1326, Logon failure: unknown user name or bad password.

(2) administrator | password

[etc.]

(10) administrator | nobody

Hacking Exposed Windows Server 2003: Windows Security Secrets & Solutions

return 132 6, Logon failure: unknown user name or bad password.

(11) administrator | space

return 132 6, Logon failure: unknown user name or bad password.

(12) administrator | opensesame password found: opensesame

Following a successfully guessed password, you will find that enum has authenti­cated to the IPC$ share on the target machine. enum is really slow at SMB grinding, but it is accurate. (Our experience with false negatives is minimal.)

O Countermeasures to Password Guessing

Vendor Bulletin:


NA

Bugtraq ID:


NA

Fixed in SP:


NA

Log Signature:


Y

The bestsolutionto password guessingis to blockaccessto ordisableNTfamilyauthenti-cation services, as discussed in Chapter 4.

Assuming that SMB can't be blocked or disabled outright, we'll discuss some of the other available countermeasures next. Nearly all of the features discussed are accessible via Windows Server 2003's Security Policy MMC snap-in, which can be found within the Administrative Tools. Security Policy is discussed in more detail in Chapter 16.

Enforcing Password Complexity (passfilt) We cannot overemphasize the importance of se­lecting strong, difficult-to-guess passwords, especially for NT family authentication ser­vices. It takes only one poorly chosen password to lay an entire organization wide open (and we've seen it plenty of times). Since NT 4 Service Pack 2, Microsoft's most advanced operating system has provided a facility to enforce complex passwords across single sys­tems or entire domains. Formerly called passfilt after the dynamic link library (DLL) that bears its name, the password filter can now be set under the Security Policy applet (see Chapter 16) under the Passwords Must Meet Complexity Requirements option, as shown in Figure 5-1.

As with the original passfilt, setting this option to Enabled will require that pass­words 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)

liM Incidentally, the passfilt.dll file is no longer required on Windows Server 2003 systems—it's all done through this Security Policy setting.

NT 4's passfilt had two limitations: the six-character length requirement was hard-coded, and it filtered only user requests to change passwords. Administrators could still set weak passwords via console tools, circumventing the passfilt requirements. Both of these issues are easy to address. First, manually set a minimum password length using Security Policy. (We recommend seven characters per the discussion in Chapter 7.) Sec­ond, the Windows Server 2003 password filter should be applied to all password resets, whether from the console or remotely.

Custom passfilt DLLs can also be developed to match the password policy of any or­ganization more closely. (See the "References and Further Reading" section at the end of the chapter.) Be aware that Trojan passfilt DLLs would be in a perfect position to compro­mise security, so carefully vet third-party DLLs.

For highly sensitive accounts like the true Administrator and service accounts, we also recommend incorporating nonprinting ASCII characters. These make passwords extraor­dinarily hard to guess. This measure is designed more to thwart offline password guessing attacks (for example, cracking), which will be discussed in more depth in Chapter 7.

Account Lockout Another critical factor in blocking password guessing is to enable an ac­count lockout threshold, although some organizations find this difficult to support (as we will discuss momentarily). Account lockout will disable an account once the threshold has been met. Figure 5-2 shows how account lockout can be enabled using Security Policy. Unless account lockout is set to a reasonably low number (we recommend 5), password guessing can continue unabated until the intruder gets lucky, or until he compiles a large enough dictionary file, whichever comes first.

Interestingly, Windows Server 2003 maintains a record of failed logins even if the lockout threshold has not been set. (A tool like UserDump from Chapter 4 will show the number of failed logins and the last failed login date via null session, if available.) If ac­count lockout is subsequently enabled, it examines all accounts and locks out those that have exceeded the threshold within the last Y minutes (where Y is the number of minutes you set in the account lockout policy). This is a more secure implementation, since it en­ables the lockout threshold to take effect almost instantaneously, but it may cause some disruption in the user community if a lot of accounts have previous failed logons that oc­curred within the lockout threshold window (although this is probably a rare occur­rence). (Thanks to Eric Schultze for bringing this behavior to our attention.)

Some organizations we've worked with as security consultants have resisted imple­menting lockout thresholds. Since only select administrative groups can reenable a locked out account, most companies observe a converse relationship between a lower lockout threshold and higher help desk support costs and thus choose not to impose such a burden on their users, support staff, and financial resources. We think this is a mistake, though, and we advise that you spend the effort to find the magic number of lockouts that your organization can tolerate without driving support staff mad. Remember that even seemingly absurd thresholds can prevent wanton password guessing. (We've even seen organizations implement 100-count thresholds!) You can also play with the account lock­out duration and automatic reset duration (also configured in Security Policy) to alleviate some burden here.

This being said, account lockout thresholds create the potential for a denial of service condition, whether accidentally or intentionally. A common scenario is service accounts that get locked out when passwords expire on the domain (accidental), or a disgruntled employee who attempts to logon using the account names of coworkers and known bo­gus passwords simply to frustrate fellow employees intentionally. Use this option with care, and make sure it works well in your particular environment.

Enable Auditing of Logon Failure Events Dust off that handy-dandy Security Policy applet once again and enable auditing of Logon and Account Logon event failure (at a mini­mum), as shown in Figure 5-3.

This is a minimum recommendation, as it will capture only failed logon events that may be indicative of password-guessing attacks. Failed logons will appear as Event ID 529 (failed logon event) and 681 (failed account logon event) in the Security Log. Account locked out events are ID 539. We discuss auditing in more general terms in Chapter 6. Re­member that the Event Log will track only the NetBIOS machine name of the offending system, not its IP address, limiting your ability to track password-guessing activity.

Windows Server 2003 records success of account logon events and logon events by default.

Review the Event Logs! Remember that simply auditing logon events is not an effec­tive defense against intrusions—logs must be periodically reviewed if the entries gen­erated by these settings are to have any meaning. In a large environment, reviewing the logs even on a monthly basis can be a Herculean task. Seek out automated log

Hacking Exposed Windows Server 2003: Windows Security Secrets & Solutions

monitoring and reporting tools to perform this task for you. Some recommended products are listed here:

▼ Event Log Monitor (ELM) from TNT Software ELM consolidates all Event Logs to a central repository in real time, to provide correlation of all events in one data source. An agent must be installed on each machine to be monitored.

▲ EventAdmin from Aelita Software EventAdmin performs much the same functions as ELM, without requiring an agent on each machine.

Links to each of these company's web sites are listed in the "References and Further Reading" section at the end of this chapter.

Lock Out the True Administrator Account and Create a Decoy The Administrator account is especially problematic when it comes to password-guessing attacks. First, it has a stan­dard name that is widely known—intruders are usually assured that they at least have the account name correct when they attack this account. Changing affords some protec­tion, but it's not foolproof—we've already shown in Chapter 4 how the null session enu­meration can determine the true Administrator name. Second, the Administrator account is not locked out by default on Windows Server 2003, no matter what account lockout set­tings have been configured.

It is debatable how much value renaming the Administrator account provides from a security perspective, since the true Administrator can always be identified by its SID if enumeration is possible, no matter what name it carries (see Chapter 4). However, we rec­ommend renaming the Administrator account nevertheless, since it provides greater security if enumeration is not possible.

We further recommend that a decoy Administrator account be set up to look exactly like the true Administrator account. This will quickly identify lowbrow password guess­ing attacks in the logs. Do not make the fake Administrator a member of any groups, and make sure to fill in the account's Description field with the appropriate value—"Built-in account for administering the computer/domain."

As for lockout, the NT 4 Resource Kit provided a utility called passprop that could be used to configure the true Administrator account (RID 500) to be locked out from the net­work. (The true Admin account will always be able to log in interactively.) The passprop tool quit working under Windows 2000 up to Service Pack 2 (even though it appears to work). Windows Server 2003 contains this same cumulative fix and responds to passprop appropriately.

Running passprop to set Administrator lockout is easy, as shown next:

C:\>passprop /adminlockout

Password must be complex

The Administrator account may be locked out except for interactive logons on a domain controller.

To be extra secure, manually lock out the true Administrator account from the net­work after running this command. This ensures that the true Admin account will not be able to access the system remotely. If Admin has been renamed, this will be doubly diffi­cult for attackers to figure out.

Get the passprop tool from the Windows 2000 Server Resource Kit; it is not included in the Profes­sional kit.

\YW The first edition of Hacking Exposed Windows 2000 alluded to a tool called admnlock. Microsoft never published this tool, instead opting to patch the operating system to work with the old passprop.

Disable Idle Accounts In our consulting experience, we've found that the toughest orga­nizations to break into are those that use account lockout as well as account expiration. Contractors, consultants, or other temporary workers who are hired for only a short pe­riod should be given accounts that are configured to expire after a set amount of time. You should also do the same with accounts used for temporary activities like migrations. This assures the system administrator that the account will be disabled when the temp work is completed and the account is no longer necessary, as opposed to when the human resources department gets around to telling someone to disable or delete the account af­ter a few months (or years, depending on the efficiency of the HR department!). If the temporary work contract gets extended, the account can be re-enabled, again for a set pe­riod of time. Organizations that implement this policy can be much more difficult to break into by guessing passwords for user accounts, since there are fewer accounts to tar­get at any one time. Moreover, the accounts that are weeded out are typically those with the worst passwords—temporary accounts!

Account expiration can be set on Windows Server 2003 domain controllers on the properties of a user account, Account tab, under Account Expires, as shown in Figure 5-4.

Vet Administrative Personnel Carefully Last but not least, when hiring personnel who will require administrative privileges, make sure that strict hiring policies and background checks have been performed. Members of the highly privileged administrative groups under Windows Server 2003 have the ability to wipe out logs and otherwise hide their tracks so that it is nearly impossible to track their (mis)deeds. Assign each administrator a separate account to enable logging of individual activities, and don't make that account name guessable (like "admin"). Remember, the username/password pairs for adminis­trative accounts are the keys to your Windows kingdom—treat the people who hold those keys with deference.

Prevent Creation of Administrative Shares Although it's somewhat minor, we should at least mention how to prevent creation of administrative shares (C$, ADMIN$) on Win­dows 2000 and Windows Server 2003. Intruders typically target these shares for pass­word-guessing attacks, since they permit direct mounting of large portions of the system drive. Here's how to delete the administrative shares on Windows Server 2003:

1. Delete the ADMIN$ and all driveletter$ shares in the Computer Management Control Panel, under Shared Folders\Shares.

2. Create HKLM\System\CurrentControlSet\Services\LanmanServer\ Parameters\AutoShareServer (REG_DWORD) and set it to zero (0).

Administrative shares will be deleted and will not be automatically re-created after subsequent reboots.

This does not eliminate the IPC$ share; it is required by Server service and can be deleted only by dis­abling that service.

EAVESDROPPING ON WINDOWS AUTHENTICATION

Should direct password guessing attacks fail, an attacker may attempt to obtain user creden­tials by eavesdropping on NT family logon exchanges. Many tools and techniques are avail­able for performing such attacks, and we will discuss the most common ones in this section:

▼ Sniffing credential-equivalents directly off of the network wire ■ Capturing credential-equivalents using a fraudulent server ▲ Man-in-the-middle (MITM) attacks

"Sniffing" is a colloquial term for capturing and analyzing communications from a network. The term was popularized by Network Associates' Sniffer line of network monitoring tools.

Since these are somewhat specialized attacks, they are most easily implemented us­ing specific tools. Thus our discussion will be centered largely around these tools.

This section assumes familiarity with Windows' LAN-oriented authentication protocols, including the NTLM challenge-response mechanism, which are described in Chapter 2.

©Sniffing Kerberos Authentication Using KerbSniff/KerbCrack

Popularity 5

Popularity:


5

Simplicity:


3

Impact:


9

Risk Rating:


6

Yes, you heard us right: sniffing Kerberos. While the potential for eavesdropping on LM/NTLM authentication is widely known, it is much less widely appreciated that the same thing can be done with Windows 2000 and later Kerberos domain logons using the nifty KerbSniff/KerbCrack tools from Arne Vidstrom at ntsecurity.nu. In fact, we couldn't believe it until we tested it and saw the data with our own eyes.

KerbSniff and KerbCrack work in tandem. KerbSniff sniffs the network and pulls Kerberos domain authentication information, saving it to a user-specified output file (in our example, output.txt), as shown here:

C:\>kerbsniff output.txt

KerbSniff 1.2 - (c) 2002, Arne Vidstrom

- http://ntsecurity.nu/toolbox/kerbcrack/

Available network adapters:

0 - 192.168.234.34

1 - 192.168.234.33

2 - 192.168.208.1 4 - 192.168.223.1

Select the network adapter to sniff on: 1 Captured packets: *

Press ctrl-c to end capture. The asterisk after "Captured packets" indicates the number of logons that have been sniffed.

Hacking Exposed Windows Server 2003: Windows Security Secrets & Solutions

You can then use KerbCrack to perform brute-force or dictionary cracking operations on the output file, revealing the passwords given enough time and computing horsepower (or a particularly large dictionary). We use the dictionary crack option in this example:

C:\>kerbcrack output.txt -d dictionary.txt

KerbCrack 1.2

(c) 2 0 02, Arne Vidstrom

http://ntsecurity.nu/toolbox/kerbcrack/

Loaded capture file.

Currently working on:

Account name From domain Trying password Trying password Trying password

administrator

VEGAS2

admin

guest

root

Number of cracked passwords this far: 1

Done.

The last password guessed is the cracked password (in our example, "root").

KerbCrack will crack only the last user entry made in the KerbSniff file; you will have to separate the en­tries manually into different files if you want to crack each user's password. Also, we've noted that KerbSniff sometimes appends mor nto some account names.

The basis for this attack is explained in a paper written in March 2002 by Frank O'Dwyer. (See "References and Further Reading" at the end of this chapter for a link.) Es­sentially, the Windows Kerberos implementation sends a pre-authentication packet that contains a known plaintext (a timestamp) encrypted with a key derived from the user's password. Thus, a brute-force or dictionary attack that decrypts the pre-authentication packet and reveals a structure similar to a standard timestamp unveils the user's pass­word. This has been a known issue with Kerberos 5 for some time.

O Countermeasures to Kerberos Sniffing

Vendor Bulletin:


NA

Bugtraq ID:


NA

Fixed in SP:


NA

Log Signature:


Y

In our testing, setting encryption on the secure channel (see Chapter 2) did not pre­vent this attack, and Microsoft had issued no guidance on addressing this issue at the time of this writing. Thus, you're left with the classic defense: pick good passwords. Frank O'Dwyer's paper notes that passwords of eight characters in length containing dif­ferent cases and numbers would take an estimated 67 years to crack using this approach on a single Pentium 1.5GHz machine, so if you are using Windows Server 2003's pass­word complexity feature (mentioned earlier in this chapter), you've bought yourself some time (grin). Also remember that if a password is found in a dictionary, it will be cracked immediately.

Sniffing LM Authentication

^Popularity:


7

Simplicity:


2

Impact:


10

Risk Rating:


6

The L0phtcrack(LC) password auditingtool is possiblyone ofthe mostrecognized in the security community and, indeed, even within mainstream software circles. Although its primary function is to perform offline password cracking, more recent versions have shipped with an add-on module called SMB Packet Capture, which is capable of sniffing LAN Manager (LM) challenge-response authentication traffic off of the network and feeding it into the L0phtcrack cracking engine. We will discuss password cracking and LOphtcrack in Chapter 8; in this chapter, we will focus on the tool's ability to capture LM traffic and decode it.

As we alluded to in Chapter 2, weaknesses in the LM hash allow an attacker with the ability to eavesdrop on the network to guess the password hash itself relatively easily and then attempt to guess the actual password offline—yes, even though the password hash never traverses the network! An in-depth description of the process of extracting the password hash from the LM challenge-response routine is available within LC's docu­mentation, under "Technical Explanation of Network SMB Capture," but we will cover the essentials of the mechanism here.

The critical issue is the way the LM algorithm creates the user's hash based on two separate seven-character segments of the account password. The first 8 bytes are de­rived from the first seven characters of the user's password, and the second 8 bytes are derived from the eighth through fourteenth characters of the password:

First 8 bytes of LM hash

Second 8 bytes of LM hash

Derived from first 7 Derived from second 7

characters of account password characters of account password

Each chunk can be attacked using exhaustive guessing against every possible 8-byte combination. Attacking the entire 8-byte "character space" (that is, all possible combina­tions of allowable characters up to 8) is computationally quite easy with a modern desk­top computer processor. Thus, if an attacker can discover the user's LM hash, she stands a good chance of ultimately cracking the actual cleartext password.

So how does SMB Packet Capture obtain the LM hash from the challenge-response exchange? As we saw in Chapter 2, neither the LM nor the NTLM hash are sent over the wire during NTLM challenge-response authentication. It turns out that the "response" part of NTLM challenge-response is created by using a derivative of the LM hash to encrypt the 8-byte "challenge." Because of the simplicity of the derivation process, the response is also easily attacked using exhaustive guessing to determine the original LM hash value. The efficiency of this process is greatly improved depending on the password length. The end result: LC's SMB Packet Capture can grab LM hashes off the wire if it can sniff the LM response. Using a similar mechanism, it can obtain the NTLM challenge-response hashes as well, although it is not currently capable of deriving hashes from NTLMv2 chal­lenge-response traffic. Figure 5-5 shows SMB Packet Capture at work harvesting LM and NTLM responses from a network.

Once the LM and NTLM hashes are derived, they can be imported into LC and subject to cracking (see Chapter 8). Depending on the strength of the passwords, the cracking process may reveal cleartext passwords in a matter of minutes or hours.

You should note some important things about using LC's SMB Packet Capture utility:

▼ IMPORTANT: It is currently unable to derive hashes from logon exchanges between Windows 2000 and later systems (a legacy Windows machine must represent one side of the exchange, client or server). In our testing, the most recent version, LC 4, was able to derive LM responses only from authentications that involved NT 4 or earlier systems. If both ends of the conversation included only Windows XP, 2000, or Server 2003, LC 4 SMB Packet Capture did not capture any packets.

■ It can capture challenge-response traffic only from shared media, not switched. (However, this can be circumvented by using Address Resolution Protocol [ARP] redirection/cache poisoning on switched Ethernets; see Hacking Exposed, Fourth Edition, Chapter 9.)

■ The time to crack challenge-response hashes captured from a network sniffing completion scales linearly as you add password hashes to crack. The slowdown results from each hash being encrypted with a unique challenge so that work done cracking one password cannot be used again to crack another (which is not the case with hashes obtained from a Registry dump). Thus, ten network challenge-response hashes will take ten times longer to crack than just one, limiting the effectiveness of this type of password auditing to specific situations.

▲ The included WinPcap packet capture driver must be successfully installed and running during SMB Packet Capture. (LC installs WinPcap automatically, and the driver is launched at boot time.)

To verify correct installation of WinPcap, check to see that WinPcap appears in the Add/Remove Programs Control Panel applet. When running SMB Packet Capture, you can verify that the driver is loaded by running Computer Management (compmgmgt.msc) and looking under the System Information/Software Environment/Drivers node. The entry called packet_2.1 should be listed as Running. (The number may be different for different versions of WinPcap.) Also, be sure to disable any personal firewall software that may be running on your system to ensure that it does not interfere with WinPcap's packet capture.

SoopLM/BeatLM Another great set of tools for capturing LM responses and cracking them is the ScoopLM and BeatLM tools from Urity at SecurityFriday.com. ScoopLM per­forms similarly to LC SMB Packet Capture, but it will also give visibility into authentica­tion exchanges involving systems newer than NT 4. For example, in Figure 5-6, we show

ScoopLM capturing password exchanges between a Windows Server 2003 server and the following clients: Windows NT 4, XP, and Server 2003. (You can tell which client is which by the username we selected.)

Unfortunately, when you attempt to crack these logon exchanges using BeatLM, you quickly find that the LM responses in this data are not susceptible to cracking, as we show in Figure 5-7. Each of the passwords for the user in question is "test," and we have used a dictionary with the word "test" in it. As you can see, the NT 4 LM response is cracked quite handily, but the Windows XP and Windows Server 2003 client responses are not, showing the ERR message in the right column. We'll discuss the reason for this in the "Countermeasures" section coming up shortly.

Redirecting SMB Logon to the Attacker Assuming users can be tricked into connecting to a server of the attacker's choice, capturing LM responses becomes much easier. This approach also comes in handy when network switching has been implemented, as it will invoke au­thentication sessions proximal to the attacker's system regardless of network topology.

It is also a more granular way to target individual users. The most basic trick was sug­gested in one of the early releases of L0phtcrack: send an e-mail message to the victim with an embedded hyperlink to a fraudulent server. The victim receives the message, the hyperlink is followed (manually or automatically), and the client unwittingly sends the user's LM/NTLM credentials over the network. Such links are easily disguised and typi­cally require little user interaction because Windows automatically tries to log in as the cur­rent user ifno other authentication information is explicitly supplied. This is probably one of the most debilitating behaviors of Windows from a security perspective, and it's one that we will touch on again in Chapter 13.

As an example, consider an imbedded image tag that renders with HTML in a web page or e-mail message:

When this HTML renders in Internet Explorer or Outlook/Outlook Express, the null.gif file is loaded and the victim will initiate Windows authentication withattacker_server. The shared resource does not even have to exist. We'll discuss other such approaches, includ­ing telnet session invocation, in Chapter 13 on client-side hacking.

Once the victim is fooled into connecting to the attacker's system, the only remaining feature necessary to complete the exploit is to capture the ensuing LM response, and we've seen how trivial this is using SMB Packet Capture or ScoopLM. Assuming that one of these tools is listening on attacker_server or its local network segment, the LM/NTLM challenge-response traffic will come pouring in.

One variation on this attack is to set up a rogue NT family server to capture the hashes as opposed to a sniffer like SMB Packet Capture. We'll discuss rogue SMB servers in "Subverting Windows Authentication" later in this chapter. It is also possible to use ARP redirection/cache poisoning to redirect client traffic to a designated system; see Hacking Exposed, Fourth Edition, Chapter 9.

Countermeasures

Vendor Bulletin:


NA

Bugtraq ID:


NA

Fixed in SP:


NA

Log Signature:


Y

The risk presented by LM response sniffing can be mitigated in several ways.

One way is to ensure that network security best practices are followed. Keep Windows authentication services within protected networks and ensure that the overall network in­frastructure does not allow LM traffic to pass by untrusted nodes. A corollary of this rem­edy is to ensure that physical network access points (wall jacks and so on) are not available to casual passersby. (Remember that this is made more difficult with the growing preva­lence of wireless networking.) In addition, although it's generally a good idea to use fea­tures built-in to networking equipment or Dynamic Host Configuration Protocol (DHCP) to prevent intruders from registering physical and network-layer addresses without au­thentication, recognize that sniffing attacks do not require the attacker to obtain a MAC (Media Access Control) or IP address since they operate in promiscuous mode.

In the second case, configure all Windows systems within your environment to dis­able propagation of the LM hash on the wire. This is done using the "Network Security: LAN Manager Authentication Level" setting under Security Policy (Computer Configu­ration/Windows Settings/Security Settings/Local Policies/Security Options node within the Group Policy or Local Security Policy MMC snap-in). This setting allows you to configure Windows 2000 and later to perform LM/NTLM authentication in one of six ways (from least secure to most; adapted from KB article Q239869):

▼ Level 0 Send LM and NTLM response; never use NTLM 2 session security. Clients use LM and NTLM authentication and never use NTLM 2 session security; domain controllers accept LM, NTLM, and NTLM 2 authentication. (This is the default on NT family products through Windows XP.)

■ Level 1 Use NTLM 2 session security if negotiated. Clients use LM and NTLM authentication and use NTLM 2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLM 2 authentication.

■ Level 2 Send NTLM response only. Clients use only NTLM authentication and use NTLM 2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLM 2 authentication. (This is the default on Windows Server 2003.)

■ Level 3 Send NTLM 2 response only. Clients use NTLM 2 authentication and use NTLM 2 session security if the server supports it; domain controllers accept

LM, NTLM, and NTLM 2 authentication.

■ Level 4 Domain controllers refuse LM responses. Clients use NTLM 2 authentication and use NTLM 2 session security if the server supports it; domain controllers refuse LM authentication (that is, they accept NTLM and NTLM 2).

▲ Level 5 Domain controllers refuse LM and NTLM responses (they accept only NTLM 2). Clients use NTLM 2 authentication and use NTLM 2 session security if the server supports it; domain controllers refuse NTLM and LM authentication

(they accept only NTLM 2).

By setting LAN Manager Authentication Level to Level 2, Send NTLM Response Only, LM response sniffing tools will not be able to derive a hash from challenge-re­sponse authentication. (Settings higher than 2 will also work and are more secure.) Figure 5-8 shows the Windows Server 2003 Security Policy interface in its default setting of the LM Authentication level.

When applying the LM Authentication Level setting on Windows Server 2003, right-click the top node of the MMC tree in which the setting is displayed and select Reload. This will apply the setting immediately.

What about the newer NTLM and NTLM 2 protocols? The NTLM response is not sus­ceptible to LM response sniffing, since it is not based on concatenated cryptographic ma­terial that can be attacked in parallel. For example, L0phtcrack's SMB Packet Capture will still appear to have captured a Windows Server 2003 client's LM response even if its LM Authentication Level is set to 2, but once imported into L0phtcrack for cracking, pass­word hashes derived from NTLM-only responses will not crack within a reasonable timeframe. As we saw earlier, other LM response sniffing tools like ScoopLM exhibit this same behavior.

This is not to say that one cannot crack valid NTLM hashes (as we will see is quite possible in Chapter 8), but rather that it is not easy to derive the NTLM hash from NTLM-only challenge-response authentication.

It is interesting to note that NTLM 2 challenge-responses can be sniffed as well, and, in theory, they could also be vulnerable to a similar attack. However, no publicly avail­able tools can perform such an attack today.

The LAN Manager Authentication Level setting was formerly configured using the HKLM\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel Registry key under NT 4, where the Level 0-5 designations originated, even though the numbers don't appear in the Windows Server 2003 Security Policy interface (see KB article Q147706).

Remember that as long as systems in an environment have not been set to Level 2 or higher, that envi­ronment is vulnerable, even if all servers have been set to Level 4 or 5. Clients will still send the LM response even if the server doesn't support it.

One of the biggest issues large organizations faced when deploying the old LMCompatibilityLevel Registry setting was the fact that older Windows clients could not send the NTLM response. This issue was addressed with the Directory Services Client, in­cluded on the Windows 2000 CD-ROM under Clients\Win9x\Dsclient.exe. Once installed, DSClient allows Windows 9x clients to send the NTLM 2 response. Windows 9x must still be configured to send only the NTLM 2 response by creating an LSA Registry key under HKLM\System\CurrentControlSet\Control and then adding the following registry value:

Value Name: LMCompatibility Data Type: REG_DWORD

Value: 3

Valid Range: 0,3

IJW On Windows 9xclients with DSClient installed, this Registry value should be named LMCompatibility, ^™ not LMCompatibilityLevel, which is used for the NT 4 setting.

It's also important to note that the LAN Manager Authentication Level setting applies to SMB communications. Another Registry key controls the security of Microsoft Remote Procedure Call (MSRPC) and Windows Integrated authentication over HTTP on both cli­ent and server (they must match):

HKLM\System\CurrentControlSet\control\LSA\MSV1_0

Value Name: NtlmMinClientSec or NtlmMinServerSec

Data Type: REG_WORD

Value: one of the values below:

0x00000010- Message integrity

0x00000020- Message confidentiality

0x00080000- NTLM 2 session security

0x20000000- 128-bit encryption

0x80000000- 56-bit encryption

Finally, as we've noted frequently in this chapter, Windows 2000 and later versions are capable of performing another type of authentication, Kerberos. Because it is a wholly different type of authentication protocol, it is not vulnerable to LM response sniffing. Un­fortunately, clients cannot be forced to use Kerberos by simply setting a Registry value similar to LM Authentication Level, so as long as there are down-level systems in your environment, it is likely that LM/NTLM challenge-response authentication will be used.

In addition, in many scenarios, Kerberos will not be used in a homogeneous Win­dows 2000 or later environment. For example, if the two machines are in a different Windows 2000 forest, Kerberos will not be used (unless a cross-forest trust is enabled, which is available only in native Windows Server 2003 domains; see Chapter 2). If the two machines are in the same forest, Kerberos may be used—but only if the machines are referenced by their NetBIOS machine names or DNS names; accessing them by IP address will always use LM/NTLM challenge-response. Finally, if an application used within a Windows Server 2003 domain does not support Kerberos or supports only leg­acy LM/NTLM challenge-response authentication, it will obviously not use Kerberos, and authentication traffic will be vulnerable to LM response sniffing.

Remember also that to set up Kerberos in a Windows 2000 and later environment, you must deploy a domain with Active Directory. Some good tools to use to determine whether Kerberos is being used for specific sessions are the Resource Kit kerbtray utility, a graphical tool, or the command-line klist tool. We'll discuss Kerberos in more detail in Chapter 16.

Remember that earlier in this chapter we've demonstrated that Kerberos authentication can be sniffed as well!