Trustwave's SpiderLabs Security Advisory TWSL2010-001:
Multiplatform View State Tampering Vulnerabilities
Published: 2010-02-08 Version: 1.1
SpiderLabs has documented view state tampering
vulnerabilities in three products from separate vendors.
View states are used by some web application frameworks to
store the state of HTML GUI controls. View states are
typically stored in hidden client-side input fields,
although server-side storage is widely supported.
The affected vendors generally recommend that client-side
view states are cryptographically signed and/or encrypted,
but specific exploits have not been previously documented.
These vulnerabilities show that unsigned client-side view
states will ALWAYS result in a vulnerability in the affected
products.
Credit: David Byrne of Trustwave's SpiderLabs
===============================================
Vendor: Microsoft (http://www.microsoft.com)
Product: ASP.Net (http://www.asp.net)
Versions affected: .Net 3.5 is confirmed vulnerable;
previous versions are likely to be vulnerable as well.
Description:
ASP.Net is a web-application development framework that
provides for both user interfaces, and back-end
functionality.
The ASP.Net view state is typically stored in a hidden field
named "__VIEWSTATE". When a page's view state is not
cryptographically signed, many standard .Net controls are
vulnerable to Cross-Site Scripting (XSS) through the view
state.
It is well documented that using an unsigned view state is
"bad", but most previous advisories focus on vaguely
described threats or vulnerabilities introduced by custom
use of the view state. To the best of Trustwave's knowledge,
this is the first time a proof of concept attack of this
nature has been demonstrated against the view state. A
vulnerability was alluded to in a 2004 Microsoft article on
troubleshooting view state problems [1]. However, other
Microsoft documents recommend disabling view state signing
"if performance is a key consideration," [2, 3, 4] or for
various other reasons [5, 6]. Realistically, unsigned view
states should never be used in a production environment.
The following code is vulnerable to a XSS attack against the
form control. Note that the "ValidateRequest" setting does
not prevent the attack.
<%@ Page EnableViewStateMac="False"
ValidateRequest="True" %>
<html runat="server">
<form runat="server"/>
</html>
If the following request is sent to the server, the response
will contain JavaScript that calls an alert box.
xss.aspx?__VIEWSTATE=/wEPDwUKLTgzNDA2NzgyMA9kFgJmD2QWAgIBDxY
CHglpbm5lcmh0bWwFHTxzY3JpcHQ%2BYWxlcnQoJ3hzcycpPC9zY3JpcHQ%2
BZGQ=
The view state's XML equivalent is below:
<?xml version="1.0" encoding="utf-16"?>
<viewstate>
<Pair>
<Pair>
<String>-834067820</String>
<Pair>
<ArrayList>
<Int32>0</Int32>
<Pair>
<ArrayList>
<Int32>1</Int32>
<Pair>
<ArrayList>
<IndexedString>innerhtml</IndexedString>
<String><script>alert('xss')</script></String>
</ArrayList>
</Pair>
</ArrayList>
</Pair>
</ArrayList>
</Pair>
</Pair>
</Pair>
</viewstate>
The HTML response is below:
<html>
<form name="ctl01" method="post"
action="xss.aspx" id="ctl01">
<div>
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE"
value="/wEPDwUKLTgzNDA2NzgyMA9kFgJmD2QWAgIBDxYCHglpbm5lcmh0b
WwFHTxzY3JpcHQ+YWxlcnQoJ3hzcycpPC9zY3JpcHQ+ZGQ=" />
</div>
<script>alert('xss')</script></form>
</html>
This example uses the "innerhtml" attribute of the form
control, although other attributes in other controls are
also vulnerable to similar attacks.
Remediation Steps:
The ASP.Net view state should always be cryptographically
signed with a "Message Authentication Code" (MAC). This has
been enabled by default since .Net 1.1, but can be disabled
using the "EnableViewStateMac" setting. Using the
"ViewStateUserKey" setting can also help to mitigate the
scope of this vulnerability. [7]
===============================================
Vendor: Apache Software Foundation (http://www.apache.org)
Product: Apache MyFaces (http://myfaces.apache.org/)
Versions affected: 1.2.8 and 1.1.7 are confirmed as
vulnerable. All previous versions are likely vulnerable.
Related products: Some versions of IBM WebSphere Application
Server (at least 6.x and 7.x) ship with Apache MyFaces
[8,9]
Description:
MyFaces is an open source implementation of the JavaServer
Faces standard. JavaServer Faces [10] is a framework that
aids in developing user interfaces for web-based
applications.
When the application's view state is not encrypted, it is
possible for an attacker to supply a new or modified view
object as part of a request. The malicious view can contain
arbitrary HTML code (allowing Cross-Site Scripting), and
arbitrary Expression Language (EL) [11] statements that will
be executed on the server. The EL statements can be used to
read data stored in user-scoped session variables, and
application or server-scoped variables. Since these
variables should be inaccessible by the user, it is not
uncommon to store sensitive data in them.
Exploiting this vulnerability requires modification of the
serialized view object, which is not stored in a plaintext
format. The Deface tool[12] can be used to provide
proof-of-concept attacks.
Remediation Steps:
This vulnerability can be completely prevented by encrypting
the application's view state.[13] This should always be
performed, even if this specific vulnerability is remediated
by Apache.
===============================================
Vendor: Sun Microsystems (http://www.sun.com)
Product: Mojarra (https://javaserverfaces.dev.java.net/)
Versions affected: 1.2_14 and 2.0.2 are confirmed as
vulnerable. All previous versions are likely vulnerable.
Related products: Some versions of IBM WebSphere Application
Server (at least 6.x and 7.x) ship with Sun Mojarra [8,9]
Although not well documented, some versions of Caucho
Resin (at least 4.x) ship with Sun Mojarra [14]
Description:
Mojarra is the open source reference implementation of the
JavaServer Faces standard. JavaServer Faces[10] is a
framework that aids in developing user interfaces for
web-based applications.
When the application's view state is not encrypted, it is
possible for an attacker to supply a new or modified view
object as part of a request. The malicious view can contain
arbitrary HTML code (allowing Cross-Site Scripting), and
arbitrary Expression Language (EL) [13] statements that will
be executed on the server. The EL statements can be used to
disclose data stored in user-scoped session variables, and
application or server-scoped variables. Since these
variables are usually inaccessible by the user, it is not
uncommon to store sensitive data in them.
Exploiting this vulnerability requires modification of the
serialized view object, which is not stored in a plain-text
format. Techniques similar to those used in the Deface
tool[12] can provide proof-of-concept attacks.
Remediation Steps:
This vulnerability can be completely prevented by encrypting
the application's view state.[15] This should always be
performed, even if this specific vulnerability is remediated
by Sun.
===============================================
References
1. http://support.microsoft.com/kb/829743
2. http://msdn.microsoft.com/en-us/library/system.web.configuration.pagessection.enableviewstatemac.aspx
3. http://msdn.microsoft.com/en-us/library/ydy4x04a.aspx
4. http://msdn.microsoft.com/en-us/library/ms691344.aspx
5. http://technet.microsoft.com/en-us/library/cc732610.aspx
6. http://technet.microsoft.com/en-us/library/dd807062%28WS.10%29.aspx
7. http://msdn.microsoft.com/en-us/library/ms178199(VS.85).aspx
8. http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.express.doc/info/exp/ae/cweb_javaserver_faces.html
9. http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.express.iseries.doc/info/iseriesexp/ae/cweb_javaserver_faces.html
10. http://java.sun.com/javaee/javaserverfaces/
11. http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JSPIntro7.html
12. https://www.trustwave.com/spiderLabs-tools.php
13. http://wiki.apache.org/myfaces/Secure_Your_Application
14. http://www.caucho.com/resin-javadoc/com/caucho/jsf/integration/Mojarra12InjectionProvider.html
15. http://192.9.76.37/Wiki.jsp?page=JavaServerFacesRI
Revision History:
1.0 Initial publication (2010-02-03)
1.1 Added information about IBM WebSphere and Caucho Resin
(2010-02-08)
About Trustwave:
Trustwave is the leading provider of on-demand and
subscription-based information security and payment card
industry compliance management solutions to businesses and
government entities throughout the world. For organizations
faced with today's challenging data security and compliance
environment, Trustwave provides a unique approach with
comprehensive solutions that include its flagship
TrustKeeper compliance management software and other
proprietary security solutions. Trustwave has helped
thousands of organizations--ranging from Fortune 500
businesses and large financial institutions to small and
medium-sized retailers--manage compliance and secure their
network infrastructure, data communications and critical
information assets. Trustwave is headquartered in Chicago
with offices throughout North America, South America,
Europe, Africa, Asia and Australia. For more information,
visit https://www.trustwave.com
About Trustwave's SpiderLabs:
SpiderLabs is the advance security team at Trustwave
responsible for incident response and forensics, penetration
testing, application security and security research for
Trustwave's clients. SpiderLabs has responded to hundreds of
security incidents, performed thousands of ethical hacking
exercises and tested the security of hundreds of business
applications for Fortune 500 organizations. For more
information visit https://www.trustwave.com/spiderlabs
Disclaimer:
The information provided in this advisory is provided "as
is" without warranty of any kind. Trustwave disclaims all
warranties, either express or implied, including the
warranties of merchantability and fitness for a particular
purpose. In no event shall Trustwave or its suppliers be
liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business
profits or special damages, even if Trustwave or its
suppliers have been advised of the possibility of such
damages. Some states do not allow the exclusion or
limitation of liability for consequential or incidental
damages so the foregoing limitation may not apply.
