Aspect9: Internet Explorer 8.0 Beta 2 Anti-XSS Filter Vulnerabilities Release Date: December 11, 2008 Date Reported: October 5, 2008 Severity: Medium-High (Execute scripts, Turning Protection Off, Transfer data Cross Domains) Vendor: Microsoft Systems Affected: Windows Platform with Internet Explorer 8.0 Beta 2 Overview: 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. A quote of Microsoft's Anti-XSS filter design philosophy: <<< "Like all security mitigation and protection technologies, the XSS Filter's approach does have limitations, being that it is a pragmatic balance between application compatibility, security, and performance. Some examples: * Injection into some contexts is not blocked. Ex: Scenarios where content can be injected directly into JavaScript without breaking out of a string. * Injections facilitated by some HTTP headers are not currently blocked. Ex: "Referer" based injection. * If a page contains multiple nearby injection points, attacks can be constructed that thwart the XSS Filter." >>> For more information about the Anti-XSS filter: http://blogs.msdn.com/dross/archive/2008/07/03/ie8-xss-filter-design- philosophy-in-depth.aspx In order to understand the contents of this advisory, the reader must be familiar with the concept of CRLF which is distinguished from CRSF. http://www.owasp.org/index.php/CRLF_Injection http://www.owasp.org/index.php/CSRF 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 His attack will fail as " 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% 0aThe server is busy, try again in 30 minutes 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 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: ------------------------------------------------ ------------------------------------------------ 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. I must admit that I have 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. What does this mean?!?! 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 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'))};****** 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): 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" Credit: Rafel Ivgi Greetings: David Ross, the_pull, Arkon, JonD, lorgandon, xbxice, Budo, Reiter, Inga, Lucid, h.p.c, Dror Shalev, Liu Die Yu, wir3less, Zull, 0fir0, dbrod, ax1les, whitehawkofjustice Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are no warranties, implied or express, with regard to this information. In no event shall the author be liable for any direct or indirect damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk.