Message-ID: <200505031053.59218.sflist@digitaloffense.net>
Date: Tue, 3 May 2005 10:53:58 -0500
From: H D Moore <sflist@...italoffense.net>
To: Michal Zalewski <lcamtuf@...il.com>, bugtraq@...urityfocus.com,
	vulnwatch@...nwatch.org
Subject: Re: ASP.NET __VIEWSTATE crypto validation prone to replay attacks

Comments are inline.

On Tuesday 03 May 2005 08:38, Michal Zalewski wrote:
> The data is by *typically* stored on client side as base64-encoded,
> hidden POST form field. By default, the field is protected from
> tampering by being "signed" using SHA1 with machine-specific key

On most deployments, the machine-specific key is regenerated after a 
certain period, so the replay window is limited. On cluster deployments, 
this can be a serious problem, depending on what is stored in the 
ViewState. Web server clusters often share a manually set machineKey 
value and I have yet to see a code base where the cluster machineKey is 
updated on a regular basis. 

> Because information from controls such as DataGrid is by default
> "cached" in __VIEWSTATE, enabling the user to tamper with this data
> would allow for modifying item ID and price data in ASP.NET online
> shops, for example. This possibility is discussed by Microsoft and
> others, with the conclusion that SHA1/MD5 signing prevents it, and
> hence it is safe to rely on __VIEWSTATE cached data in that regard:
[ snip ]
> Storing and then trusting database fields retrieved from user, even
> with SHA1 validation, may send shivers down any infosec guy's or gal's
> spine, but that's the way it'd seem to be done:

This is common practice in the financial services applications -- many 
cash management and online banking systems rely on the ViewState to 
protect internal database IDs. Assuming that the hashing method is secure 
and the key is not bruteforcable within the available window, it puts 
code auditing into a new and somewhat frightening perspective (in some 
cases, you CAN trust external input).

>   1) Injection-through-replay scenarios are still available.
>
>      "Signed" __VIEWSTATE is replayable for the system or cluster that
>      generated it, for that specific .aspx script:

Only within the window that the same machineKey is valid, but you can 
always go generate it again.

>      b) Since there appears to be no expiration mechanism, user may
> keep __VIEWSTATE data and reuse it after availability, pricing, or
> other parameters of items or settings has changed, or ability to access
> certain information has been restricted, effectively obtaining a
> "backdoor" of sorts.

The VSPageID may prevent replay attacks, but I have not tested this. 
Expiration usually occurs on reboot or within a certain period of time 
(24 hours maybe, it has been a while since I tested this).

>      c) The attacker may obtain __VIEWSTATE after entering dangerous or
>         offensive contents or view settings within his session (some of
> which may be not immediately visible), then redirect third parties
> through a webpage with a specific __VIEWSTATE parameter to expose them
> to that contents, or to impose these settings upon that viewer.

This is a problem with many client-side data storage/validation systems 
and can usually be fixed at the page-level in the application. 

>   2) When NOT signed, resource starvation due to __VIEWSTATE complexity
> is possible.

When NOT signed, you can cause havok with all sorts of things. There are a 
dozen different ways to trigger exceptions within the managed code, so 
far I haven't found anything exploitable beyond a DoS. ViewStateMac has 
been enabled by default since the second beta release iirc.

> Possible mitigation method for problem #1: include secure session ID
> within __VIEWSTATE data, correlate with existing session control data,
> or validate and expire appropriately; or sacrifice storage and keep
> this data on server.

> Mitigation method for problem #2: sacrifice CPU cycles to always
> validate data; or store on server.

Encrypting the ViewState can prevent or delay some of these attacks -- the 
ViewStateUserKey (salt) may also be useful, if changed by the application 
on a frequent basis.

> Cheers,
> Michal Zalewski
> SotW plug: http://lcamtuf.coredump.cx/silence/

Excellent work as usual :-) I recommend Silence on the Wire for anyone has 
grown tired of the standard "Hacking Decomposed" style of security books.

-HD

PS. Attached is an old perl script for prodding ASP.Net applications. It 
can quickly check for ViewStateMac and a few other security settings. It 
was designed for ASP.Net 1.0, but still turns up some fun things once in 
a while (trace.axd, etc). 

Download attachment "dnascan.pl.gz" of type "application/x-gzip" (46034 bytes)

Powered by blists - more mailing lists