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.