======================================================================== Apache Tomcat UTF-7 XSS ======================================================================== Affected Software : Apache Tomcat <= 6.0.18 (all platforms) Apache Tomcat <= 5.5.27 (all platforms) Apache Tomcat <= 4.1.39 (all platforms) Severity : Medium Local/Remote : Remote Author : Luca Carettoni - luca.carettoni[at]ikkisoft[dot]com Advisory URL : http://www.ikkisoft.com/stuff/LC-2009-02.txt [Summary] Apache Tomcat (all platforms and versions) is vulnerable to Cross Site Scripting caused by an improper validation of user-supplied input encoded with the UTF-7 charset. This issue could be exploited by tricking a user into following a malicious link. The theft of session tokens could completely compromise affected systems by triggering session hijacking. Several attack vectors have been discovered in Apache Tomcat including the default 404, 501 error pages and several JSP/Servlet examples. UTF-7 charset[1] is a well-known attack vector[2] since several browsers can be tricked into assuming UTF-7 as a charset when no charset header is given by the server or from within the HTML. [1] http://www.ietf.org/rfc/rfc2152.txt [2] http://openmya.hacker.jp/hasegawa/security/utf7cs.html [Vulnerability Details] A Cross Site Scripting vulnerability triggered by UTF-7 payloads afflicts all previous versions of Apache Tomcat. This can be exploited to execute arbitrary HTML and script code in a user's browser session in the context of an affected site. Using this particular technique, an aggressor may encode the malicious payload in UTF-7 in order to avoid input validation filters. As a Proof of Concept, it is possible to use the following basic pattern: +ADw-script+AD4-alert(123)+ADw-/script+AD4- It does not vary from the usual JS PoC vector, encoded in UTF-7. ) In the past years, the usage of the UTF-7 charset as an attack vector against web server and web applications launched a great public debate in the security community. Some claimed that the vulnerability affects the browser and not the web server or the web application [3][4]. For instance, Internet Explorer's autodetection clearly violates the RFC specification [5]. However, as mentioned by several security researchers, we cannot trust the client-side environment because we simply do not know how a particular browser will interpret the bytes we send. As usual, to ensure security we have to strictly enforce the standard. In the excellent "Browser Security Handbook" [6], Michal Zalewski reports: " This behavior makes it inherently unsafe to return any renderable, user-controlled data with no character set explicitly specified. There are two primary ways to explicitly declare a character set for any served content; first of them is the inclusion of a charset= attribute in Content-Type headers: Content-Type: text/html; charset=utf-8 The other option is an equivalent directive: " Apache Tomcat does not enforce any charset by default, which makes several attack vectors possible: {Default 404 Error Page} A request to a nonexistent page will trigger the default 404 error page which normally includes the requested resource. Since neither UTF-7 expressions are validated nor charset is enforced, it is possible to include JS code. GET /nonexistent/+ADw-script+AD4-alert(123)+ADw-/script+AD4- HTTP/1.0 Host: 127.0.0.1:8080 (Default 501 Error Page) As above, it is possible to include arbitrary JS code within the 501 "Not Implemented" error page. G+ADw-script+AD4-alert(123)+ADw-/script+AD4-ET / HTTP/1.0 Host: 127.0.0.1:8080 (Servlet and JSP Examples) Several Servlet and JSP examples include user-supplied data in the response page therefore it is possible to abuse these resources to inject JS payloads encoded in UTF-7. As a Proof of Concept, we provide the following examples: "Request Info" Servlet Example GET /examples/servlets/servlet/RequestInfoExample/+ADw-script+AD4-alert(123)+ ADw-/script+AD4- HTTP/1.0 Host: 127.0.0.1:8080 "Request Headers" Servlet Example GET /examples/servlets/servlet/RequestHeaderExample HTTP/1.0 Accept: image/gif, +ADw-script+AD4-alert(1)+ADw-/script+AD4- Accept-Language: en-GB+ADw-script+AD4-alert(2)+ADw-/script+AD4-,pl;q=0.5 UA-CPU: x8+ADw-script+AD4-alert(3)+ADw-/script+AD4-6 User-Agent: Mozilla/4.0+ADw-script+AD4-alert(4)+ADw-/script+AD4- Cookie: +ADw-script+AD4-alert(5)+ADw-/script+AD4-=""; JSESSIONID Host: 127.0.0.1:8080 "Implict Object" JSP Example GET /examples/jsp/jsp2/el/implicit-objects.jsp?foo=bar HTTP/1.0 Accept: +ADw-script+AD4-alert(1)+ADw-/script+AD4- User-Agent: +ADw-script+AD4-alert(2)+ADw-/script+AD4- Host: 127.0.0.1:8080 Several other examples, included in Apache Tomcat, are vulnerable as well ("Request Parameters" Servlet, "Cookies" Servlet, "Sessions" Servlet, ...). Since no charset header is actually specified and there is no system-wide input validation checkpoint for the UTF-7 charset, the problem is omnipresent in the Tomcat code base. For this reason, it is likely that other attack vectors exist. Trying to evaluate the severity of this finding, it may be noted that UTF-7 charset is accepted by almost all browsers. However, only Microsoft Internet Explorer (version 6,7) detects unknown charsets in the document which renders it particularly vulnerable to this attack. Social engineering is definitely required to persuade a potential victim to manually change the browser charset option. [3] http://seclists.org/bugtraq/2008/May/0166.html [4] http://www.securityfocus.com/archive/1/492220/30/0/threaded [5] http://www.ietf.org/rfc/rfc2616.txt [6] http://code.google.com/p/browsersec/wiki/Part2 [Fix Information] Enforcing a specific charset in the default setup of the JSP/Servlet container should be considered as a sufficient mitigation. [Time Table] 26/02/2009 - Vendor notified. ??/??/2009 - Vendor response. ??/??/2009 - Vendor patch release. ??/??/2009 - Public disclosure. [Legal Notices] The information in the advisory is believed to be accurate at the time of publishing based on currently available information. This information is provided as-is, as a free service to the community. There are no warranties with regard to this information. The author does not accept any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. Permission is hereby granted for the redistribution of this alert, provided that the content is not altered in any way, except reformatting, and that due credit is given. This vulnerability has been disclosed in accordance with the RFP Full-Disclosure Policy v2.0, available at: http://www.wiretrip.net/rfp/policy.html