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.
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.
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.
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.
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!win think 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.
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!
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.
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.
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!
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.
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:
Here is the valid code:
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.