This post explores how an ASP.NET project incorrectly disclosing its web.config containing static keys allows for remote code execution. The common cases for exploiting this vulnerability would be if the web application has published it’s static machine keys to GitHub, such as with the example project for this post (https://github.com/ozajay0207/EGVC) or if the application has a local file inclusion vulnerability that allows the attacker to obtain a copy of the static keys from the web.config file.

 

In order to keep track of different sessions, ASP.NET applications use a ViewState that contains serialized application defined data. Due to the nature of serialization, if the user can control and create a valid ViewState, then they can use a deserialization attack to achieve remote code execution on the host.

 

In order to mitigate this potential attack ASP.NET applications can perform HMAC signing of the ViewState to verify the authenticity of the object. Another option is using encryption with a secret key to prevent reading or modification of its contents. Keeping these keys secret is paramount in preventing ViewState deserialization attacks and remote code execution.

 

These mitigations rely on each application utilising uniquely generated validation and decryption keys, which is not always the case. Recently, CVE-2020-688 exposed Microsoft for including static validation and decryption keys in the Microsoft Exchange Server’s control panel. The same keys were generated once and shared among every exchange installation allowing anyone with a copy of the server to recover and misuse these key values.

 

To demonstrate this attack, a proof of concept will be performed for a public GitHub project that contained this vulnerability. Figure 1 is the web.config from the chosen project and contains two security issues. Firstly, the validation and decryption key are hard coded and secondly, the ViewState encryption mode has been disabled.

 

​Now that the three required pieces of information have been recovered, a payload can be generated using ysoserial.net. The malicious payload will execute an arbitrary command, in this case a simple PowerShell web request to a controlled endpoint, is used so that the code execution can be verified.

The tool ysoserial.net creates a payload that is base64 encoded but supplying this directly to the server in a request will cause parsing errors. This occurs because the base64 standard includes some symbols, such as the equals sign, that will be misinterpreted in a HTTP request. To remedy this the payload must be URL encoded. With this encoding the necessary symbols will be correctly interpreted by the ASP application.

​
To perform the attack the default packet HTTP POST from the registration form was captured into BurpSuite, and the __VIEWSTATE variable was replaced with the malicious ViewState generated by ysoserial.net. Once the request is sent to the server the PowerShell command is executed, and a corresponding GET request is made to our controlled endpoint.

​From here it is straightforward for an attacker to modify the command to download and execute a malicious PowerShell script and create a reverse shell.