Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: ASP.NET __VIEWSTATE crypto validation prone to replay attacks
From: H D Moore <sflist () digitaloffense net>
Date: Tue, 3 May 2005 10:53:58 -0500

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

Attachment: dnascan.pl.gz
Description:


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]