Re: XSS in viewstate

[David Byrne <DByrne () trustwave com>]

In our original advisory, we did comment that Microsoft hinted at this vulnerability in a rather buried document 
(http://support.microsoft.com/kb/829743), but we could find no other references to it on Microsoft's website or 
anywhere else. While there are plenty of comments about application developers abusing the view state, this is the 
first time (as far as we know) that the .Net framework was demonstrated to be vulnerable to XSS through the view state. 

The machine key does have to be manually set in a load balanced environment, but I don't see that as being a problem. 
.Net supports 512-bit machine keys (http://msdn.microsoft.com/en-us/library/ms998288.aspx), which is well beyond 
brute-force attacks. That's such a large key space that I don't think rotation is critical to maintain good security. 
If a way to bypass the MAC is discovered, that would be huge news, but it seems to be pretty solid for now.


Thanks,
David Byrne
Senior Security Consultant
Trustwave - SpiderLabs, Application Security



-----Original Message-----
From: dailydave-bounces () lists immunitysec com [mailto:dailydave-bounces () lists immunitysec com] On Behalf Of Raw 
Data
Sent: Friday, February 19, 2010 11:46 AM
To: dailydave () lists immunityinc com
Subject: Re: [Dailydave] XSS in viewstate

Hi Dave,

This problem has been hinted by MS since the release of .Net2.0, even
my team was able to reproduce this a while ago, so I was a bit
surprise when this advisory was released, as I thought this was
already known.

> From my point of view the problem here is not the tampering of
non-encrypted/signed Viewstate. The problem lies with applications
that are load-balanced and using signed/encrypted Viewstate.

When Viewstate is used on a single machine, the encryption key/signing
MAC is managed internally and auto-generated. However, when it's being
used on a web farm environment this key has to be shared between all
servers, so it has to be set manually, and here lies the problem. Will
everybody instruct their operations teams to change this on, let's
say, a weekly basis?

Worse even, now that Viewstate is on the spotlight, it's fairly easy
to imagine that someone will write a tool to brute-force it or devise
some easier way to break it. Remember that the MachineKey which is
used to encrypt/sign the Viewstate has other functions besides this
one (Forms authentication tickets and role cookies).

Solutions?

Cheers,

RD


On Fri, Feb 19, 2010 at 2:45 PM, dave <dave () immunityinc com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> http://www.hacking-lab.com/misc/downloads/ViewState_Afames.pdf
>
> This, on first glance, looks real to me. Does anyone have any comments
> on it? ViewState is pretty complex and fairly opaque. If I understand
> properly, MS does not publish the full specs to it? Maybe the Mono team
> found them somewhere?
>
> - -dave
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkt+pCEACgkQtehAhL0ghepUJQCeMs9I2pnL3z4eYicYF44xaUgd
> T4gAnjD/aFU9Z2tWRHge7i4Ch48BS3Ph
> =w0qz
> -----END PGP SIGNATURE-----
> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunitysec com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave


_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave