IE8's XSS Filter Exposes Sites To XSS Attacks

Blue Taxes writes "The cross-site scripting filter that ships with Microsoft's Internet Explorer 8 browser can be abused by attackers to launch cross-site scripting attacks on websites and web pages that would otherwise be immune to this threat. The IE8 filter works by scanning outbound requests for strings that may be malicious. When such a string is detected, IE8 will dynamically generate a regular expression matching the outbound string. The browser then looks for the same pattern in responses from the server. If a match is made anywhere in the server's response, the browser assumes that a reflected XSS attack is being conducted and the browser will automatically alter the response so that the XSS attack cannot succeed. The researchers figured out a way to use IE8's altered response to conduct simple abuses and universal cross-site scripting attacks, which worked against sites that would not otherwise have been vulnerable to XSS." Here is the researchers' backgrounder (PDF) on the attack. Microsoft says that they have issued two patches that address the issue, but the researchers insist that holes remain.
Update: 04/20 14:06 GMT by KD : Microsoft's Security Response Center has issued a statement on the vulnerability.

Comments

Microsoft's response

[seifried]

http://blogs.technet.com/msrc/archive/2010/04/19/guidance-on-internet-explorer-xss-filter.aspx

.

Re:Microsoft's response

[totally bogus dude]

Well maybe they've decided to actually test the patch before releasing it? :)

I discovered today that a patch for a vulnerability in the IIS SMTP service causes the settings for the service to be reset if you're running it on Server 2008 (2003 doesn't seem to be affected, AFAIK).

Unfortunately we applied that patch (and others) last Wednesday and don't have regular automated testing of our website's ability to deliver mail to localhost, so took a while for us to notice... a quick Google lead me to this discussion where I discovered the cause.

Re:Microsoft's response

[LinuxAndLube]

I just read this: "Now when you look at Microsoft today they do more to secure their software than anyone. They're the model for how to do it. They're not perfect; there's room for improvement. But they are definitely doing more than anybody else in the industry, I would say." [ http://news.cnet.com/8301-27080_3-20002317-245.html?tag=rtcol;inTheNewsNow ] I think most people in the know would agree with him.

Re:Microsoft's response

[thornmaker]

The last sentence of the article's summary is completely wrong. I am one of the "original researchers" for this issue (p42.us is my website). The patches that have been issued by Microsoft up to this point are successful at eliminating the primary security vulnerability, to the best of our knowledge. The main security vulnerability described in our white paper was disclosed to Microsoft last fall and Microsoft fixed the issue in January 2010. The one case that has not been addressed by the filters is very rare and extremely unlikely to be found on a given websites.

Really old news!

[Anonymous Coward]

This was already reported last November: http://tech.slashdot.org/story/09/11/24/2141247/Major-IE8-Flaw-Makes-Safe-Sites-Unsafe

Re:Deserve what you get

[TrancePhreak]

And there is no way to control it either.

You mean like right clicking and selecting "not junk" ?

This is how it works.

[clone53421]

No.

The sites were previously not susceptible to cross-site scripting. They escaped their input, whatever needed to be done.

IE cleverly tried to prevent cross-site scripting and in the process they screwed up the properly-escaped response so that now, you can execute a xss attack that didn’t even exist until IE8 changed it.

This is how.

If I enter “<img src=x:x onerror=alert(document.cookie);><script” in a username field, the next page that says “Hi, $name” should not result in a script alert. And if the page also sends the username as a Javascript string, the (PROPERLY ESCAPED) response might look like this:

<script type="text/javascript">
var username = "<img src=x:x onerror=alert(document.cookie);><script";
</script>
Hi, &lt;img src=x:x onerror=alert(document.cookie);&gt;&lt;script

Note that the site properly escaped the angle brackets when it was presented as HTML, and there were no illegal characters that needed escaping in Javascript.

IE8 will detect your “<script” in the input and replace all instances of <script with “<sc#ipt” in the resulting page. (No, I’m not making this up. That is what the researchers claim.) Which, naturally, kills most of the Javascript functionality in the resulting page. But more importantly, it does this:

<sc#ipt type="text/javascript">
var username = "<img src=x:x onerror=alert(document.cookie);><sc#ipt";
</script>
Hi, &lt;img src=x:x onerror=alert(document.cookie);&gt;&lt;script

...which looks like this, when the browser renders it:

var username = "[broken image bitmap] Hi, <img src=x:x onerror=alert(document.cookie);><script

AND THE INJECTED SCRIPT EXECUTES.

Now you just replace the alert() with some Ajax code to send the stolen cookies to your server, craft a URL containing the malicious code in a GET query, and go phishing.

Re:This is how it works.

[clone53421]

Actually, no. The site sent code that was executed by the browser to a malicious result. Normally in such a situation you’d blame the site, and rightly so.

The blame goes on IE in this one, though, for breaking correct code generated by the site and turning it into something incorrect (and malicious).

Re:Good to know

[CorporateSuit]

When you go to a website, and it says "Welcome, Thomas!" because your referrer website sent them to their homepage with something like "http://www.website.com/?name=Thomas" these guys set up the referrer to send you to a page that says something like "http://www.website.com/?name=[malicious code]" and the site says "Welcome !" and congratulations on your new site-specific keylogger.