The Independent Newspaper for Windows NT Enterprise Computing [ENT logo] [ENT Archive Icon] ------------------------------------------------------------------------ [Archive Search] [Buyers Guide] Backward Compatibility Keeps NT 5.0 Vulnerable [Downloads] [Hot Sites] Stephen Swoyer [Papers/Reports] [Reader Surveys] September 10, 1997 [Resource Guide] [ENT Staff] As details of Windows NT 5.0's new distributed security model emerge, industry [Readers Choice Winnners] watchers -- hackers and analysts alike -- are saying that despite Windows NT 5.0's [Media Kit] bevy of new security features, the overall success of Microsoft's flagship operating [Subscribe] system in locking intruders out could ultimately hinge on the question of backward [Home] compatibility. Windows NT currently provides two types of authentication, LAN Manager (LM) challenge/response authentication and Windows NT challenge/response authentication. LM support is provided so that OS/2 LAN Manager servers and clients can authenticate and be authenticated by Windows NT clients and servers. Straight out of the box, Windows NT 4.0 is configured to provide both an LM challenge/response and a Windows NT challenge/response to prospective clients and servers. Despite the implementation of a new Kerberos 5- and x.509 certificate-based security model, Windows NT 5.0 will also maintain support for the LM protocol to provide backward compatibility with OS/2 LAN Manager. In July, a new Windows NT hacker-engineered crack called l0phtcrack 1.5 appeared. I0phtcrack 1.5 differs from previous Windows NT cracks because, rather than exploiting an API in the Windows NT SAM, as in the case of PWDUMP, or a broken system call, as in the case of GETADMIN, l0phtcrack plays on LM's relatively weak password structure. Because LM breaks a password into two seven-character pieces, assigning null characters to fill the space if a user has chosen a password smaller than 14 characters, "Mudge" -- the hacker-author of l0phtcrack -- claims that it's easy to breach. Because LM authentication is necessary only in environments that still have OS/2 LAN Manager in place, most users can safely configure Windows NT to issue only a Windows NT challenge/response. A patch posted on Microsoft's FTP site supports a new registry key that can disable LM authentication and allow clients to be configured for only Windows NT authentication (ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/NT40/hotfixes-postSP3/lm-fix/). However, the fix requires some manual changes to registry settings -- and an environment without any LM dependencies. Windows NT Service Pack 3 brought with it the ability to encrypt the Windows NT Security Accounts Manager (SAM) using strong encryption of 128 bits, but that only solves one potential point of entry. "Even if you have installed Service Pack 3 and enabled SAM encryption, your passwords are still vulnerable if they go over the network," Mudge writes in a l0phtcrack advisory. However, before using l0phtcrack 1.5, a potential intruder must first gain access to the network itself. Service Pack 3 also introduced the Server Messaging Block (SMB) protocol, designed to beef up LM authentication by supporting a mutual authentication feature in which both the client and the server generate an SMB key that is mutually authenticated at both ends. SMB was designed to prevent man-in-the-middle attacks, but Mudge writes that "with only trivial modifications" to l0phtcrack, "you can break the SMB signing options and play man-in-the-middle attacks." Several calls placed to Microsoft about this potential problem were not returned. "Historically, the LAN or network operating systems have been vulnerable to one particular issue, which is nonsecure network authentication," observes Robert Kane, president of Intrusion Detection Inc., a security software and consulting company based in New York. Past Windows NT hacks involved logging in as an administrator and dumping the password file from the SAM and then running a dictionary attack on it. Network-based cracks such as l0phtcrack 1.5 don't require administrative access in order to work, however. "What these guys are doing is the same kind of [dictionary attack] password-cracking for passwords that get transmitted over the wire," Kane comments. "We have not tested it in our test lab, but it does certainly sound feasible." "Going forward, Windows NT will always have the capability to be backward-compatible with LAN Manager," says Rob Enderle, senior analyst with analyst firm Giga Information Group (Santa Clara, Calif.). "The client can decide whether or not to turn that compatibility on and off, and most sites have gotten rid of LAN Manager." The problem, Enderle says, is one of education: Administrators simply aren't aware of the danger posed by the legacy LM authentication protocol. "I'm not convinced everybody knows to turn this off," he asserts. "Even though it's posted up and down on Microsoft's Web site, people don't go looking for this stuff." Although Microsoft's fix will solve the problems of most IT managers, administrators of environments with LAN Manager still in the mix are out of luck. Microsoft's LM patch poses a Catch-22 of sorts: In disabling LM authentication and shoring up security, LAN Manager servers are locked out of the solution. "Basically, administrators will have to change all of their clients over from LAN Manager to NT authentication," comments Enderle. "But if you have a LAN Manager server, there's no way to update it." But that's not all. According to Microsoft, under certain circumstances, Windows 3.1x and MS-DOS LanManager 2.x clients operating in an environment in which the fix has been applied will not be able to connect to a Windows NT server. "If the last password change came from a Windows for Workgroups or MS-DOS LanManager 2.x or earlier client, the data needed for Windows NT authentication will not be available on the domain controller, and a client selecting level 2 will not be able to connect to Windows NT-based servers," states a Knowledge Base article on the FTP site. Analysts speculate that the LM security problem could be just enough to cause many users of OS/2 LAN Manager systems to make the switch to a Windows NT desktop environment. "What they're saying is if you want absolute security based on the bulletproof security built into NT, you should be using NT, but if you're using Win95 or Windows 3.1, you shouldn't expect to have the same level of security," says Kane. "If you want better security, migrate to the industrial-strength product." ------------------------------------------------------------------------ Comments to Al Gillen, Editor-in-Chief | Last updated January 1998 | Copyright © 1996, 1997, 1998 Boucher Communications Inc.