RE: Trustwave's SpiderLabs Security Advisory TWSL2010-001

[David Byrne <DByrne@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx





-----Original Message-----
From: arian.evans@xxxxxxxxx [mailto:arian.evans@xxxxxxxxx] On Behalf Of Arian 
J. Evans
Sent: Tuesday, February 09, 2010 5:07 PM
To: Trustwave Advisories
Cc: webappsec@xxxxxxxxxxxxxxxxxxxxxxx; websecurity@xxxxxxxxxxxxx; 
full-disclosure@xxxxxxxxxxxxxxxxx; bugtraq@xxxxxxxxxxxxxxxxx
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