VIEWSTATE Vulnerabilities

[Nytro]

[h=3]VIEWSTATE Vulnerabilities[/h][h=2]Friday, January 27, 2012[/h]

1. ViewState Overview

"View state is a method that the ASP.NET page framework uses to preserve page and control values between round trips. When the HTML markup for the page is rendered, the current state of the page and values that must be retained during postback are serialized into base64-encoded strings. This information is then put into the view state hidden field or fields."

MSDN

"What does ViewState do?

- Stores values per control by key name, like a Hashtable

- Tracks changes to a ViewState value's initial state

- Serializes and deserializes saved data into a hidden form field on the client

- Automatically restores ViewState data on postbacks"

From an article on the ViewState mechanisms by an ASP.NET developer

To put it even simplier, ViewState is a hidden HTML parameter that sends a current structure of page content to the server. Example of use: retaining form field values on the page for by-page list scrolling.

Though there are widely used methods of disabling or avoiding ViewState (usually, by means of a DBMS), this mechanism is built in ASP.NET by default and is often misused:

"Even more important than understanding what it does, is understanding what it does NOT do:

What doesn’t ViewState do?

- Automatically retain state of class variables (private, protected, or public)

- Remember any state information across page loads (only postbacks)

- Remove the need to repopulate data on every request

- ViewState is not responsible for the population of values that are posted such as by TextBox controls (although it does play an important role)"

From an article on the ViewState mechanisms by an ASP.NET developer

Obviously, such misuse entails more serious problems, such as a missing filtration or a perverted idea of how the web application should work properly.

Developers tend to believe that if ViewState is a serialized structure, moreover, a base64-encrypted one, no attacker will be able to get to its contents.

However, the truth is, if the encryption and the data integrity check (MAC) are disabled, accessing the content is much simplier than it seems. Let’s decode base64:

Pic. 1. Decoding VIEWSTATE by means of base64_decoder.

Then, open it in the Hex Editor. Now it is evident that any string variable is preceded by bytes that indicate the string’s length (the number of bites depends on the length of the string: a string less than 128 bytes will have one byte for a variable length).

Pic. 2. Spoofing content of the serialized structure.

Authoritative resources state that ASP.NET versions earlier than 2.0 use LosFormatter as a serialization/deserialization algorithm, while version 2.0 and later use ObjectStateFormatter. Thus, to change the variable, one needs to define the length of a new string, overwrite the string, overwrite the byte (bytes) with the string length, encode it back with base64 and insert into __VIEWSTATE.

Pic. 3. Spoofing content of the serialized structure.

2. Vulnerabilities and attacks

Combined with a low-level knowledge of an average specialist about a correct and secure configuration of web applications, such approach generates the following vulnerabilities and provides opportunities for the following attacks:

• Cross-Site Scripting (XSS)

• Content Spoofing

• SQL Injection

• Information Leakage

• Logical Attacks

• ViewState Vulnerabilities as such

• Other vulnerabilities

2.1. Cross-Site Scripting, Content Spoofing

The possibility of content spoofing for an HTML page comes out of ViewState main purpose, i.e. to preserve page and control values. If data from ViewState placed into the HTTP response body are not filtered properly, it results in Content Spoofing and/or Cross-Site Scripting.

Vulnerable configuration:

EnableViewStateMac=false

ViewStateEncryptionMode=never|auto

(Depends on RegisterRequiresViewStateEncryption)

ViewStateUserKey=EMPTY

2.2. Information Leakage, Logical Attacks

If developer does not encrypt the VIEWSTATE parameter (Securing View State), an attacker can decode the VIEWSTATE structure and extract confidential data. If developer does not check data integrity (MAC), an attacker can change parameters that can influence the web application logic, thus facilitating Authentication Bypass, Authorization Bypass, and Abuse of Functionality.

Vulnerable configuration:

ViewStateEncryptionMode=never|auto

EnableViewStateMac=false|true

2.3. Attacks Against ViewState

The ViewState itself is also vulnerable to attacks. For example, September, 2010 saw a publication describing a vulnerability that allowed decrypting AES-encrypted ViewState by sending numerous requests to a server and tracking various error codes (Important: ASP.NET Security Vulnerability - ScottGu's Blog).

Besides, the earlier versions (1.0, 1.1) are vulnerable to the Denial Of Service (DoS) attacks (against unencrypted VIEWSTATE) and the Replay attacks (against encrypted VIEWSTATE). The latter one is an attack against a cryptographic protocol consisting in resending an intercepted package that will be received appropriately, thus breaking the algorithm. These attacks were described by Michal Zalewski as far as in 2005 (Bugtraq: ASP.NET __VIEWSTATE crypto validation prone to replay attacks).

2.4. Other Vulnerabilities

All other vulnerabilities common for web applications, such as SQL injection, OS Commanding, as well as other vulnerabilities of such types as Code Exploitation, Information Disclosure, etc. can and should be checked both in variables of the ViewState structure and in ordinary variables sent by GET/POST/COOKIES.

Vulnerable configuration:

EnableViewStateMac=false

ViewStateEncryptionMode=never|auto

(depends on RegisterRequiresViewStateEncryption)

3. Protection

3.1. EnableViewStateMac

Default: TRUE

Since: 1.0

Enables MAC (Machine Authentication Check) to check the VIEWSTATE parameter values by means of a checksum.

Set the EnableViewStateMac property to "True" in the Page element.

Besides, the activation requires configuring the validationKey and validation properties of the machineKey element.

The following in-built encrypting algorithms are supported: SHA1, MD5, 3DES, AES, HMACSHA256, HMACSHA384, HMACSHA512.

3.2. ViewStateEncryptionMode

Default: Auto

Since: 2.0

Allows encrypting the VIEWSTATE parameter by any of the following algorithms: DES, 3DES, AES.

For activation, configure the decryptionKey and decryption properties of the machineKey element.

3.3. ViewStateUserKey

Default: EMPTY

Since: 1.1

Not everyone knows that ViewState protects not only itself against spoofing, but the entire application against CSRF by means of the ViewStateUserKey parameter.

ViewStateUserKey is just a protection mechanism. It is a developer’s duty to ensure its unpredictable and random nature.

Set the ViewStateUserKey property to "String" in the Page element.

4. Conclusion

Sections 2 and 3 provide sound evidence that, configured by default, ViewState is secured against vulnerabilities that are not 0-day. However, quite often developers, after having struggled with constantly appearing error notifications about integrity violation, faulty arguments, etc., end up disabling keys that provoke errors, thus leaving the application vulnerable to various attacks.

Yet, if the web application is properly configured, the probability of errors and even vulnerabilities can be minimized down to 0.

Sursa: [Positive Technologies] Research Lab: VIEWSTATE Vulnerabilities