What's this bulletin about?
Microsoft Security Bulletin MS00-089 announces the availability of a patch that eliminates a vulnerability in Microsoft® Windows 2000. The vulnerability could allow a malicious user to bypass a domain account lockout policy and accomplish a brute force password-guessing attack on a local machine. 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.
What's the scope of the vulnerability?
The vulnerability could enable a malicious user to conduct a brute force password-guessing attack against a Windows 2000 machine, even if the domain administrator had set an account lockout policy. The attack could only be targeted at the account of a user who had previously logged in to the target machine, and whose login credentials were cached on the machine.
A number of factors limit the scope of this vulnerability:
- This vulnerability only affects Windows 2000 machines that are members of a non-Windows 2000 domain. Standalone Windows 2000 machines and Windows 2000 machines that were members of a Windows 2000 domain would be not affected.
- The ability to conduct a brute force password-guessing attack would be restricted to domain accounts that have previously logged in to the machine, and for which the machine has cached the user's credentials.
- If a malicious user were able to guess the user's password, he or she could only use the password to log in to the machine under attack. The domain account lockout policy would prevent the malicious user from authenticating to a domain controller or using the guessed password to authenticate to other machines in the domain.
What causes the vulnerability?
The vulnerability is caused by a flaw in the implementation of NTLM authentication in Windows 2000. When a user's credentials for NTLM authentication are cached on a local machine, Windows 2000 fails to respect the domain's account lockout policy while processing attempts to log in to that user's account.
What is an account lockout policy?
An account lockout policy allows an administrator to specify that an account is to be disabled if a person attempts to login using the wrong password an administrator-specified number of times.
Why would a domain administrator want to establish a domain policy regarding account lockout?
An administrator might want to establish a domain policy regarding account lockout to decrease the likelihood of success in using brute force password-guessing attacks to determine account passwords.
What is a brute force password-guessing attack?
A brute force password-guessing attack is an attempt by a user or a program to try multiple combinations of characters, or perhaps of words or other commonly-used strings, to find the password associated with a specific account.
What is NTLM?
NTLM is an authentication protocol that Windows NT Version 4.0 and earlier use to allow a domain controller to authenticate the identity of a user. Windows 2000 supports NTLM authentication to provide compatibility between Windows 2000 clients, servers, and domain controllers and systems running earlier versions of Windows NT.
What is a cached credential?
When a user logs onto a Windows 2000 system that is a member of a domain successfully, the operating system remembers a hashed version of the user's password so that the user can log on in the future, even if the system is unable to unable to contact the domain controller. The hashed version of the user's password and the associated information about the user's authorization are referred to as a cached credential for the user.
I have a Windows 2000 domain where authentication is performed using Kerberos rather than NTLM. Am I at risk from this vulnerability?
No. Only Windows 2000 machines that use NTLM authentication are affected. When a Windows 2000 machine authenticates to a Windows 2000 domain, it uses Kerberos authentication, and is therefore unaffected by this vulnerability.
I have Windows 2000 workstations in a mixed-mode domain. Am I at risk from this vulnerability?
Yes. In a mixed-mode domain, there are both Windows NT 4.0 and Windows 2000 domain controllers. As discussed above, the vulnerability only occurs if a Windows 2000 workstation authenticates to a Windows NT 4.0 domain controller. Because there is a possibility in a mixed-mode domain that a workstation might authenticate to a Windows NT 4.0 domain controller, this should be treated as a vulnerable configuration.
If I had never logged into a machine, could a malicious user still target that machine and attempt to guess my password?
No. This vulnerability only affects domain users' accounts that already have established cached credentials on the local machine. This means that a user would have to have previously logged onto the local machine in order for their user account to be subject to this vulnerability.
If a malicious user was able to guess a password by exploiting this vulnerability, would he or she be able to exercise that password to log onto other machines in the domain?
No. The cached credentials would allow the malicious user to log onto the target machine in violation of the account lockout policy, but the login attempts would still be reported to the domain controller, and the account lockout policy would still take effect at the domain level. So if the malicious user attempted to use the user name and guessed password to log on to another machine in the domain, he or she would be forbidden from doing so.
If an attack was successful, what privileges would the attacker obtain?
Although the attacker would be able to log on using the cached credentials, the domain account would still be locked out and the attacker would not be able to authenticate to the domain. Thus, the attacker would only have whatever access the domain account had on the local machine. If the domain account had administrative privileges on the local machine, the attacker would gain local administrator control of that machine.
Could this vulnerability be exploited remotely?
In order to exploit this vulnerability remotely, the attacker would have to gain network access to a Windows 2000 machine that was a member of a non-Windows 2000 domain, identify the username of a person who had logged into the machine, and be able to perform a password-guessing attack. If best practices were followed and NetBIOS ports were blocked at the organization's firewall, this attack could only originate from inside the organization's network. However an attack could be conducted within the confines of the organization's network.
How would I know if someone were attempting to use a brute force password-guessing attack on my domain?
If an Audit policy for Audit login event failure were enabled, all unsuccessful account login attempts would be recorded in the event logs.
Are local accounts affected by this vulnerability?
No. Only domain accounts are affected. The account lockout policy for local accounts is unaffected by this vulnerability, and is still adhered to.
Since the administrator account is never locked out, what keeps an attacker from using a brute force account password attack against it?
First, an administrator can rename the administrator account so that the name is not obvious. However, if an attacker were able to find the name of the administrator account, he or she could attempt a brute force password-guessing attack. It is always a best practice to use a long, complex password for any administrator account. In addition, in this case, it would be especially important to enable logging of unsuccessful login attempts.
Who should use the patch?
Microsoft recommends that all users who have Windows 2000 machines that are members of NT 4.0 domains consider installing the patch.
What does the patch do?
The patch eliminates the vulnerability by eliminating the implementation flaw in NTLM authentication for Windows 2000.
Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin .
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 Q274372 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.
