Mitigations against critical universal cross-site scripting vulnerability in fully patched Internet Explorer 10 and 11

This week David Leo disclosed a critical universal cross-site scripting vulnerability in fully patched Microsoft Internet Explorer 10 and 11 (from now on called the UXSS leak). He notified Microsoft on October 13 last year, but Microsoft didn’t publish a patch for the problem, so he decided to go full public disclosure on the Nmap mailing list.

Every web site you visit with Internet Explorer version 10 and 11 can read the contents of cookies from other domain names that the user has stored in their web browser. An attacker can circumvent the same-origin policy via the UXSS leak. This is a primary and very important security measure in all browsers. It prevents web sites from reading each others data. And as of speaking, this protection is now completely broken in Internet Explorer 10 and 11.

HTTP header ‘x-frame-options’ to the rescue?
Reacting on the public disclosure, the security community instantly responded with a solution: apply the ‘x-frame-options’ HTTP header to mitigate the problem. This proposed solution for web sites was copied in news articles and by security experts all over the internet.

It sounds like a good solution: the UXSS leak needs an iframe in order to circumvent the same-origin policy and ‘x-frame-options’ instructs a browser that the web page that sets this header may never be loaded in a iframe. Problem solved right? Not completely.

Testing the proposed mitigation
A lot of web site owners that hadn’t implemented ‘x-frame-options’ yet, rushed to do so now. I was asked by a client to perform a security analysis on the matter and found out that the ‘x-frame-options’ header protects against HTML injection via UXSS, but not against the most dangerous risk of cross-site scripting: identify theft via stealing session cookies.

It seems that nobody on the internet had noticed that ‘x-frame-options’ didn’t protected cookies. In my research I found out that ‘HttpOnly’ protected cookies couldn’t be read via UXSS.

Web masters and security consultants need to know about this and that’s why I wrote this article. ‘x-frame-options’ and ‘HttpOnly’ to the rescue!

Exploit code for the UXSS leak
I’ve deployed the following exploit code on ‘sijmen.ruwhof.net’ that misuses the UXSS leak:

poc

Above code makes also use of ‘redirector.php’ which performs a simple redirect:

redirector

Test files that set cookies and the ‘x-frame-option’ header
The following file with name ‘setcookies.php’ is deployed on ‘dev.secundity.com’ and just sets a normal cookie and a second cookie that is secured via the ‘HttpOnly’ flag:

setcookie

Test environment
In order to make the exploit work, I’ve created a test environment that exists of a fully patched Windows 8.1 machine with Internet Explorer 11 on it:

ie11 windowsupdates

Executing the UXSS exploit code
The following screenshots will prove that the ‘x-frame-options’ header will not protect cookies from being read by JavaScript code that is running on other domain names.

To demonstrate this, we first need Internet Explorer to get two cookies from ‘dev.secundity.com’:

setcookies

After this I’m loading the UXSS exploit that is deployed on ‘sijmen.ruwhof.net’:

fiddler

The exploit executes and demonstrates that ‘sijmen.ruwhof.net’ has access to all cookies that don’t have the ‘HttpOnly’ flag set:

poc executed

What can you do with stolen cookies?
When an attacker steals a session cookie from a victim, then he can set that cookie in his browser and perform identity theft. When the attacker visits the web site from which he stole the victim’s cookie, then the web site will think that the attacker is the victim. If the victim was logged in into his account at the web site, then the attacker now is also logged in into the victim’s account, from which he can view confidential information and perform actions.

In short: a complete compromise of a single user can be the result of UXSS. If this single user has high privileges on the web site, such as administrator rights, then the security of the whole web site can be broken.

Solutions for UXSS
Web site owners can take the following mitigations against UXSS:

  1. Implement the ‘x-frame-options’ HTTP header. It is very important that all content served on the web server should have this header set. That includes ‘robots.txt’ and images.
  2. Set all cookies with the ‘HttpOnly’ flag. At least on all session cookies.
  3. Set a short timeout on sessions.
  4. When the IP address or user agent changes in a specific session, then the session should be invalidated.

Internet Explorer 10 and 11 users should:

  1. Not use Internet Explorer version 10 or 11 until Microsoft has released a patch for the UXSS leak. Use Chrome or Firefox in the meantime.
  2. If you keep using Internet Explorer:
    1. Then you should never click on links that are sent via e-mail messages.
    2. And to minimize risk, don’t log in into web sites.

And Microsoft, please release a patch soon.

This research is references by:

  1. Daniele Bellavista’s Blog

About Sijmen Ruwhof

Freelance IT Security Consultant / Ethical Hacker
This entry was posted in browser security, cross site scripting, security vulnerability, website security. Bookmark the permalink.

One Response to Mitigations against critical universal cross-site scripting vulnerability in fully patched Internet Explorer 10 and 11

  1. Bhdresh says:

    Good job… keep it up…

Leave a Reply

Your email address will not be published.