AOH :: HP Unsorted T :: BU-1779.HTM

Trustwave's SpiderLabs Security Advisory TWSL2010-001



(resend) RE: Trustwave's SpiderLabs Security Advisory TWSL2010-001
(resend) RE: 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  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@trustwave.com] 
Sent: Tuesday, February 09, 2010 2:41 PM
To: webappsec@lists.securityfocus.com; websecurity@webappsec.org; full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.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" %>
   
      
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: -834067820 0 1 innerhtml <script>alert('xss')</script> The HTML response is below:
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

The entire AOH site is optimized to look best in Firefox® 3 on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH
We do not send spam. If you have received spam bearing an artofhacking.com email address, please forward it with full headers to abuse@artofhacking.com.