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.
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
Example 3. go function
The PHP file contains the following code:
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 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 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.
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:
- 1006472 – Microsoft Internet Explorer Same Origin Policy Bypass Vulnerability
Analysis by Henry Li and Rajat Kapoor