Internet Explorer Cached Web Credentials vulnerability (Patch available) ------------------------------------------------------------------------ SUMMARY Microsoft has released a patch that eliminates a security vulnerability in Microsoft Internet Explorer. Under a certain set of conditions, the vulnerability could enable a malicious user to obtain another user's userid and password to a web site. DETAILS Vulnerable systems: - Microsoft Internet Explorer 4.x - Microsoft Internet Explorer 5.x prior to version 5.5 Immune systems: - Microsoft Internet Explorer 5.5 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. Patch Availability: - <http://www.microsoft.com/windows/ie/download/critical/q273868.htm> http://www.microsoft.com/windows/ie/download/critical/q273868.htm 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 <http://www.microsoft.com/technet/support/kb.asp?ID=273868> Q273868. As discussed in Affected Software Versions, this vulnerability does not affect IE 5.5. 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. Please note that the fix for this issue will be included in IE 5.01 SP2. 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 us 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 is 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 does not lie in the site that they are sent to, it lies in the way they are sent. By initially logging onto the site via an SSL-protected page, you have 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 is 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 is 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 have not 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 <http://mspress.microsoft.com/prod/books/4293.htm> 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 <http://www.microsoft.com/technet/support/kb.asp?ID=273868> 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 <http://www.microsoft.com/technet/support/kb.asp?ID=273868> Q273868 provides a manifest of the files in the patch package. The easiest way to verify that you have 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. -- Eko Sulistiono MIKRODATA & AntiVirus Media Web: http://www.mikrodata.co.id/ WAP: http://www.mikrodata.co.id/wap/index.wml This message contains no viruses. Guaranteed by AVP. ------------------------------------------------------------------------ Forum Komunikasi Penulis-Pembaca MIKRODATA (FKPPM) Informasi : http:[EMAIL PROTECTED] Arsip : http://www.mail-archive.com/forum%40mikrodata.co.id/ WAP : http://mikrodata.co.id/wap/index.wml Milis ini menjadi kontribusi beberapa rubrik yang diasuh tim MIKRODATA. Termasuk rubrik-rubrik yang ada di media lain. Memakai, Menyebarluaskan, dan Memperbanyak software bajakan adalah tindakan kriminal. Please check with the latest AVP update before you ask about virus: ftp://mikrodata.co.id/avirus_&_security/AntiViral_Toolkit_Pro/avp30.zip
