[WEB SECURITY] RE: Trustwave's SpiderLabs Security Advisory TWSL2010-001

Arian J. Evans arian.evans at anachronic.com
Thu Feb 11 15:25:02 EST 2010


Your secnd paragraph is the key. Which  I don't believe you fully
emphasized in your advisory. My observation here is simply based upon
the number of confused questions I have gotten about your advisory,
all fixed on 'viewstate vulns'.

Very good points made. And out in the real world we do see a large
number of apps with improperly secured Viewstates, at least the first
time you test them.

Without crunuching any numbers, I'd say "the majority" of sites using
Viewstates in multi-node environments are insecure by default. The
percentage is less in single-node environments, but I'll have to run
some numbers to get a better idea of how widespread the below is. All
in all I'd suspect fairly widespread.

---
Arian Evans
capitalist marksman. eats animals.



On Thu, Feb 11, 2010 at 11:42 AM, David Byrne <DByrne at trustwave.com> wrote:
> 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 at trustwave.com
>
>
>
>
>
> -----Original Message-----
> From: arian.evans at gmail.com [mailto:arian.evans at gmail.com] On Behalf Of Arian J. Evans
> Sent: Tuesday, February 09, 2010 5:07 PM
> To: Trustwave Advisories
> Cc: webappsec at lists.securityfocus.com; websecurity at webappsec.org; full-disclosure at lists.grok.org.uk; bugtraq at securityfocus.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
>
>
>
>
> ----------------------------------------------------------------------------
> 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
>
>

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



More information about the websecurity mailing list