• Article

Security Bulletin

Microsoft Security Bulletin MS00-067 - Critical

Patch Available for 'Windows 2000 Telnet Client NTLM Authentication' Vulnerability

Published: September 14, 2000 | Updated: February 20, 2003

Version: 1.3

Originally posted: September 14, 2000
Re-Released: September 21, 2000

Summary

On September 14, 2000, Microsoft released the original version of this bulletin, which was revised the following day to advise of a problem with the patch. On September 21, 2000, a new version of the patch was released, and the bulletin was updated to advise of its availability. Microsoft recommends that all customers, including those who applied the original version of the patch, consider applying the new version.

The patch eliminates a security vulnerability in the telnet client that ships with Microsoft® Windows 2000. The vulnerability could, under certain circumstances, allow a malicious user to obtain cryptographically protected logon credentials from another user.

Affected Software:

  • Microsoft Windows 2000

Vulnerability Identifier: CVE-2000-0834

General Information

Technical details

Technical description:

Windows 2000 includes a telnet client capable of using NTLM authentication when connecting to a remote NTLM enabled telnet server. A vulnerability exists because the client will, by default, perform NTLM authentication when connecting to the remote telnet server. This could allow a malicious user to obtain another user's NTLM authentication credentials without the user's knowledge.

A malicious user could exploit this behavior by creating a carefully-crafted HTML document that, when opened, could attempt to initiate a Telnet session to a rogue telnet server - automatically passing NTLM authentication credentials to the malicious server's owner. The malicious user could then use an offline brute force attack to derive the password or, with specialized tools, could submit a variant of these credentials in an attempt to access protected resources.

This vulnerability would only provide the malicious user with the cryptographically protected NTLM authentication credentials of another user. It would not, by itself, allow a malicious user to gain control of another user's computer. In order to leverage the NTLM credentials (or subsequently cracked password), the malicious user would have to be able to remotely logon to the target system. However, best practices dictate that remote logon services be blocked at border devices, and if these practices were followed, they would prevent an attacker from using the credentials to logon to the target system. Best practices also strongly recommend that Windows 2000 users logon to their hosts with User level credentials, and if these practices were followed, they would prevent a malicious user from obtaining Administrator level NTLM credentials.

Frequently asked questions

What's this bulletin about?
Microsoft Security Bulletin MS00-067 announces the availability of a patch that eliminates a vulnerability in the telnet client that ships with Microsoft® Windows 2000. Microsoft is committed to protecting customers' information, and is providing the bulletin to inform customers of the vulnerability and what they can do about it.

Why was this bulletin re-released?
After releasing the patch on September 14, 2000, we found that the version we had released was actually a beta version, rather than the final version. The beta version did eliminate the vulnerability. However, if a malicious user attempted to exploit the vulnerability, it would cause the Telnet client to fail. When we discovered this error, we removed the patch and updated the bulletin, advising customers of the problem and recommending that they temporarily use a workaround. On September 21, 2000, we released the corrected version of the patch. Customers who applied the original version are not required to apply the new version, but we nevertheless recommend that they consider applying it.

What's the scope of the vulnerability?
This vulnerability could enable a malicious user to automatically request a Telnet session from an unsuspecting user's machine to the malicious user's server. As part of this session, the user's cryptographically protected NTLM authentication credentials could be passed to the malicious user's server. The malicious user could obtain these credentials and subject them to offline brute force attack to discover the user's clear-text password. This vulnerability would only provide the malicious user with the password credentials of another user. It would not, by itself, allow the malicious user to take any actions on the user's system. As discussed in detail below, following standard best practices could minimize the risk this vulnerability poses.

What causes the vulnerability?
This vulnerability occurs because the default authentication setting of the Windows 2000 telnet client is inappropriate. By default, the Windows 2000 Telnet client will participate in NTLM challenge-response authentication with the server. If a malicious user operated a Telnet server and could compel other users to initiate a session with it, he could collect the NTLM responses, and then use these to potentially authenticate to the unsuspecting user's computer.

What's Telnet?
Telnet is a member of the TCP/IP family of protocols, and allows a user to establish a remote terminal session on a telnet server. The protocol supports only alphanumeric terminals - that is, it doesn't support mice and other pointing devices, nor does it support graphical user interfaces. Instead, all commands must be entered via the command line.

What's NTLM?
NTLM (NT LanMan) is an authentication process that's used by all members of the Windows NT family of products. Like its predecessor LanMan, NTLM uses a challenge/response process to prove the client's identity without requiring that either a password or a hashed password be sent across the network.

How does challenge/response work?
When the authentication process begins, the user's system (client) sends a login request to the telnet server. The server replies with a randomly generated "token" (or challenge) to the client. The client hashes the currently logged-on user's cryptographically protected password with the challenge and sends the resulting "response" to the telnet server. The telnet server receives the challenge-hashed response and compares it to what it knows to be the appropriate response. (The server takes a copy of the original token - which it generated - and hashes it against what it knows to be the user's password hash from its own user account database.) If the received response matches the expected response, the user is successfully authenticated to the host.

Is my password being sent across the network during NTLM authentication?
No. NTLM authentication does not send the user's password (or hashed representation of the password) across the network. Instead, NTLM authentication utilizes challenge/response mechanisms to ensure that the actual password never traverses the network.

What's wrong with the Telnet client in Windows 2000?
The default authentication mechanism for the Windows 2000 telnet client is NTLM. When a telnet session is initiated with a remote NTLM enabled telnet server, the telnet client will automatically initiate a challenge/response logon process and send NTLM authentication credentials to the remote server.

How could a malicious user exploit this vulnerability?
A malicious user could create an HTML formatted document or e-mail message, that when viewed by the recipient, would automatically request a telnet session to the malicious user's server. Because NTLM credentials would be sent to the malicious user's server by default, the malicious user could capture the unsuspecting user's authentication credentials.

Once the malicious user obtained the NTLM response, what could he do with it?
NTLM hashes (or challenge/response pairs) could be fed into a program that performs brute force password guessing. The "cracking" program would iteratively try all possible passwords, hashing each and comparing the result to the hash that the malicious user obtained. When it located a match, the malicious user would know that the password that produced the hash is the user's password.

If the true password hash is never passed to the server over the network, how can a malicious user "crack" my password when they only have the hashed response?
In the malicious telnet server scenario, the telnet server would maintain a copy of both the server-issued challenge and the response received from the client. A brute force password-cracking program could hash the results of all the possible password hashes, derived above, with the server issued challenge. The resulting value is compared against the response hash obtained by the malicious person. If the response hash (captured from the client) matches the hash value derived from the cracking program, the malicious user would know the password used to produce the initial hash is the user's password. Because the malicious person controls the telnet server in this scenario, he could adjust the mechanism used to generate the tokens. Instead of sending the client a randomly generated token, a specially created telnet server application could respond with a specific known token that would aid the malicious user in performing offline brute-force password "cracking" efforts.

Does the malicious user need to crack my password hash to login to my host?
No. The malicious user could use the challenge response hashes obtained as described above to respond to challenges received from your host; however, specialized tools would be required for this to occur.

What could a malicious user do if he cracked my password?
Determining the clear-text value of a user password is not enough to allow the malicious user to logon to your system. In order for another user to logon to your system, they must first connect to your computer via a remote login service. However, he could only log on to your machine if he could reach it - but best practices strongly recommend that these remote login services be blocked at Internet border devices (routers and firewalls).

What are examples of remote login services?
Some popular remote login services for Windows 2000 may include (but are not limited to) any of the following:

  • NetBIOS over TCP/IP - also known as CIFS/SMB (tcp 139, tcp 445)
  • Telnet (tcp 23, or a user defined port)
  • Terminal Server (tcp 3389)
  • SQL Server (tcp 1433 or a user defined port)
  • FTP (tcp 20,21, or a user defined port)
  • HTTP (tcp 80, or user defined port)

Best Practices dictate that network administrators block incoming requests for these services at their border routers and firewalls. Individuals and home users can block inbound access to these ports via IPSec filtering on their own systems.

Could I protect against this vulnerability by blocking outbound telnet sessions at my router or firewall?
The telnet protocol can be manipulated to use any tcp port number, effectively bypassing standard packet filtering mechanisms designed to block outbound telnet sessions. Since this vulnerability can be exploited via any number of applications that parse and render html code, Windows 2000 users are urged to apply this patch to all of their Windows 2000 hosts.

What about Windows NT4?
The telnet client in NT4 does not utilize NTLM authentication and is therefore not susceptible to this vulnerability.

Who should use the patch?
Microsoft recommends that all Windows 2000 users consider installing the patch. This patch may be applied to both Windows 2000 hosts with or without Service Pack 1.

What does the patch do?
The patch eliminates the vulnerability by presenting a warning message to the user before automatically sending NTLM credentials to a server residing in an un-trusted zone. The user will be required to approve the telnet session before NTLM credentials will be supplied to the remote server. Automatic NTLM authentication will only occur when the telnet server resides in the "Local intranet" or "Trusted sites" zone and the zone's policy is set to allow "automatic logon with user name and password".

What are the default "automatic logon" settings for the Local intranet and Trusted sites zones?
Automatic logon with user name and password is enabled, by default, in the Medium, Medium-low, and Low security settings. This setting is disabled, by default, in the High ecurity setting. The Local intranet zone is configured, by default, to use the Medium-low security setting, and the Trusted sites zone, is configured, by default, to use the Low security setting.

I don't want my Telnet client to ever participate in NTLM authentication. How can I disable default NTLM authentication altogether?
You may change the behavior for telnet authentication so that it will not pass NTLM credentials under any conditions. This workaround is independent of the patch associated with this Bulletin. To determine what form of authentication you are currently using, perform the following steps:

  • Type 'telnet' at a command prompt.
    • Type 'display' at the telnet prompt.
    • A value of 'Will Auth (NTLM Authentication)' means telnet will use NTLM authentication by default.
    • A value of 'Not Auth (NTLM Authentication)' means telnet will not use NTLM authentication.

To disable NTLM authentication, perform the following steps:

  • Type 'telnet' at the command prompt.
    • Type 'unset ntlm' and hit Enter.
    • Type 'quit' to exit telnet and save your preferences.

How does this patch affect third party telnet applications that utilize NTLM authentication?
This patch only impacts the behavior of the built-in Windows 2000 telnet client. This patch does not affect third party telnet clients.

Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin.

I installed the original version of the patch. What should I do?
We recommend that you consider installing the new version. The original version eliminated the vulnerability, and allowed legitimate Telnet connections to work normally. However, in the event that a malicious user tried to exploit the vulnerability, the original version of the patch would cause the Telnet client to fail.

How do I use the patch?
The Knowledge Base article contains detailed instructions for applying the patch to your site.

How can I tell if I installed the patch correctly?
The Knowledge Base article provides a manifest of the files in the patch package.The easiest way to verify that you've installed the patch correctly is to verify that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article.

What is Microsoft doing about this issue?

  • Microsoft has delivered a patch that eliminates the vulnerability.
  • Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerability and the procedure to eliminate it.
  • Microsoft has sent copies of the security bulletin to all subscribers to the Microsoft Product Security Notification Service, a free e-mail service that customers can use to stay up to date with Microsoft security bulletins.
  • Microsoft has issued a Knowledge Base article explaining the vulnerability and procedure in more detail.

Where can I learn more about best practices for security?
The Microsoft TechNet Security web site is the best to place to get information about Microsoft security.

How do I get technical support on this issue?
Microsoft Product Support Services can provide assistance with this or any other product support issue.

Patch availability

Download locations for this patch

  • Microsoft Windows 2000:
    https://www.microsoft.com/download/details.aspx?FamilyId=0D0032E7-259D-4F68-BF08-B0A7CAA1FD1C&displaylang;=en

    Note: Customers who applied the original version of the patch should consider applying the current version. The original version eliminated the vulnerability; however, if a malicious user attempted to exploit the vulnerability, the patch caused the Telnet client to fail. The current version of the patch eliminates the vulnerability without interfering with Telnet connections.

    Note: This patch will also be included in the next Service Pack for Windows 2000. It can be applied to computers with or without Service Pack 1.

Additional information about this patch

Installation platforms: Please see the following references for more information related to this issue.

  • Microsoft Knowledge Base (KB) article Q272743, https:

Other information:

Acknowledgments

Microsoft thanks DilDog of @Stake Inc. (www.atstake.com) for reporting this issue to us and working with us to protect customers.

Support: This is a fully supported patch. Information on contacting Microsoft Product Support Services is available at </https:>https:.

Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.

Disclaimer:

The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

Revisions:

  • September 14, 2000: Bulletin Created.
  • September 15, 2000: Bulletin re-released to advise of problem with patch.
  • September 21, 2000: Bulletin re-released to advise of availability of new patch.
  • February 20, 2003: Bulletin modified to update download location for patch.

Built at 2014-04-18T13:49:36Z-07:00 </https:>