Password Security: Part 2

83-01-12

DATA SECURITY MANAGEMENT PASSWORD SECURITY: PART 2

Jonathan S. Held

INSIDE Introduction; The Problem; Contending with the Internet; Getting to the Source of the Problem; The Mathematics of Passwords; UNIX and Linux; Windows 95 and 98; Windows NT; Recommendations

WINDOWS 95/WINDOWS 98 While password protection on Linux or UNIX systems may be bad, mea- suring how vulnerable a system is to compromise depends on many other factors that are highlighted later in this article. Suffice it to say that the password implementation mechanism in Windows 95 and 98 (passwords are stored in a file ending with the .PWL extension) is far worse. But these systems were developed with security apparently more of an afterthought than anything else; kernel security support had very limited functionality. For this reason, perhaps one should scrutinize these OSs in a different context, limiting the examination to the discussion of the PWL file and security considerations when internetworking various Win- dows platforms. Many Windows and non-Windows resources require passwords for access. In a LAN environment, one of the very first actions that is re- quired in order for users to “browse”

the network is to enter a Microsoft PAYOFF IDEA Networking password as illustrated A strong password policy, rigorously enforced in Exhibit 1. serves as an excellent foundation to enhance net- At first glance, the dangers in this work security. This article, presented in two parts, action are not intuitively obvious. looks at passwords from a hacker’s perspective. Part 1 (83-01-11) introduced the problems and The casual user indiscriminately en- then examined how access is mediated on UNIX ters a password without a care in the and Linux machines, focusing on password file for- world — how the system validates mat, the use of shadowed password files, and tools the password is not important. More- and types of attacks that hackers use to break over, where the information that is passwords. Part 2 (this article) explores password usage and insecurities in Windows 95, 98, and NT. entered into the “Password” field It concludes with a list of rules for creating good goes is something that few, if any- passwords and a review of password generation one, ever give second thought to. and utilities useful to system administrators.

DATA SECURITY MANAGEMENT

EXHIBIT 1 — Entering a Microsoft Networking Password

However, take a closer look at what happens during this process and any system administrator would become seriously concerned with security. The password information that the user enters is saved to the hard drive in what is called a PWL file. The PWL file contains very valuable information — everything from dial-up networking (DUN) to network passwords, and many applications (such as Netscape and Internet Ex- plorer) access the contents of this file and verify or extract username and password information (see Exhibit 2). The PWL file can hold up to 255 records, with each record consisting of three fields:

1. resource type: an integer, ranging in value from 0 to 255; common values are 6 (DUN) and 19 (WWW) 2. resource name 3. resource password

EXHIBIT 2 — Entering a Network Password: The User Name and Pass- word Entered Are Cached in the Currently Logged-on User’s PWL File

PASSWORD SECURITY: PART 2

The file is encrypted with a key derived from the user’s password using the RC4 strong cipher algorithm. When the user attempts to log on the system, Windows decrypts the PWL file using the specified password and verifies the resulting checksum. If everything checks out, the user is allowed to log on and applications can access the contents of the PWL file by using an application programming interface (API). Each PWL file is registered with the system; run sysedit.exe (System Configuration Editor) and take a look at the system.ini file. In that file, one will find a section labeled [Password Lists]; for example [Password Lists] JON=C:\WINDOWS\JON.PWL JSHELD=C:\WINDOWS\JSHELD.PWL Entries are generally in the format USERNAME=PATHTOPWLFILE. Know- ing that PWL files are kept in the WINDOWS subdirectory by default, anyone can open an MS-DOS Prompt window and issue the command dir *.pwl to obtain a complete listing of these files. All that is left to do is to perform the crack. For this, there are several programs in the public domain that can be used. The first one to take a look at is the PWL editor that comes with Win- dows 95 and 98. If one has the original CD, look under \TOOLS\RES- KIT\NETADMIN\PWLEDIT for the program pwledit.exe. Run this program and get a good look at the contents of the PWL file for the currently logged-on user (see Exhibit 3). This is clearly a management tool that allows one to remove resources from the PWL file. It does not display what the resource usernames or passwords are, but this is easily accomplished by going elsewhere (e.g., http://www.ryanspc.com/password.html) and downloading a copy of PwlCrack.zip. The zipped file, pwlcrack.exe, is extremely small — 26,112 bytes to be exact — and although it claims to be a Win95 PWL viewer, the author found that it also works on Win98 machines. Exhibit 4 shows an example of the output generated by this program. PWLCrack.exe is limited to displaying the resource username and password pair combinations for the currently logged-on user. It does not display the user’s login name or password, which is ideally what the malefactor is looking for. A much more useful and robust utility that gives us this information is PWLTool v. 6.0 (see Exhibit 5), which can be down- loaded from http://www.webdon.com/vitas/pwltool.htm. This application makes cracking PWL files look like a trivial operation. It has a very nice, easy-to-use interface that allows the user to select from multiple user/PWL files and perform various types of password attacks (brute force, smart force, and dictionary) if the password is unknown. Once the user’s password is cracked, it will display the contents of the PWL file in a format almost identical to that produced by PwlCrack.exe.

DATA SECURITY MANAGEMENT

EXHIBIT 3 — Using the Microsoft Password List Editor

EXHIBIT 4 — Output of PwlCrack.exe

DATA SECURITY MANAGEMENT

The registration cost for PWLTool v. 6.0 is well worth it if recovering passwords from Windows 95 and 98 is a frequent administrative task. What one should take away from this brief discussion is the danger that exists in a heterogeneous computing environment where non-Windows NT computers are allowed to become part of a domain. The old adage that a system is only as secure as its weakest link surely holds here; a user that logs on to a domain from a Windows 95 or 98 machine has the domain username and password cached in the PWL file. As previously demonstrated, the security imposed on this file is inherently weak and access to resource usernames and passwords can be obtained using a va- riety of free or relatively inexpensive, publicly available utilities. For this reason, at no time should these OSs be allowed to become part of a Win- dows NT domain. Administrators should examine the network control panel program, specifically looking at the properties settings of the client for Microsoft Networks, and ensure that logging on to a Windows NT domain is disabled. Exhibit 6 illustrates what this dialog box looks like.

EXHIBIT 6 — Checking the Client for Microsoft Networks Properties to Ensure a Windows 95 or 98 Computer Cannot Log onto a Domain

PASSWORD SECURITY: PART 2

WINDOWS NT Average day-to-day computer users will most undoubtedly not favor using a UNIX or Linux operating system, primarily because the applications they use are not supported or have extremely limited support in these environments. Sure, they could always find comparable applications (e.g., Sun’s StarOffice) or use special software such as OS emulators that allow running non-native applications, but doing so requires learning a new application or how to make configuration settings. Few people want to spend the time figuring out how to migrate, so one sticks with what one knows. Windows NT has not been around nearly as long as UNIX has, but it has widespread acceptance and has managed to entrench itself among many businesses as the choice OS. System administration on a Windows NT network is a fairly straight- forward task. The basics of creating accounts, setting permissions and policies, etc., are all made easier by the GUI utilities distributed with the OS (look under Start->Programs->Administrative Tools). Like UNIX, NT is a discretionary access control (DAC) system, whereby individual users can modify the access control lists (ACLs) on resources, which enu- merate who has permission to access these resources and what type of permission they have (read, write, execute, or some combination thereof; to view the ACL on a file, open a command prompt windows and type cacls <filename>). This means that if malefactors can log in using another individual’s credentials, they authenticate themselves to the system with a set of permissions that can be altogether different from someone else’s. And, of course, the one account that hackers want is the administrator’s. Given that NT creates two accounts during installation — Administrator and Guest — half the hacker’s battle is over; that is, the user name is al- ready known. Neither of these built-in accounts can be deleted, so the only alternative is to disable or rename them. But before one does this, beware — Guest is commonly used by other applications. Disable the account and the applications will not be able to execute as intended. Rath- er, one should ensure that the Guest account has a good password; and while one cannot delete the Administrator account, one can rename it to something less obvious. In order for account information to be used by the OS, it has to be per- sistent. Windows NT does what every other OS does to accomplish this — it writes the information to disk; however, the manner in which this is done and the way information is managed is slightly different from the previous examples. Windows NT uses a Security Accounts Manager (SAM) database to store sensitive user information (look in the \\WINNT\SYSTEM32\CONFIG directory and one finds the files SAM and SAM.LOG). While the OS is running, the SAM database is locked, and copying, deleting, or otherwise manipulating it through a user context is not possible (see Exhibit 7).

DATA SECURITY MANAGEMENT

EXHIBIT 7 — Trying to Access the SAM Database Files from a Windows NT (top) and Windows 98 (bottom) Machine while the OS is Running

As with everything else, however, there are utilities for Windows NT that allow access to the contents of the SAM database. Knowing what these utilities are and how they work is extremely important if system administrators want to have a better understanding of what security risks exist and what steps they can take to improve network security.

PASSWORD SECURITY: PART 2

Of all the password applications available for Windows NT, perhaps the most well-known one is a product called L0phtCrack written by L0pht Heavy Industries (available for download at http://www.l0pht.com/l0phtcrack). L0phtCrack allows NT Administrators to quickly evaluate the security of user passwords, and it can perform different types of password attacks (dictionary, hybrid dictionary, or ex- haustive keyspace) based on appropriate configuration settings. L0phtCrack can obtain NT passwords directly from the registry by looking at the contents of the SAM files or by monitoring simple message block (SMB) network activity. To perform most of these operations, the malefactor has to be an Administrator on the machine he wishes to attack. This requirement, of course, limits its utility, but it was never intended to be a “hacking” tool; rather, it serves as an inexpensive ($100) password management tool and is a nice complement to double-check that password restrictions configured by the Accounts Policy settings in the User Manager for Domains utility are functioning as desired (see Exhibit 8).

EXHIBIT 8 — Setting Password Restrictions in the Account Policy Dialog Box

DATA SECURITY MANAGEMENT

L0phtCrack is as easy to use as PWLTool and its GUI provides a limited selection of menu options that helps keep its operation simple and self-explanatory. Exhibit 9 illustrates L0phtCrack 2.5 running a brute- force attack against a SAM database containing nine user accounts. In a matter of seconds, the application has cracked five passwords, and it is well on its way to finishing off the remaining four. The logical question that remains is how, if only an administrator can run this application, does one who does not have this privilege get a hold of this information? The most common means for accomplishing this is fivefold:

1. Explicitly create an emergency repair disk. This process copies the SAM database to floppy, which can then be expanded and loaded into L0phtCrack on another machine for further analysis. 2. Look in the \\WINNT\REPAIR subdirectory for the file SAM._. This file, created after a Windows NT installation, will most likely contain only the Administrator and Guest user account information. The file is compressed and must be expanded by opening a command prompt window and typing: expand sam._ . Appli- cations such as L0phtCrack or PWDUMP can then read the user account information from this file. 3. Use a boot disk on the local machine and copy the SAM database. By booting from floppy, the OS will not have the opportunity to lock the file and cannot prohibit what would ordinarily be unauthorized access. If the SAM database resides on a FAT partition, this is extremely easy to do; an NTFS partition makes things a little more difficult (ordinarily, one cannot see the contents of an NTFS formatted partition). However, use NTFSDOS, and one can boot the machine in a DOS- like environment and access the contents of an NTFS partition. 4. Mount a drive from a non-Windows OS and access the SAM database. 5. Run getadmin.exe and become the administrator. One does not need to bother with the SAM database; once one logs out and logs back in, one has all the rights of a local administrator.

Windows NT is not without its ﬂaws, but most of what has been dis- cussed here are exploits that have been highly publicized for some time on numerous “hacker” Web sites. The security-conscious administrator will take the time to peruse CERT advisories, NTBugTraq (http://www.ntbugtraq.com), and other Web sites that contain relevant and insightful information, but time is unfortunately a precious commodity that few have lots of. And as one starts to add services (e-mail, FTP, HTTP, etc.) on top of the OS, security becomes inﬁnitely more complex, more cumbersome, and more time-intensive a process than originally anticipated.

DATA SECURITY MANAGEMENT

RECOMMENDATIONS Some of what one can do to enhance network security is delineated in the bulleted list below. This list is not all-inclusive, but it serves as an excellent foundation to enhance network security and, by its mere length, suggests what is not always obvious to management personnel — security is a full-time job!

• Utilize a password filter or some other rule-based set. Windows NT allows one to specify password aging (how long a user can keep a password before having to change it), password length, and a password uniqueness feature that prevents users from using old passwords. One can also apply a password filter that forces users to choose characters from a specified character set. • Explore password generation programs. One can assign passwords to users or let users pick their own passwords. The former option is normally only done when a user account is created; opting for the latter option can lead to problems if weak passwords are chosen. • Enforce good passwords by trying to crack them. There are plenty of third-party password management utilities (other than L0phtCrack) that allow one to do just this (e.g., http://www.netmagic.com). It might even be worth it to buy a high-end (Pentium III) machine and use it solely for this purpose. • Consider using a biometric device such as a fingerprint scanner or vocal analyzer as an additional security precaution. • Consider whether a one-time password solution can work. • Monitor logs. Unfortunately, logs become large very quickly (the request for one Web page is actually a request for all of the objects em- bedded in that page). To get through these logs, one might consider using a third-party utility that can spot unusual activity, but one should do so with extreme caution — nothing should ever replace one’s personal scrutiny of these important files. • Train personnel and ensure that if they have access to the Internet, they refrain from using corporate usernames and passwords for access to Web sites. • Separate the corporate infrastructure (intranet) from the Internet as much as possible. When allowing Internet access, try to do so through a proxy server. • Monitor alerts and warnings (CERT, NTBUGTRAQ) by subscribing to appropriate mailing lists. • Chart services versus vulnerabilities/scan ports on remote machines. At the very minimum, this will help one see where the weak spots are and what someone is likely to go after. This identification process allows one to proceed with network vulnerability testing — some- times, the best way to learn about security is to try and break into one’s own network. One will quickly come to the realization that ser-

PASSWORD SECURITY: PART 2

vices are the biggest security culprit because software is typically poorly tested; and while time and “bug fixes” may make it better by adding more features, it may just as likely introduce new problems. • Implement Service Packs and hot fixes when they become available. • Implement an Intrusion Detection System (IDES). • Packet sniffers (such as Ethernet cards in promiscuous mode) are a serious concern that need to be countered. If someone can see everything, then nothing is safe. • Do not give away too much information. Finger daemons should be disabled — the less a “hacker” knows about the users of a particular system, the more difficult it is for him to break into the system. • A homogeneous computing environment is far easier and has a lower total cost of ownership (TCO) than a heterogenerous one. If at all possible, seriously consider the migration process and what it would take to get everyone and everything operating in the same type of environment.

Jonathan S. Held is a consultant in the Washington, D.C., area, and actively engaged in E-commerce development and security. After graduating from the University of Pennsylvania with a B.A. in mathematics, he served in the United States Navy as a cryptologic ofﬁcer. He holds an M.S. in computer science from the Naval Postgraduate School. As a Microsoft Certiﬁed Professional in Windows NT Server 4.0, he co-authored the book Data Encryption Techniques with Basic and C++ and an article for Auerbach entitled “Developing a Client/Server RDBMS Using Java Servlets.”