- Apr 13, 2013
- 3,224
A weakness has been discovered in the reflective cross-site scripting filter present in Internet Explorer since IE 8 that could enable an attacker to trick the browser into executing malicious code as trusted. The problem going forward is twofold: everything occurring in the bypass method is accepted as part of the official HTML standard going back at least 15 years; and Microsoft said it will not work on a fix for the flaw.
Carlos Munoz, a researcher with WhiteHat Security who publicized the issue today, told Threatpost that he reported the problem to the Microsoft Security Response Center on Aug. 26 and after several back-and-forth emails was informed that Microsoft would not move forward citing its design philosophy for the XSS filter.
A request for comment to Microsoft was not returned in time for publication.
Specifically, Microsoft pointed Munoz to a bullet point in its design philosophy that states: “For attacks that depend on application-specific transformations, we will only attempt to make the XSS Filter effective where these transformations are identified to be pervasive. We choose not to ROT13 decode URLs.
Munoz said that if Microsoft did choose to fix the problem, it may have to add functionality to the filter that recognizes encoded reflections, decodes them, and then compares those decodings to known potentially malicious signatures.
“Another path that Microsoft could take is tracking injections across several requests and attempting to determine if an injection on page 1 of a website eventually reflects as a malicious script on page 4,” Munoz said. “There are probably several other avenues that Microsoft could pursue in working on a fix for this flaw.”
Microsoft introduced the reflective cross-site scripting filter in Internet Explorer 8 and it’s been supported in every version of the browser through the current version 11 released two months ago with Windows 8.1. The filter prevents browsers from executing non-stored data submitted in an HTML form or in an HTTP query without sanitizing it first.
The filter, however, has a weakness in that it can be tricked into executing untrusted requests from a user; an attacker could exploit this situation to execute malicious javascript or VBScript inside the browser. Numerous high-profile attacks this year alone have exploited javascript issues with Internet Explorer. Microsoft has issued almost monthly cumulative IE patches for the browser in 2013.
“Currently this method of bypassing Internet Explorer’s anti-XSS filter only works when an attacker can inject into or create their own attribute space of an HTML element, and that attribute is then passed onto a page within the same domain that contains a XSS vulnerability,” Munoz said. “As this would imply, this is not an ‘everything is vulnerable’ type of finding. It is, however, something that could be exploited on almost any page where an attacker can inject HTML elements, albeit with the requirement that the victim would need to click a link on the page.”
Munoz wrote in a blog post today that the filter compares only untrusted requests with the response body from a website for reflections that could cause code execution.
“Should an injection from that initial request reflected on the page not cause immediate JavaScript code execution, that untrusted data from the injection is then marked as trusted data, and the anti-XSS filter will not check it in future requests,” Munoz said, adding that only untrusted data is sent to through the filter.
Munoz points out that the filter is effective at stopping cross-site scripting attacks, but an attacker could fool it by taking advantage of a loophole in the HTML standard with regard to decimal and hexadecimal encodings.
“Everything utilized in this methodology is part of the official HTML standard—it uses the web the way the web was meant to be used,” Munoz said. When a response is made to an HTTP request that includes a properly coded decimal or hexadecimal character, Munoz said, the browser will display the encoded character.
“As an added bonus for an attacker, when a decimal or hexadecimal encoded character is returned in an attribute that is then included in a subsequent request, it is the decoded character that is sent, not the decimal or hexadecimal encoding of that character,” Munoz wrote. “Thus, all an attacker needs to do is fool Internet Explorer’s anti-XSS filter by inducing some of the desired characters to be reflected as their decimal or hexadecimal encodings in an attribute.”
Munoz said such an attack can be carried out with a malicious iframe, malicious code in a form submission or an embedded link to a site hosting an exploit. He added that he is not aware of any in-the-wild exploits. An attacker could craft something similar to a common reflective XSS attack to bypass the filter, but would have to entice the user via a phishing email to land on a site hosting an exploit.
“Once the victim followed the link, the malicious JavaScript would run in their browser in the context of the vulnerable website,” Munoz said. “This could lead to anything from the capturing of session tokens, the bypassing of Cross Site Request Forgery protections, to the utilization of Internet Explorer-specific 0-days to compromise the victim’s computer.”
http://threatpost.com/bypass-of-internet-explorer-cross-site-scripting-filter-possible/103106
Carlos Munoz, a researcher with WhiteHat Security who publicized the issue today, told Threatpost that he reported the problem to the Microsoft Security Response Center on Aug. 26 and after several back-and-forth emails was informed that Microsoft would not move forward citing its design philosophy for the XSS filter.
A request for comment to Microsoft was not returned in time for publication.
Specifically, Microsoft pointed Munoz to a bullet point in its design philosophy that states: “For attacks that depend on application-specific transformations, we will only attempt to make the XSS Filter effective where these transformations are identified to be pervasive. We choose not to ROT13 decode URLs.
Munoz said that if Microsoft did choose to fix the problem, it may have to add functionality to the filter that recognizes encoded reflections, decodes them, and then compares those decodings to known potentially malicious signatures.
“Another path that Microsoft could take is tracking injections across several requests and attempting to determine if an injection on page 1 of a website eventually reflects as a malicious script on page 4,” Munoz said. “There are probably several other avenues that Microsoft could pursue in working on a fix for this flaw.”
Microsoft introduced the reflective cross-site scripting filter in Internet Explorer 8 and it’s been supported in every version of the browser through the current version 11 released two months ago with Windows 8.1. The filter prevents browsers from executing non-stored data submitted in an HTML form or in an HTTP query without sanitizing it first.
The filter, however, has a weakness in that it can be tricked into executing untrusted requests from a user; an attacker could exploit this situation to execute malicious javascript or VBScript inside the browser. Numerous high-profile attacks this year alone have exploited javascript issues with Internet Explorer. Microsoft has issued almost monthly cumulative IE patches for the browser in 2013.
“Currently this method of bypassing Internet Explorer’s anti-XSS filter only works when an attacker can inject into or create their own attribute space of an HTML element, and that attribute is then passed onto a page within the same domain that contains a XSS vulnerability,” Munoz said. “As this would imply, this is not an ‘everything is vulnerable’ type of finding. It is, however, something that could be exploited on almost any page where an attacker can inject HTML elements, albeit with the requirement that the victim would need to click a link on the page.”
Munoz wrote in a blog post today that the filter compares only untrusted requests with the response body from a website for reflections that could cause code execution.
“Should an injection from that initial request reflected on the page not cause immediate JavaScript code execution, that untrusted data from the injection is then marked as trusted data, and the anti-XSS filter will not check it in future requests,” Munoz said, adding that only untrusted data is sent to through the filter.
Munoz points out that the filter is effective at stopping cross-site scripting attacks, but an attacker could fool it by taking advantage of a loophole in the HTML standard with regard to decimal and hexadecimal encodings.
“Everything utilized in this methodology is part of the official HTML standard—it uses the web the way the web was meant to be used,” Munoz said. When a response is made to an HTTP request that includes a properly coded decimal or hexadecimal character, Munoz said, the browser will display the encoded character.
“As an added bonus for an attacker, when a decimal or hexadecimal encoded character is returned in an attribute that is then included in a subsequent request, it is the decoded character that is sent, not the decimal or hexadecimal encoding of that character,” Munoz wrote. “Thus, all an attacker needs to do is fool Internet Explorer’s anti-XSS filter by inducing some of the desired characters to be reflected as their decimal or hexadecimal encodings in an attribute.”
Munoz said such an attack can be carried out with a malicious iframe, malicious code in a form submission or an embedded link to a site hosting an exploit. He added that he is not aware of any in-the-wild exploits. An attacker could craft something similar to a common reflective XSS attack to bypass the filter, but would have to entice the user via a phishing email to land on a site hosting an exploit.
“Once the victim followed the link, the malicious JavaScript would run in their browser in the context of the vulnerable website,” Munoz said. “This could lead to anything from the capturing of session tokens, the bypassing of Cross Site Request Forgery protections, to the utilization of Internet Explorer-specific 0-days to compromise the victim’s computer.”
http://threatpost.com/bypass-of-internet-explorer-cross-site-scripting-filter-possible/103106
