Vulnerabilities > CVE-2017-0154 - Injection vulnerability in Microsoft Internet Explorer 11
Attack vector
LOCAL Attack complexity
LOW Privileges required
NONE Confidentiality impact
LOW Integrity impact
LOW Availability impact
NONE Summary
Microsoft Internet Explorer 11 on Windows 10, 1511, and 1606 and Windows Server 2016 does not enforce cross-domain policies, allowing attackers to access information from one domain and inject it into another via a crafted application, aka, "Internet Explorer Elevation of Privilege Vulnerability."
Vulnerable Configurations
| Part | Description | Count |
|---|---|---|
| Application | 1 | |
| OS | 4 |
Common Weakness Enumeration (CWE)
Common Attack Pattern Enumeration and Classification (CAPEC)
- Buffer Overflow via Environment Variables This attack pattern involves causing a buffer overflow through manipulation of environment variables. Once the attacker finds that they can modify an environment variable, they may try to overflow associated buffers. This attack leverages implicit trust often placed in environment variables.
- Server Side Include (SSI) Injection An attacker can use Server Side Include (SSI) Injection to send code to a web application that then gets executed by the web server. Doing so enables the attacker to achieve similar results to Cross Site Scripting, viz., arbitrary code execution and information disclosure, albeit on a more limited scale, since the SSI directives are nowhere near as powerful as a full-fledged scripting language. Nonetheless, the attacker can conveniently gain access to sensitive files, such as password files, and execute shell commands.
- Cross Site Scripting through Log Files An attacker may leverage a system weakness where logs are susceptible to log injection to insert scripts into the system's logs. If these logs are later viewed by an administrator through a thin administrative interface and the log data is not properly HTML encoded before being written to the page, the attackers' scripts stored in the log will be executed in the administrative interface with potentially serious consequences. This attack pattern is really a combination of two other attack patterns: log injection and stored cross site scripting.
- Command Line Execution through SQL Injection An attacker uses standard SQL injection methods to inject data into the command line for execution. This could be done directly through misuse of directives such as MSSQL_xp_cmdshell or indirectly through injection of data into the database that would be interpreted as shell commands. Sometime later, an unscrupulous backend application (or could be part of the functionality of the same application) fetches the injected data stored in the database and uses this data as command line arguments without performing proper validation. The malicious data escapes that data plane by spawning new commands to be executed on the host.
- Subverting Environment Variable Values The attacker directly or indirectly modifies environment variables used by or controlling the target software. The attacker's goal is to cause the target software to deviate from its expected operation in a manner that benefits the attacker.
Msbulletin
| bulletin_id | MS17-006 |
| bulletin_url | |
| date | 2017-03-14T00:00:00 |
| impact | Remote Code Execution |
| knowledgebase_id | 4013073 |
| knowledgebase_url | |
| severity | Critical |
| title | Cumulative Security Update for Internet Explorer |
Nessus
| NASL family | Windows : Microsoft Bulletins |
| NASL id | SMB_NT_MS17-006.NASL |
| description | The version of Internet Explorer installed on the remote Windows host is missing Cumulative Security Update 4013073. It is, therefore, affected by multiple vulnerabilities, the most severe of which are remote code execution vulnerabilities. An unauthenticated, remote attacker can exploit these vulnerabilities by convincing a user to visit a specially crafted website, resulting in the execution of arbitrary code in the context of the current user. |
| last seen | 2020-06-01 |
| modified | 2020-06-02 |
| plugin id | 97729 |
| published | 2017-03-14 |
| reporter | This script is Copyright (C) 2017-2019 and is owned by Tenable, Inc. or an Affiliate thereof. |
| source | https://www.tenable.com/plugins/nessus/97729 |
| title | MS17-006: Cumulative Security Update for Internet Explorer (4013073) |
| code | |
Seebug
| bulletinFamily | exploit |
| description | Original link: a [Broken Browser](<https://www.brokenbrowser.com/uxss-ie-htmlfile/>) Original author: [Manuel Caballero](<https://twitter.com/magicmac2000>) 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](<https://msdn.microsoft.com/en-us/library/7sw4ddf8\(v=vs.94\).aspx>) . 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](<https://developer.mozilla.org/en-US/docs/Web/API/DOMImplementation/createDocument>), and [implementation. createHTMLDocument ](<https://developer.mozilla.org/en-US/docs/Web/API/DOMImplementation/createHTMLDocument>) even [XMLHttpRequest ](<https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/responseType>) 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 ](<https://msdn.microsoft.com/en-us/library/aa752041\(v=vs.85\).aspx>) 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!**win **think it belongs to the top of the top, I can not help but imagination is. It is perhaps the presence of [XFO ](<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options>) 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 ]](<https://www.cracking.com.ar/demos/sop-ax-htmlfile/getdomain.html>) 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](<https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze>), 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 ]](<https://www.cracking.com.ar/demos/sop-ax-htmlfile/accesstop.html>) 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](<https://en.wikipedia.org/wiki/Matryoshka_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 ]](<https://www.cracking.com.ar/demos/sop-ax-htmlfile/injectiframexdom.html>)  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. |
| id | SSV:92802 |
| last seen | 2017-11-19 |
| modified | 2017-03-20 |
| published | 2017-03-20 |
| reporter | Root |
| title | Microsoft Internet Explorer Elevation of Privilege Vulnerability (CVE-2017-0154) |