iDEFENSE Security Advisory 02.27.04b: Microsoft Internet Explorer Cross Frame Scripting Restriction Bypass
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