Exploiting IE8 UTF-7 XSS Vulnerability using Local Redirection

Conventions:
Attacker Domain – Securethoughts.com
Target Domain – 50webs.com

If you don’t remember, there was an important XSS vulnerability reported in all major browsers a while ago – IE7, Firefox and Opera. More Information is available in the Secunia advisories here. The vulnerability was that if you don’t specify a charset in your application page, then it is susceptible to inherit the charset in the parent page via iframes. So, if you accidently land on an evil site, an attacker might be able to steal your application session since your usual XSS prevention stuff [<,>,",',etc] will not filter the utf-7 encoded chars and XSS will execute in your vulnerable domain. Proof of Concept that works in IE7 but not in IE8 -
/security/ie8utf7/ie7utf-7.html

This vulnerability was patched in Firefox 2.0.0.2, Opera 9.20 and recently in Internet Explorer 8. Ideally, we should not be vulnerable to this attack anymore. However, I have found a way to attack the fix that was done in Internet Explorer 8. I have tested it working with IE8 RC1 and final release version IE8.0.6001.18702. I call this a “Local Redirection Attack”.

The attack works as follows:

1. You are authenticated to vulnerable domain e.g. 50webs.com.

2. You land onto the evil site via link –
/security/ie8utf7/ie8utf-7.html.

3. The page loads into your IE8 browser.

4. IE8 thinks that it is loading a child page -
[/security/ie8utf7/utf-71.html] from the same domain and hence removes the restriction on charset inheritance.

5. This is where Local Redirection Attack comes into play. The attacker sets a temporary redirect on the child page to vulnerable site [http://webappsec.50webs.com/utf-71.html]. Make sure that the link to vulnerable site is a page with your UTF-7 injected characters [Persistent/Reflected XSS]. In this case, my utf-71.html page on 50webs.com has a persistent XSS with UTF-7 characters.

6. The XSS executes in the context of vulnerable site. E.g. if you see below, you can see my 50webs.com member cookie appended with ‘XSS’ in an alert box.

I have been in touch with Jack from Microsoft Security Response Center (MSRC) team for the last 2 months. I would like to thank the Microsoft Security Team for their timely responses and letting me discuss these issues with the security community. They are actively working to resolve this issue and a fix for this vulnerability is expected to arrive in the next version of Internet Explorer, IE9.

Tags: Charset, IE8, Internet Explorer, Local Redirection Attack, Microsoft, UTF-7, XSS

This entry was posted on Tuesday, May 12th, 2009 at 4:41 am and is filed under Browsers, Exploits, WebAppSec, XSS. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

18 Responses to “Exploiting IE8 UTF-7 XSS Vulnerability using Local Redirection”

Ghost says:

May 19, 2009 at 3:28 am

is it kind of sarcasm ?
:
“I have been in touch with Jack from Microsoft Security Response Center (MSRC) team for the last 2 months. I would like to thank the Microsoft Security Team for their timely responses and letting me discuss these issues with the security community. They are actively working to resolve this issue and a fix for this vulnerability is expected to arrive in the next version of Internet Explorer, IE9.”
:
?
actively working on it to be fixed in IE9!?
missing to say please don’t exploit this while we are relaxing till IE9 is released to public.

cheers.
Inferno says:

May 19, 2009 at 3:53 am

Hi Kawzaki,

In my opinion, it was important to bring this issue into light so that people would not do the same mistake of not specifying charsets and think that they are not vulnerable in IE8. I think Microsoft did some prioritization on this issue and thought it could be better fixed in IE9. I don’t question their capabilities.

Thanks,
Inferno
TUX2K says:

May 26, 2009 at 12:28 pm

Just tried it on the dutch version of IE 8.
It doesn’t seem toe work, no popup.
bobbie says:

May 26, 2009 at 3:20 pm

Is that FireFox with noscript addon in it that is not vunerable or is it standard Firefox 2.0.0.2
Inferno says:

May 26, 2009 at 3:51 pm

Hi Tux2K,

Did you try this link /security/ie8utf7/ie8utf-7.html ??

Can you paste the complete IE8 version number from “About Internet Explorer” and platform like Windows Vista/XP. As I know, this won’t be fixed in IE8 and should work.

Thanks,
Inferno
Inferno says:

May 26, 2009 at 3:56 pm

Hi Bobbie,

Standard Firefox users using versions later than 2.0.0.2 are not vulnerable to this exploit anymore [even without noscript addon]. Only IE7, IE8 users are vulnerable. IE does not have a noscript type of plugin that we have for Firefox and IE8 XSS filter does not protect against this exploit.

Thanks,
Inferno
Simon Zerafa says:

June 12, 2009 at 4:08 am

Hi,

The link at:

/security/ie8utf7/ie8utf-7.html

is confirmed to be working in IE8 build 8.00.6001.18783 and was fully patched with all patches as of today. Running on Windows Vista Home Premium SP1.

Kind Regards

Simon
Exploiting IE8 UTF-7 XSS Vulnerability using Local Redirection - DMNTorrents says:

June 20, 2009 at 3:00 pm

[...] Exploiting IE8 UTF-7 XSS Vulnerability using Local Redirection | SecureThoughts.com [/quote] [...]
N Blackwell says:

June 26, 2009 at 8:49 pm

Is Google Chrome affected by this?
Inferno says:

June 27, 2009 at 12:24 am

Hi Nik,

Thanks for bringing this up. I forgot to mention Google Chrome in the post. Google Chrome is not vulnerable to this exploit. The version I tested was 2.0.172.33.
Joe says:

July 2, 2009 at 2:45 am

My one data point:

I tried the link /security/ie8utf7/ie8utf-7.html using IE 8.0 .6001.18783 on Vista Home Premium. I did not see the popup. I got a DNS error in the iframe.

I am running Blink antimalware to help protect against this kind of rogue behavior, but there was nothing in the event logs.
Inferno says:

July 2, 2009 at 3:38 am

Hi Joe, As far as I know, Microsoft hasn’t patched this yet. So, it should work fine on your machine. Try two things – (1) try loading http://webappsec.50webs.com/utf-71.html directly to see if you can access the child page [you should see utf-7 string and no DNS error] (2) then try disabling blink antimalware and seeing what results you get when accessing /security/ie8utf7/ie8utf-7.html
Breezy says:

August 23, 2009 at 7:22 pm

Nice find. Would it be correct to assume that if a page’s URL must contain the characters = or &, then the page is not vulnerable in this context? IE seems to be encoding the URL in the GET request as such:

http://example.com/test.php?thing1=1&thing2=2
becomes
http://example.com/test.php?thing1+AD0-1+ACY-thing2+AD0-2

= and & seem to be an impossibility for the target URL
Inferno says:

August 23, 2009 at 8:47 pm

hi breezy, IE does not encode the URL, = and & are allowable in URL. Vulnerability exists in GET and other scenarios as well such as POST, persistent XSS, etc.
LayZee says:

September 21, 2009 at 4:12 pm

Been around since IE6 and still not patched in IE8?! Shame on you, M$!!

Tested and found vulnerable on IE 8.0.7600.16385 @ Windows 7 Pro x64.
Dave Dows says:

November 16, 2009 at 9:53 am

If I understand your test correctly, then my IE8 is not vulnerable or one of my security products is blocking this. The popup contains only the text “XSS” without your 50webs.com member cookie.

IE8 Version 8.0.6001.18702
Windows XP Build 2600.xpsp.080320-1628 (Service Pack 3) fully patched
AVG LinkScanner® version: 8.5.362
SnoopFree Privacy Shield 1.0.7
NIS 2010, MBAM, SAS
Inferno says:

November 16, 2009 at 1:59 pm

@Dave, if you are seeing XSS, then script is executing, which means that your IE is vulnerable. If you want to see the cookie as well, you need to signup for a 50webs.com account, signin and then go to the exploit page.
hacky says:

November 28, 2009 at 8:33 am

To make things worse MS put the same IE code on windows 7 too… latest IE still vulnerable…

SecureThoughts.com