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).
dnascan.pl.gz
Description: GNU Zip compressed data
