Message-ID: <E64731F3ABEB554E8591AFD1DC20DEE1128FF05EDB@SKYVS1.trustwave.com>
Date: Thu, 11 Feb 2010 13:44:32 -0600
From: David Byrne <DByrne@...stwave.com>
To: "bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: RE: Trustwave's SpiderLabs Security Advisory 	TWSL2010-001

Any input from a user is susceptible to tampering. The advisory is specifically about vulnerabilities in how frameworks handle view states. While the frameworks provide functions to secure the view states, the specific vulnerabilities are not documented by the vendors. 

Apache's documentation states that the encryption is only needed when t:SaveState tag is used. Sun provides no specific recommendations on encrypting the view state. Microsoft recommends securing the view state, but doesn't provide concise information about what will happen if you don't. 

The purpose of our advisory was to show that unsecured view states will always be vulnerable to real-world attacks. This changes view state security from a best-practice to a demonstrable vulnerability for all applications developed on the three frameworks described.

Regarding your specific questions:

1) Yes, we did find specific vulnerabilities in all three products listed. The Microsoft vulnerability is demonstrated in the advisory. The Apache MyFaces vulnerability is described in the advisory, but a specific attack is beyond the scope of the advisory. Trustwave has released Deface (https://www.trustwave.com/spiderLabs-tools.php) to demonstrate an actual attack. The Sun Mojarra vulnerability is essentially the same as the one in Apache MyFaces, but is not supported by Deface. If you are familiar with Java, Deface can be modified for use with Mojarra.

2) Enabling encrypted view states in Apache MyFaces and Sun Mojarra will prevent the vulnerability. Microsoft offers several security controls that will effectively prevent the attack. All three frameworks support server-side view states which will also prevent the attacks.

3) Microsoft enables view state MAC (essentially cryptographic signing) by default. Apache MyFaces and Sun Mojarra do not enable encrypted view states by default. 



Thanks,
David Byrne
Senior Security Consultant
Trustwave - SpiderLabs, Application Security
Email: dbyrne@...stwave.com





-----Original Message-----
From: arian.evans@...il.com [mailto:arian.evans@...il.com] On Behalf Of Arian J. Evans
Sent: Tuesday, February 09, 2010 5:07 PM
To: Trustwave Advisories
Cc: webappsec@...ts.securityfocus.com; websecurity@...appsec.org; full-disclosure@...ts.grok.org.uk; bugtraq@...urityfocus.com
Subject: Re: [WEB SECURITY] Trustwave's SpiderLabs Security Advisory TWSL2010-001

Hidden Form Fields and Cookie values are also sometimes vulnerable to these attack techniques.

Encrypting hidden form fields and cookies usually protects them from tampering. Same problem; same solution.

Viewstates typically have the advantage over cookies and hidden FFs, from a security control standpoint, of having native encryption and checksumming facilities provide by the programming environment/framework.

These controls are as easy to turn on as flicking a switch. Super simple remediation. Most frameworks do not offer easy, native controls like this for cookies or hidden FFs.

Would you agree that the issue here is RTFM?

Many developers using Viewstates aren't aware they are using Viewstates. Think "Newbie Visual Studio Jockey" developers. They are using a control in their IDE and have no idea it's passing off stuff in b64 strings to the web-browser/client that can be decoded and/or modified.

The most common scenario where developers disable native Viewstate controls is in multi-websever deployments when they start load-balancing. The Viewstate keys don't match across servers; the app breaks; the developers Google just enough info to decide to turn off Viewstate encryption/checksums (or the server admin does it).

The fix for Viewstate load balancing issues is also super simple:
Share Viewstate MAC/checksum or encryption keys. But it is fairly common not to do this until after a security assessment. Usually for the same reasons I outlined above: they aren't really even sure what Viewstate is doing.

So good work. Nicely written advisories.

Questions:

1) Did you find any unpublished new vulns in these specific products?

2) Are the core issues "if you turn off your compensating control your vulnerabilities are still vulnerable?"

3) Do most vendors enable Viewstate controls by default (like Microsoft does)? If not - I think you should highlight and underscore that. Certainly a default checksum would be smart.

Ciao

---
Arian Evans
Solipsistic Software Security Statistician

Powered by blists - more mailing lists