Microsoft Internet Explorer Cross Frame Scripting Restriction Bypass iDEFENSE Security Advisory 02.27.04b: http://www.idefense.com/application/poi/display?id=77&type=vulnerabiliti es February 27, 2004 I. BACKGROUND Internet Explorer is a set of core technologies in Microsoft Windows operating systems that provide web browsing functionality. Further information is available at http://www.microsoft.com/ie/. II. DESCRIPTION Exploitation of an access validation error within Microsoft Corp.'s Internet Explorer web browser allows remote attackers to bypass the restrictions imposed on cross frame scripting. The problem specifically exists due to invalid restrictions within the event handling routines of Internet Explorer. According to Microsoft Knowledge Base Article 167796 (http://support.microsoft.com/support/kb/articles/Q167/7/96.asp) access between frames located on different domains should be restricted. However, it is possible to bypass this restriction by placing malicious JavaScript outside the defined frameset within the parent HTML and forcing the target frameset to maintain focus. The example below will display the captured keystrokes from the iDEFENSE registration page in the status bar of the frameset. <html> <head><title>IE Cross Frame Scripting Restriction Bypass Example</title> <script> var keylog=''; document.onkeypress = function () { k = window.event.keyCode; window.status = keylog += String.fromCharCode(k) + '[' + k +']'; } </script> </head> <frameset onLoad="this.focus();" onBlur="this.focus();" cols="100%,*"> <frame src="http://www.idefense.com/register.jsp"; scrolling="auto"> </frameset> </html> Keyboard events appear to be the only events that are leaked across framesets. The malicious JavaScript can monitor all keystrokes typed within the targeted frameset and could be used to transmit the keystrokes to a remote location. Such information leakage could include confidential information such as login credentials and credit card information. The technique does not require an attacker to replicate the functionality of a third party web site as the victim will be interacting with the real site. III. ANALYSIS Successful exploitation requires that an attacker convince a user to follow a link allowing for the target site to be contained within a malicious frame. A victim would be alerted to this attack by noticing an incorrect URL in the address bar or improper name on the SSL certificate. Therefore, chances of success can be greatly increased when combining exploitation of this vulnerability with the Internet Explorer URL Canonicalization Vulnerability (MS04-004). Successful exploitation allows an attacker to obtain confidential data, which could lead to further compromise. IV. DETECTION iDEFENSE has confirmed the existence of this vulnerability in Internet Explorer 5 and 6 running on Windows 2000 Professional and Windows XP Professional. Internet Explorer 5 running on Windows 98 is reported not to be vulnerable. V. WORKAROUND Website administrators can prevent exploitation of this kind on their own site by ensuring that the site is not encapsulated within a frameset. The following snippet of JavaScript can be utilized to accomplish this: if (top != self) { top.location=self.location; } VI. VENDOR RESPONSE Microsoft has not categorized this issue as a vulnerability. However, they have stated that a bug will be opened for the issue and the functionality will be changed in a future service pack. Their reasoning for this assessment is provided below. "We've reviewed this issue and determined that it isn't itself a security vulnerability but could be used in a spoofing scenario. In this particular spoofing scenario, similar to most spoofing attacks, a user must be enticed into providing personal information without verifying the identity of the Web site collecting the information. Generally, customers can protect themselves from these types of attacks by verifying that the Web sites they are providing information to are the actual Web sites they intend to interact with. Specifically, to be protected from this spoofing attack, customers should take the following steps: - First, verify that MS04-004 is installed. This will make certain that customers have the most up-to-date IE. Moreover, MS04-004 provides a fix that ensures customers can verify which Web sites they are visiting by simply viewing the address bar. - Second, and for customers who have not updated their computers with MS04-004, customers can double check the identity or legitimacy of the Web site they are viewing before inputting personal information by double clicking on the yellow padlock icon at the bottom right corner of the screen. This will reveal the security certificate for the visited Web site and verify its identity. Customers should review the best practices for safe browsing available at http://www.microsoft.com/security/incident/spoof.asp And finally, as always, Microsoft recommends that all customers visit and follow the guidance on www.microsoft.com/protect" iDEFENSE agrees with the technical aspects of the statement made by Microsoft. However, we feel that the issue outlined in this advisory can be exploited in such a way that would make it difficult for an end user mitigate the potential risk through visual inspection of the address bar. Potential avenues of attack include: - Utilizing cybersquatted URLs similar to the target domain - Creating the frameset in a popup window that uses scripting to avoid displaying the address bar - Masking the true URL using the Internet Explorer URL Canonicalization Vulnerability (MS04-004 - http://www.microsoft.com/technet/technet/security/Bulletin/MS04-004.asp) The final avenue of attack presents the greatest risk given the fact that a patch for MS04-004 was only recently released (February 2, 2004). VII. CVE INFORMATION A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not been assigned yet. VIII. DISCLOSURE TIMELINE February 4, 2004 Vulnerability acquired by iDEFENSE February 10 2004 Initial vendor notification February 10 2004 Initial vendor response February 11, 2004 iDEFENSE clients notified February 27, 2004 Public disclosure
