========================================================================
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