Date: Wed, 10 Feb 2010 10:31:51 -0600
From: David Byrne <DByrne@...stwave.com>
To: Trustwave Advisories <TrustwaveAdvisories@...stwave.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


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists