[NT] ASP.NET's __VIEWSTATE Prone to Replay Attacks and DoS

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html 

- - - - - - - - -



  ASP.NET's __VIEWSTATE Prone to Replay Attacks and DoS
------------------------------------------------------------------------


SUMMARY

ASP.NET's extremely popular __VIEWSTATE functionality provides an 
automatic, uniform method for storing current state of all webpage 
"controls" (including form fields, database views, etc), so that 
user-entered data auto-magically persists and is populated across newly 
rendered HTML, and so that current selections of displayed database 
records are cached and do not need to be looked up again after every 
operation.

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 and - although not 
discussed by Microsoft - presumably either target .aspx filename or other 
file ID parameter.

The ASP.NET's __VIEWSTATE field has been found to be prone to replay 
attacks as well as denial of service vulnerabilities.

DETAILS

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:

 <http://msdn.microsoft.com/library/en-us/dnaspp/html/viewstate.asp> 
http://msdn.microsoft.com/library/en-us/dnaspp/html/viewstate.asp

Storing and then trusting database fields retrieved from user, even with 
SHA1 validation, will send shivers down any security guy's or gal's spine, 
but that's the way it'd seem to be done:

<I>"DataGrid stores its contents in the view state so the page developer 
doesn't need to rebind the database data to the DataGrid on each and every 
page load, but only on the first one. The benefit is that the database 
doesn't need to be accessed as often. "</I>

Lacking proper documentation of __VIEWSTATE validation, and based on my 
limited testing, Michal sees two major problems with how the mechanism is 
designed:

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

     a) The attacker may submit __VIEWSTATE acquired from one view, to a 
wholly different view with a reasonably compatible layout of cached 
controls.
 
        For example, if a provider of online shopping solutions hosts two 
distinct shops on a shared scripting platform - one shop with pet 
supplies, and one with expensive watches - and both (within their distinct 
databases or tables) happen to have item ID 123 - one for  $19.99 (Acme 
brand cat food), another for $1999.00 (Rolex), the attacker may move 
__VIEWSTATE from buystuff.aspx?shop=catfood to buystuff.aspx?shop=watches, 
and place an order item ID 123 for $19.99.

     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.

     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 
web-page with a specific __VIEWSTATE parameter to expose them to that 
contents, or to impose these settings upon that viewer.

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

     The format of the base64-encoded data is often summarized as 
"compressed XML"; __VIEWSTATE uses a simplistic, hierarchical markup 
scheme: first letter decides record type (triplet, pair, one of primitive 
types such as strings or integers); values for that record are enclosed in 
<...> that immediately follows that letter; fields of a record are 
separated by ';'; records can be nested with no limits.

     The problem: __VIEWSTATE is sometimes used with no integrity 
protection for valid reasons. If only user input fields are going to be 
cached,  there is no immediate problem with effects of __VIEWSTATE 
tampering (with the possible exception of 1c), and performance benefits of 
avoiding SHA1 are noticeable.

     Unfortunately, because of its hierarchical structure, and parsing 
based on recursive function calls, it is trivial to consume excessive 
amounts of resources by constructing a very deeply nested structure.

Consider this UNIX shell example:
     perl -e '{print "t<" x 8000, ";;>" x 8000}' | \
       mimencode | awk '{printf "%s", $0}'

     Inserting the output of that sequence in place of __VIEWSTATE form 
field value in a page then submitted to a web server that has SHA1 
integrity checking disabled will consume excessive resources on the target 
machine (in some cases, omitting the closing ";;>" sequence offers even 
better effort-gain DoS ratio).

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.


ADDITIONAL INFORMATION

The information has been provided by  <mailto:[email protected]> Michal 
Zalewski.



======================================== 


This bulletin is sent to members of the SecuriTeam mailing list. 
To unsubscribe from the list, send mail with an empty subject line and body to: [email protected] 
In order to subscribe to the mailing list, simply forward this email to: [email protected] 


==================== 
==================== 

DISCLAIMER: 
The information in this bulletin is provided "AS IS" without warranty of any kind. 
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.