Lucene search

K
seebugRootSSV:92802
HistoryMar 20, 2017 - 12:00 a.m.

Microsoft Internet Explorer Elevation of Privilege Vulnerability (CVE-2017-0154)

2017-03-2000:00:00
Root
www.seebug.org
43

EPSS

0.003

Percentile

71.8%

Original link: a Broken Browser

Original author: Manuel Caballero

Translation: Holic (know Chong Yu 404 security lab)

Today we know from Internet Explorer since the birth there has been function. This feature allows the Web Developer instance of the external object, and therefore be the attacker to abuse. Can you guess what we’re saying is what characteristics? That is ActiveXObject .

Even now it is subject to many limitations, we have not then happily show the Excel spreadsheet, but it still has a lot of play. We will build a reliable UXSS/SOP(same-origin policy around, it will allow us to access any of the domain stuff, of course including cookies, and you can imagine the stuff.

However, the bug hunter, do not think that ActiveXObject is another UXSS only, his attacker is a perfect element, because it has numerous vulnerabilities, we will in this article mentioned below. I really suggest you study out of this object, you unexpectedly discover a lot of new things.

A variety of rendering HTML containers

In the browser rendering the HTML there are several ways, my first thought is an IFRAME tag, and we use the OBJECT even EMBED tag can do the same thing.

Actually, there are some objects that allow us to logically render the HTML, but it is not visible. For example: implementation. createDocument, and implementation. createHTMLDocument even XMLHttpRequest can return the document object instead of text/xml.

These HTML documents with iframes/windows in a document have many similarities, but does not include all of the content. For example, some of which can’t execute the script, the other without any of the associated window, so they are missing like the window. open this method. In other words, these documents have their limitations.

But Internet Explorer there are several rendering HTML, my favorite is by means of an ActiveXObject to instantiate a "htmlFile"in. This type of document also has its limitations, but at least be able to run the script. Consider the following script.

javascript doc = new ActiveXObject("htmlFile");

This ActiveXObject is created like the WebBrowser control something so basic is similar to an iframe, and==and return its document object references==。 In order to access the window object, we have to use before the parentWindow or Script, because here does not support the defaultView of.

``javascript win = doc. defaultView; // Not supported.

win = doc. Script; // Returns the window object of doc. win = doc. parentWindow; // Returns the window object of doc. ``

I was the “Script” of the fans, so I used this method. By the way, I’m very curious about this ActiveXObject location is what.

It was fun! For me, the next question Is: this document of the window object is not, and we are treated to the same object? I mean, it has a real window or other parent element/Creator sharing.

``javascript // Remember: // win is the window object of the ActiveXObject. // window is the window object of the main window.

alert(win == window); // false ``

Thus, we conclude that the ActiveXObject the window is different from the main window, which means that it has its own window. I want to know now who is the top of it(top). Did ActiveXObject think of it at the top?

Wow!winthink it belongs to the top of the top, I can not help but imagination is. It is perhaps the presence of XFO bypass vulnerability, or to allow insecure requests for SSL top without SSL on. Write down these ideas! At least this is my habit: the fun things that come to mind, I will immediately notice, so I can continue to focus the original goal, and not let these thoughts fade away in the brain’s gray matter in the ocean.

Okay, I’m curious about another thing is this a document of the domain. So, what it really is?

alert(doc. domain); // The same domain as the top page

It returns the main window to the same domain, it’s no big deal, but worth more testing. Thoughts in the mind flow.

Recovery document. the domain of the top property

On this point, my question first is: if we change the home page’s base href, and then instantiate this ActiveX, what will happen? It will have pages with the same domain or from the base href domain?

This idea can not be achieved, but when the object is created, do not underestimate the base href, because it has produced wonders, and the future may be used to. Look at me recently is how to achieve SOP bypass.

In short, I tried another option: in a different domain in an iframe to create a ActiveXObject on. That is, the same code can now be from a different domain in an iframe implementation.

``

``

I was surprised ActiveXObject use the top of the top of the domain instead of the iframe created. Bingo!

[ IE11 Proof of Concept ]

Of course, retrieve the page domain is not the complete SOP bypasses, but it is a hard evidence, indicating we are dealing with a“confusing”the browser. Problem advancing to the deep, until IE give up. With a little JavaScript, with passion and persistence, we will do.

Pass a reference to the top

Our goal now is with the ActiveXObject shared top-level window reference to see if it has the right to access. If it the document. domain and the top of the same, it should be able to access! But here there is also a challenge: from the browser’s point of view, this ActiveXObject is not fully initialized. This means that we cannot create a variable, it cannot change any member values. Like a frozen object, you can not to delete/change anything.

javascript oc = new ActiveXObject("htmlFile"); win = doc. Script; win. myTop = top; // Browser not initialized, the variable is not set win. execScript("alert(win. myTop)"); // undefined

In a conventional window, it is supposedly effective, and the use of ActiveXObject is not, unless we use the document. open the initialization. The problem is, if we initialize the object, IE will put it in the domain settings are correct, ignore our little trick. Then take a look at this. and figure out what I mean.

javascript doc = new ActiveXObject("htmlFile"); alert(doc. domain); // alerts the top of the domain (SOP bypass) doc. open(); // Initialize the document alert(doc. domain); // alerts the iFrame domain (No more SOP bypass)

Then how we will top-level window object is passed to the ActiveXObject? Carefully think about. Each window object has a very special place that it is in any other place are writable. What is it? opener now! Yes, the window. opener, my friend, to try it!

javascript doc = new ActiveXObject("htmlFile"); win = doc. Script; win. opener = top; win. execScript("alert(opener. document. URL)"); // Full SOP bypass

[ IE11 Proof of Concept ]

Yes! Use opener skills effective. Now, whether our domain, we can access to the top of the document. We of the iframe may be in another iframe, or like a Russian doll, like unlimited nested with a different domain, but it can still access the top(top)。 This is power!

Then, we get a valid UXSS, but there is still a problem: it needs to be loaded into the iframe, I don’t think that the target site would be so generous in their iframe rendering our little trick, right? But the thought of today’s show banner: we in the iframe is rendered, and they can access the top element! This means Facebook ads, Yahoo! Advertising and any in the iframe run in the untrusted content can access the main page. If we use Facebook, the ads can be on our behalf to publish content, access to our contacts and cookies without restrictions.

We should be more further, to find one without the aid of outside method to obtain the website’s cookies. How do we make it in any of the non-cooperation of the site effective? We can in no iframe in the site to achieve? Many of the solutions appear in my mind, and the most simple is: **[redirect] + [thread-blocks] + [inject]**it. This technique is super easy, but it’s worth a little explanation.

Arbitrary content injection

There is a target website, the chance to load before, for any window/iframe to inject HTML/Script of the method, while ignoring its domain. For example, suppose we open a with the server to redirect to PayPal on the new window. In the redirect to happen before we can still access the window, but once the redirect to load a new URL, we cannot access, right? In fact, when the redirection occurs, IE render the new content before the destruction of the window of each element.

However, if we are in page injected a single element, at the redirection happens before? More, after the injection, we block the thread, and don’t give IE a chance to destroy the object, but let the redirect happen, what will happen? The new pages will retain the Old of the injected content, because IE can’t delete it.

In this case, we use alert as a thread interceptor, of course, there are other ways to achieve the same effect. Let us recall in writing code before you need to do:

  1. Open a redirected to PayPal in a new window.
  2. Redirection occurs before the injection of an iframe.
  3. The redirection happens after the iframe being created ActiveXObject for.
  4. Bang on! That’s about it. Now the ActiveXObject has been having with the main window in the same domain.

Here is the valid code:

``javascript w = window. open(“redir. php? URL=https://www. paypal. com”);

// Create and inject an iframe in the target window
ifr = w. document. createElement('iframe');
w. document. appendChild(ifr);

// Initialize the iframe
w[0]. document. open();
w[0]. document. close();

// Pass a reference to the top window
// So the iframe can access even after the redirect.
w[0]. _top = w;

// Finally, once the Paypal is loaded (or loading, same thing) we create the
// ActiveXObject within the injected iframe.
w[0]. setTimeout('alert("[ Thread Blocked to prevent the iFrame Vegas ]\\n\\nClose this alert once the address bar changes to the target site.");' +
 'doc = new ActiveXObject("htmlFile");' +
 'doc. Script. opener = _top;' +
 'doc. Script. setTimeout("opener. location = \'javascript:alert(document. all[0]. outerHTML)\'");');

``

[ IE11 Proof of Concept ]

bug hunter, not in this pause. Continue to explore ActiveXObject, because it is filled with wait for you you discover the object. And you can put this PoC becomes more clean, with less code? You can not use the alert to establish a thread is blocked? Good luck!

I say good luck? Oh no, sorry. What I mean is: continue until you find the bug. If this to you means luck, so good luck! But for me, this means that the passion and persistence. And the only need is to find security vulnerabilities.