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 oth- er factors that are highlighted later in this article. Suffice it to say that the password implementation mechanism in Windows 95 and 98 (pass- words 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. 04/00 Auerbach Publications © 2000 CRC Press LLC 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 in- formation — 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 Auerbach Publications © 2000 CRC Press LLC PASSWORD SECURITY: PART 2 The file is encrypted with a key derived from the user’s password us- ing 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 cur- rently 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 applica- tion 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 us- er/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 for- mat almost identical to that produced by PwlCrack.exe. Auerbach Publications © 2000 CRC Press LLC DATA SECURITY MANAGEMENT EXHIBIT 3 — Using the Microsoft Password List Editor EXHIBIT 4 — Output of PwlCrack.exe Auerbach Publications © 2000 CRC Press LLC © 2000 CRC Press LLC Auerbach Publications PWLTool v. 6.0. Graphical User Interface (GUI) for Recovering PWL v. PWLTool EXHIBIT 5 — Cached Passwords 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 do- main 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 Auerbach Publications © 2000 CRC Press LLC PASSWORD SECURITY: PART 2 WINDOWS NT Average day-to-day computer users will most undoubtedly not favor us- ing 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.