• Article

Security Bulletin

Microsoft Security Bulletin MS00-076 - Critical

Patch Available for 'Cached Web Credentials' Vulnerability

Published: October 12, 2000

Version: 1.0

Originally posted: October 12, 2000

Summary

Microsoft has released a patch that eliminates a security vulnerability in Microsoft® Internet Explorer. Under a daunting set of conditions, the vulnerability could enable a malicious user to obtain another user's userid and password to a web site.

Affected Software:

  • Microsoft Internet Explorer 4.x

  • Microsoft Internet Explorer 5.x prior to version 5.5

    Note: Internet Explorer 5.5 is not affected by this vulnerability. Customers using IE 5.5 do not need to take any action.

General Information

Technical details

Technical description:

When a user authenticates to a secured web page via Basic Authentication, IE caches the userid and password that were used, in order to minimize the number of times the user must authenticate to the same site. By design, IE should only send the cached credentials to secured pages on the site. However, it will actually send them to non-secure pages on the site as well. If a malicious user had complete control of another user's network communications, he could wait until another user logged onto a secured site, then spoof a request for a non-secured page in order to collect the credentials.

The vulnerability does not provide a means by which the malicious user could force the other user to log onto a secure page of his choice, and could only be used to reveal credentials that had been cached during the current IE session

Frequently asked questions

What's this bulletin about?
Microsoft Security Bulletin MS00-076 announces the availability of a patch that eliminates a security vulnerability in Microsoft® Internet Explorer. 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?
This vulnerability could, under certain conditions, enable a malicious user to learn another users' userid and password for a particular web site. With this information, the malicious user could log onto the web site as the other user, at which point he could take any action on the site that the user was capable of taking. The vulnerability is subject to several significant restrictions:

  • The malicious user would need to already have complete control over the user's communications with the web site - that is, he would need the ability to read all data on the network medium, as well as the ability to send data on it.
  • The malicious user could only recover the userid and password for a site that the user had visited during his current browsing session.

What causes the vulnerability?
The vulnerability results because Internet Explorer will forward cached credentials to a web site over an unsecured session, even if the credentials were initially exchanged over a secured one. The vulnerability only affects credentials exchanged via Basic Authentication, and only ones that have been cached during the current web session.

What do you mean by "cached credentials"?
Let's discuss the two terms separately:

  • By "credentials", we mean whatever information is used to identify a user when he logs onto a web site. For instance, suppose you have an online banking account, and it requires you to enter a userid and password when you initially access the site. The userid and password would constitute your credentials.
  • By "cached", we mean that the credentials have been temporarily saved within IE to eliminate the need for you to re-enter them multiple times during the same session. When you provide your logon credentials for a web site, IE stores them in a cache. If the web site asks for your credentials again, IE automatically sends the cached copies, rather than making you enter them again. When you close IE, it clears the cache.

What's wrong with the way IE handles cached credentials?
If the credentials were initially exchanged via a secure connection - that is, if the user connected to an SSL-protected page and then entered his userid and password - IE should refuse to ever send them via an unsecured connection. However, under some conditions, it's possible to cause IE to send them anyway.

Do you mean that IE would send my cached credentials to any site that asked for them?
No. Even with the vulnerability, IE will only send cached credentials to the site to which they belong. That is, if you log onto both Web Sites A and B during a single IE session, IE will not send your Web Site A credentials to Web Site B. However, it will send the credentials you entered via an SSL-protected page on Web Site A to an unsecured page on Web Site A.

Why is this a security vulnerability? After all, the credentials are still being sent to the site that they belong to.
The problem doesn't lie in the site that they're sent to, it lies in the way they're sent. By initially logging onto the site via an SSL-protected page, you've indicated that this is information worth protecting, so IE should not downgrade the protection by subsequently sending it in plaintext. If a malicious user were able to monitor your network connection, it would be possible for him to learn your userid and password when they were passed to the non-secure page. He could then use the userid and password to log onto the site as you, at which point he could do anything on the site that you have permissions to do.

How difficult would it be for a malicious user to monitor my network connection?
It would be extremely difficult, but not impossible. The malicious user would need to either have physical access to your network connection, or extremely favorable network geometry. That is, he would either need to be able to tap into your network, or position himself in a chokepoint through which all of your data must pass.

Suppose a malicious user could monitor my network connection. Could he force me to visit a site of his choice and enter my userid and password?
No. He would need to either use social engineering to get you to visit a particular site (that is, he would need to trick you into visiting it) or wait until you visited the site on your own accord.

Suppose I did log onto a secure page on a web site. Could the malicious user force me to visit a non-secure page on the same site, and thereby reveal my userid and password?
Yes. If the malicious user were able to manipulate your network communications, he almost certainly could spoof a request from you for a non-secure page on the site. Once the page replied to you, IE would pass the credentials in plaintext.

What if I stopped IE and restarted it?
Each time you close IE, it erases all cached credentials. If you logged onto a web site via a secure page, then closed IE and subsequently restarted it, the vulnerability could not be exploited.

Is there any relationship between the cached credentials at issue here and my userid and password for my Windows NT or Windows 2000 network?
The credentials are completely different. This vulnerability provides no way to compromise a user's Windows NT or Windows 2000 credentials. With that said, though, it's possible for the credentials to have the same value. That is, if your Windows 2000 userid is "JohnSmith" and your password is "Q23d4_)l", and your online bank lets you choose your userid and password there, it's certainly possible for you to choose "JohnSmith" and "Q23d4_)l". However, security best practices always recommend that you use always use unique passwords.

I run a web site, and would like to protect visitors to my site even if they haven't applied the patch. Is this possible?
Yes. IIS supports the concept of realms as a way of naming various portions of a web site for security purposes. If a user authenticates to a page in one realm, then moves to a different realm within the site, IIS will prompt the user for a userid and password. If no authentication is required in that realm IIS will not prompt the user. An excellent description of realms is provided in Designing Secure Web-based Applications for Windows 2000, page 112.

Who should use the patch?
Microsoft recommends that all IE users consider installing the patch.

What does the patch do?
The patch eliminates the vulnerability by changing how IE handles cached credentials. If they initially were sent to the site via a secured page, IE will not send them to a non-secure page.

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

How can I tell if I installed the patch correctly?
The Knowledge Base article Q273868 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 Q273868 explaining the vulnerability and installation procedures 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 Servicescan provide assistance with this or any other product support issue.

Patch availability

Download locations for this patch

  • https:

    Note: The patch requires IE 5.01 SP1 to install. Customers who install this patch on other versions may receive a message reading "This update does not need to be installed on this system". This message is incorrect. More information is available in KB article Q273868.

    Note: As discussed in Affected Software Versions, this vulnerability does not affect IE 5.5.

    Note: Per the normal security support policy for IE, security patches for Internet Explorer version 4.x are no longer being produced. Microsoft recommends that IE 4.x customers who are concerned about this issue consider upgrading to either IE 5.01 SP1 or IE 5.5.

    Note: The fix for this issue will be included in IE 5.01 SP2.

Additional information about this patch

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

  • Microsoft Knowledge Base (KB) article Q273868, </https:>https:

Vulnerability Identifier: CVE-2000-0982

Other information:

Acknowledgments

Microsoft thanks  ACROS Security 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:

  • October 12, 2000: Bulletin Created.

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