Recommendations
Detecting compromise
The ASD's ACSC recommends examining the following sources for the described events to detect this activity. This analysis can have a high return of false positives based on the server and the websites that are being hosted. Detections should be analysed further to confirm the activity is malicious.
Please see Appendices A and B for communications samples of VIEWSTATE and Telerik for further information. Agencies can use these materials to detect attempts of abuse against VIEWSTATE and Telerik.
IIS / reverse proxy / load balancer logging
All HTTP methods where the VIEWSTATE parameter is set could be exploiting this vulnerability. Analysing IIS, Reverse Proxy and Load Balancer logs for HTTP requests with the following characteristics will help narrow the search and reduce false positives:
- Sequential POST requests receiving 500 responses.
- Excessive requests to individual files, similar to web shell detection logic.
- Large POST to unexpected web pages.
Networking monitoring
Analyse network traffic for requests with the following characteristics:
- GET and POST requests with the VIEWSTATE parameter exceeding 2000 bytes.
- Windows Portable Executable (PE) file within the VIEWSTATE parameter.
IIS debug logs
Analyse IIS debug logs for the following:
- ViewStateException events being generated.
Windows event logs
Analyse Windows application logs looking for Event ID 1316 with the following message and reason:
- Event message: “Viewstate verification failed“
- Reason: “Viewstate was invalid”
Mitigation
Ensure that the MAC validation is enabled
MAC validation ensures that VIEWSTATE fields on web requests have not been modified. This also prevents adversaries from crafting malicious payloads without having the required key material to recreate the MAC.
The ASD's ACSC recommends:
- Ensuring that you are running an up-to-date version of .NET on your IIS servers, particularly that the patches detailed in Microsoft Security Advisory 2905247 are applied.
- Ensuring that the following settings are configured for IIS:
enableViewStateMac is set to 'true'
aspnet:AllowInsecureDeserialization is set to 'false'
Note: These settings may be overwritten by individual web application configurations. Organisations should confirm that no web applications are modifying the above values.
- MAC validation is on by default in up to date versions of .NET, however it can be manually turned off via a registry key. Agencies should ensure that it has not been disabled at the following registry location:
Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v<.NET Version>
Key/Value: AspNetEnforceViewStateMac = 1 (Enabled)
Note: These registry key needs to be checked for all versions of .NET installed on your server.
Regenerate and replace explicit Machine Keys within Web.config
An adversary is reliant on the Machine Keys to pass MAC validation and subsequently leverage the VIEWSTATE vulnerability. If exploitation is suspected or you suspect your server Machine Key has been accessed, the ASD's ACSC recommends remediating Machine Keys by:
- Generating a new Machine Key or set keys to auto-generate if not in a server farm.
- Ensuring that all web applications have unique Machine Keys to add another level of isolation between the applications.
Encrypt plain text Machine Keys in Web.config
Encrypting the Machine Keys hinders an attacker’s future ability to exploit the VIEWSTATE vulnerability if the server is compromised, or if the Machine Keys are leaked. Organisations should implement this by encrypting configuration sections through .NET Framework protected configuration and RSA Protected Configuration Providers.
Set the View State Encryption to Always (only effective for .NET 4.5+)
To ensure encryption is permanently enabled, set the ViewStateEncryptionMode to Always in the appropriate web application web.config file.
Note: While this can be done in lower versions of .NET, an actor can disregard this setting by withholding the VIEWSTATEENCRYPTED from the request.
Ensure that custom error pages are in use
ASP.NET error messages may contain sensitive information that could be used to compromise the system. Organisations should implement custom error pages for ASP.NET errors to ensure that sensitive server information remains private.
Other mitigations
The ASD's ACSC recommends agencies:
- Upgrade to the latest version of .NET, ASP and IIS to ensure all available security patches are applied.
- Implement the strongest possible Crypto Routines to reduce the chance of a brute force attack against Machine Keys.
Incident reporting
If you have questions about this advice or have indications that your environment has been compromised, contact the ASD's ACSC by emailing asd.assist@defence.gov.au or calling 1300 CYBER1 (1300 292 371).
Table of contents
- Detecting compromise
- IIS / reverse proxy / load balancer logging
- Networking monitoring
- IIS debug logs
- Windows event logs
- Mitigation
- Ensure that the MAC validation is enabled
- Regenerate and replace explicit Machine Keys within Web.config
- Encrypt plain text Machine Keys in Web.config
- Set the View State Encryption to Always (only effective for .NET 4.5+)
- Ensure that custom error pages are in use
- Other mitigations
- Incident reporting
- Appendix A: Communications samples of ViewState scanning/exploitation attempts
- ViewState scanning
- Example of IIS log __VIEWSTATE=AAAA
- Example of successful exploitation IIS log
- Example of a HTTP session of successful exploitation of an encrypted __VIEWSTATE parameter, which writes back “AAAAAAAAAAAAAAAAAAAAAAAAAAA” as a response
- Example of a HTTP Session where an encrypted __VIEWSTATE parameter causes an internal server error
- Appendix B: Communications samples of Telerik scanning/exploitation attempts
- Crypto brute force CVE-2017-9428
- Uploading a payload for CVE-2019-18935