[Owasp-dotnet] FW: ASP.NET __VIEWSTATE crypto validation pron e to replay attacks

[Noah Gray]

This is all pretty obvious to any security-conscious developer using the
technology, however I agree that the cross-page implications are relatively
unknown. Like any technology, it's useful when applicable, but dangerous
when used with blissful ignorance of it's vulnerabilities. 

My understanding of this situation is that a page name check does NOT take
place, but that a path check is enforced. If you want page/querystring
tampering, you could easily use a derived version of Page, or an HttpHandler
to add page name/querystring, as well as the current time to the viewstate.
All of these could then be checked upon the next client post.

hth.

Regards,

Noah Gray

-----Original Message-----
From: P.B. Wagenaar [mailto:PB.Wagenaar at chello.nl] 
Sent: Tuesday, May 03, 2005 10:50 AM
To: owasp-dotnet at lists.sourceforge.net
Subject: [Owasp-dotnet] FW: ASP.NET __VIEWSTATE crypto validation prone to
replay attacks

 

-----Oorspronkelijk bericht-----
Van: Michal Zalewski [mailto:lcamtuf at gmail.com]
Verzonden: dinsdag 3 mei 2005 15:39
Aan: bugtraq at securityfocus.com; vulnwatch at vulnwatch.org
Onderwerp: ASP.NET __VIEWSTATE crypto validation prone to replay attacks

Good morning,

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

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

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:

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

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

  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:

     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 webpage 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 summarised 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 noticable.

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

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

--
I am using the free version of SPAMfighter for private users.
It has removed 1577 spam emails to date.
Paying users do not have this message in their emails.
Try www.SPAMfighter.com for free now!



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Owasp-dotnet mailing list
Owasp-dotnet at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owasp-dotnet