Message-ID: <000e01caab6b$971d4a50$c557def0$@com>
Date: Thu, 11 Feb 2010 14:43:05 -0800
From: "Chris Weber" <chris@...abasec.com>
To: "'Trustwave Advisories'" <TrustwaveAdvisories@...stwave.com>,
	<webappsec@...ts.securityfocus.com>, <websecurity@...appsec.org>,
	<full-disclosure@...ts.grok.org.uk>, <bugtraq@...urityfocus.com>
Subject: (resend) RE: [WEB SECURITY] Trustwave's SpiderLabs Security Advisory TWSL2010-001

The key part of the advisory for me wasn't VIEWSTATE as much as it was the controls, but this statement you made seemed pretty outrageous (with regard to ASP.NET):

   'These vulnerabilities show that unsigned client-side viewstates will ALWAYS result in a vulnerability in the affected products.'

I would disagree - it depends how the software developer implemented use of the VIEWSTATE's content.  In ASP.NET, the interesting part here was that you appeared to be controlling an innerhtml property of a Form control through the VIEWSTATE.  What your example didn't show, I'm assuming, is some code behind that pulled out the <IndexedString> and set the value in the form's innerHtml property/attribute. That's just dangerous coding, akin to trusting client-side input and no different than acting on client input that came from any method, form input, JSON, etc.  Your repro was a bit confusing/misleading without that part.  Otherwise, were you saying that some controls inherently populate their properties/attributes from VIEWSTATE content automagically?  

There have been past discussions on VIEWSTATE's security:

Scott Mitchell documented tampering VIEWSTATE in a 2004 article:
http://msdn.microsoft.com/en-us/library/ms972976.aspx#viewstate_topic12

Michal Zalewski reported some exploit scenarios with replay and DoS through VIEWSTATE.
http://seclists.org/bugtraq/2005/May/27

You made a reference to how other controls are also vulnerable to this attack.  I think that data would be more useful in the advisory.  

Yes there do exist ASP.NET controls which don't properly encode, and I would refer readers to Sacha Faust's FxCop rule which finds those dangerous controls:

http://blogs.msdn.com/sfaust/archive/2008/09/18/fxcop-htmlspotter-spotting-asp-net-xss-using-fxcop-and-html-encoding-document.aspx


Best regards,
Chris Weber

-----Original Message-----
From: Trustwave Advisories [mailto:TrustwaveAdvisories@...stwave.com] 
Sent: Tuesday, February 09, 2010 2:41 PM
To: webappsec@...ts.securityfocus.com; websecurity@...appsec.org; full-disclosure@...ts.grok.org.uk; bugtraq@...urityfocus.com
Subject: [WEB SECURITY] Trustwave's SpiderLabs Security Advisory TWSL2010-001

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>&lt;script&gt;alert('xss')&lt;/script&gt;</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="/wEPDwUKLTgzNDA2NzgyMA9kFgJmD2QWAgIBDxYCHglpbm5lcmh0bWwFHTxzY3JpcHQ+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.



----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA

Powered by blists - more mailing lists