Microsoft.NET Framework 4.5 Click the Download Free Trial button above and get a 14-day, fully-functional trial of CrossOver. After you've downloaded CrossOver check out our YouTube tutorial video to the left, or visit the CrossOver Chrome OS walkthrough for specific steps. Run Microsoft.NET Framework 4.0 on Mac, Linux & Chrome OS The.NET Framework is a standardized, language-agnostic set of libraries aimed at Windows development. Downloads for building and running applications with.NET Framework 4.0. Get web installer, offline installer, and language pack downloads for.NET Framework. I need to download.NET Framework 3.5 Service Pack 1 (microsoft download) to enter a website for work. You have a Mac,.Net Framwork is for Windows and normally. Target.Net Framework 4.7.1 by setting Scripting Runtime Version to.Net 4.x Equivalent in Edit/Project Settings/Player/Scripting Runtime Version Open up the project in Visual Studio Code Observe the plugin fails to load the assemblies.
Introduction
ASP.NET web applications use ViewState in order to maintain a page state and persist data in a web form. The ViewState parameter is a base64 serialised parameter that is normally sent via a hidden parameter called __VIEWSTATE
with a POST request. This parameter is deserialised on the server-side to retrieve the data.
It is normally possible to run code on a web server where avalid ViewState can be forged. This can be done when the MAC validation featurehas been disabled or by knowing the:
- Validation key and itsalgorithm prior to .NET Framework version 4.5
- Validation key, validationalgorithm, decryption key, and decryption algorithm in .NET Framework version4.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 [1]. It then verifies the signature using the message authentication code (MAC) validation mechanism. The ObjectStateFormatter
class [2] 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:
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] 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], it is still possible to disable the MAC validation feature by setting the AspNetEnforceViewStateMac
registry key to zero in:
Alternatively, adding the following dangerous setting to the application level web.config
file can disable the MAC validation as well:
Using this undocumented setting (see [5]) is as simple as using the old enableViewStateMac
property! This was identified by reviewing the .NET Framework source code [6]. The following comment was also found in the code: “DevDiv #461378: EnableViewStateMac=false can lead to remote code execution” [7].
Before December 2013 when most of us did not know about the danger of remote code execution via deserialisation issues in ViewState, the main impacts of disabling the MAC validation were as follows (see [8]):
- Setting arbitrary values in the controls
- Changing the control state
- Performing cross-site scripting (XSS) attacks
At the time of writing this blog post, the following wellknown web application scanners had rated the “ASP.NET ViewState without MACenabled” vulnerability with low and medium severity which shows the lack ofawareness in this area:
- Burp Suite: Low [9]
- Netsparker: Medium [10]
- Acunetix: Medium [11]
When ViewState MAC validation has been disabled, the YSoSerial.Net project [12] can be used to generate LosFormatter
payloads as the ViewState in order to run arbitrary code on the server.
Prior to the .NET Framework version 4.5, the __VIEWSTATE
parameter could be encrypted whilst the MAC validation feature was disabled. Itshould be noted that most scanners do not attempt to send an unencryptedViewState parameter to identify this vulnerability. As a result, manual testingis required to check whether the MAC validation is disabled when the __VIEWSTATE
parameter has been encrypted. This can be checked by sending a short randombase64 string in the __VIEWSTATE
parameter. The following URL shows anexample:
If the target page responds with an error, the MACvalidation feature has been disabled otherwise it would have suppressed the MACvalidation error message. If a POST request is used, the __VIEWSTATE
parameter should be in the body of the request.
The above test case works even when it is not possible tosee the details of error messages (so it is not possible to look for “Validationof viewstate MAC failed”). However, when the ViewStateUserKey
property has been used, the page would not ignore the errors, and withoutseeing the actual error message, it is hard to say whether the MAC validationhas been disabled.
As the targeted box might not send any requests externally, automatedscanners 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 createa 10-second delay:
Net Framework 4.8.2
The above code could be executed using the ActivitySurrogateSelector
gadget of YSoSerial.Net. Modifying other gadgets can be useful if a shorter payloadis required. For instance, the xaml_payload
variable in the TextFormattingRunProperties
gadget can be changed to:
Enabled ViewState MAC Validation
Knowledge of used validation anddecryption keys and algorithms within the machineKey
section of the configuration files (web.config
or machine.config
)is required when the MAC validation feature is enabled. As mentionedpreviously, this is the default configuration for all .NET Framework versionssince September 2014. The following machineKey
section showsan example:
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] for more details.
The way .NET Framework signs and encrypts the serialised objects has been updated since version 4.5. As a result, knowing the targeted application’s framework version is important to create a valid payload. The following machineKey
section shows an example that chooses .NET Framework version 4.5 or above (also see [14]):
In older versions (prior to 4.5), .NET Framework uses the TemplateSourceDirectory
property [15] 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 frameworkand enforce ViewState encryption can still accept a signed ViewState without encryption.This means that knowing the validation key and its algorithm is enough toexploit a website. It seems ViewState is encrypted by default since version 4.5even when the viewStateEncryptionMode
property has been set to Never
.This means that in the latest .NET Framework versions the decryption key andits algorithm are also required in order to create a payload.
The ASP.NET ViewState contains a property called ViewStateUserKey
[16] that can be used to mitigate risks of cross-site request forgery (CSRF) attacks [4]. 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] shows an implemented example).
YSoSerial.Net Plugin to the Rescue!
I have created the ViewState YSoSerial.Net plugin in order to create ViewState payloads when the MAC validation is enabled and we know the secrets. It supports the main and v2 branches ([18], [19]).
This plugin supports the following arguments:
A few examples to create a ViewState payload are as follows.
For .NET Framework >= 4.5:
For .NET Framework <= 4.0 (legacy):
The decryptionKey and its algorithm are not requiredhere:
Apart from using different gadgets, it is possible to usethe __VIEWSTATEGENERATOR
parameter instead of providingthe paths:
It uses the ActivitySurrogateSelector gadget by defaultthat requires compiling the ExploitClass.cs class in YSoSerial.Net project. TheViewState payload can also be encrypted to avoid WAFs when the decryptionKeyvalue is known:
The ViewStateUserKey
parameter can also be provided as anargument.
As mentioned previously, it is important to find the root ofthe application path in order to create a valid ViewState unless:
- The application uses .NETFramework version 4.0 or below; and
- The
__VIEWSTATEGENERATOR
parameter is known.
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 havebeen provided.
The created plugin handles the requirement when it needs tobe all in lowercase or uppercase automatically. The following URL shows anASP.NET page as an example to make this clearer:
The following screenshot shows thepath tree in IIS:
You can check [20] 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:
If we did not know that “app2” was an application name, wecould use trial and error to test all the directory names in the URL one by oneuntil finding a ViewState that can execute code on the server (perhaps bygetting a DNS request or causing a delay).
Note: Due to the nature of used gadgets inYSoSerial.Net, the target ASP.NET page always responds with an error even whenan exploit has been executed successfully on the server-side.
Exploiting Older Versions
No gadget was identified to exploit .NET Framework v1.1 atthe 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] can be used (this was originally developed as part of another research [22]). 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. Although this is not ideal, it was tested on an outdated Windows 2003 box that had the following packages installed which is very common:
Additional Tips for Testers
Net Framework 4 7 2
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 URLlength that limits the type of gadgets that can be used here. During this research,I managed to use the TextFormattingRunProperties
gadget in YSoSerial.Net to exploitan application by sending the payload in the URL.
Encryption in .NET Framework prior to version 4.5
As mentioned previously,the __VIEWSTATE
parameter does not need to be encrypted whenexploiting .NET Framework 4.0 and below (tested on v2.0 through v4.0) even whenthe ViewStateEncryptionMode
property has been set to Always
. ASP.NET decideswhether 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 ispossible to send an unencrypted ViewStated by removing the __VIEWSTATEENCRYPTED
parameter from the request.
This also means that changing the decryption key or itsalgorithm cannot stop the attacks when the validation key and its algorithmhave been stolen.
The __VIEWSTATE
parameter can be encrypted in order tobypass 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 byremoving the __VIEWSTATE
parameter from the request or by adding the __PREVIOUSPAGE
parameter with an invalid value. As the __PREVIOUSPAGE
parameter isencrypted and base64 formatted by default, even providing a single character asits value should cause an error.
This might result in bypassing the anti-CSRF protectionmechanism 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 .NETFramework version 4.0 or below in order to sign a serialised object withoutknowing the application path.
ViewState chunking to bypass WAFs
It is possible tobreak the __VIEWSTATE
parameter into multipleparts when the MaxPageStateFieldLength
property has been set to a positive value. Its default value is negativeand it means that the __VIEWSTATE
parameter cannot be broken into multiple parts.
This might beuseful to bypass some WAFs when ViewState chunking is allowed.
Exploiting the EventValidation parameter
The __EVENTVALIDATION
parameter and a few other parameters arealso 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:
Valueof 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 validsignature is different based on the used parameter. The following table showsthe defined Purpose
stringsin .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
parameterexists in the request with invalid data, the application does not deserialisethe __VIEWSTATE
parameter. Providing the __CALLBACKID
parameter preventsthis behaviour.
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 goodchoice for an attacker. This can be done by disabling the MAC validation andsetting the viewStateEncryptionMode
property to Always
.This means that all ASP.NET pages that do not set the ViewStateEncryptionMode
property to Auto
or Never
always useencrypted ViewState parameters. However, as the ViewState do not use the MACvalidation feature, they are now vulnerable to remote code execution viadeserialising untrusted data. The following shows an example:
Another option for a stand-alone website would be to set themachineKey
section with arbitrary keys and algorithms to stop other attackers!
Disabling the ViewState
It should be noted that setting the EnableViewState
property to False
does not stop this attackas the ViewState will still be parsed by ASP.NET.
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 theMAC validation errors with the following setting even when the ViewStateUserKey
property is used:
This different behaviour can make the automated testing usingerror messages complicated especially when custom error pages are used.
Recommendations
The following list shows how to mitigate risks of thisattack:
- Ensure that the MAC validation is enabled.
- If the ViewState parameter is only used on one machine, ensurethat the MachineKey parameters are being generated dynamically at run time perapplication.
- Encrypt any sensitive parameters such as the
machineKey
section within theconfiguration files. - Consider using the
ViewStateUserKey
property. Its value can be consist of two parts: The first part that is used asthe anti-CSRF protection mechanism can be disclosed to the users. The secondpart should be robustly random and unpredictable and remain as a secret on theserver-side. - Any disclosed validation or decryption keys need to beregenerated.
- Ensure that custom error pages are in use and users cannot seethe actual ASP.NET error messages.
The History
Since when do weknow about the RCE using ViewState?
Exploiting untrusted data deserialisation via the ViewStateis not a new attack. In fact, it has been known publicly for at least 5 yearsat the time of writing this blog post.
There was an interesting presentation from Alexandre Herzog in November 2014 regarding exploiting the deserialisation issues in SharePoint when the MAC validation was disabled in certain pages [23]. It seems that he had used James Forshaw’s research [24] to forge his exploit and reported it to Microsoft in September 2012.
Microsoft released an update for ASP.NET 4.5.2 in December 2013 [25] to remove the ability of .NET applications to disable the MAC validation feature as it could lead to remote code execution. This patch was extended in September 2014 [3] to cover all the versions of .NET Framework.
The easy exploitation mechanism was known publicly after Alvaro Muñoz & Oleksandr Mirosh published their gadgets in BlackHat 2017 [26]. It was then possible to use the YSoSerial.Net project [12] to create the LosFormatter
class payloads.
Exploiting ASP.NET web applications via ViewState has also been mentioned directly in BlueHat v17 by Jonathan Birch in November 2017 [27], and has also been covered by Alvaro Muñoz in the LOCOMOCO conference in April 2018 [28].
I might have missed some parts of the history here so pleasefeel free to enlighten me by leaving me a comment or message me in Twitter; Iwill try to verify and publish it when I can.
Other tools
It seems Immunity Canvas supports creating the ViewState parameter when the validation and encryption keys are known [29]. 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 (written in Python)
- https://github.com/Illuminopi/RCEvil.NET (written in .NET)
I think these tools currently do not differentiate betweendifferent 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. I like the fact that theviewgen application has been written in Python as it makes it portable to otherplatforms as well as web scanners such as Burp Suite. I hope to see furtherdevelopments in these tools to support the missing features.
I confirm that I did not use any of the above tools duringthis research and creation of the ViewState YSoSerial.Net plugin.
Thank You!
Kudos to NCC Group and my colleagues for their supportwhilst performing a major part of this research.
Additional kudos to Alvaro Muñoz for his support by givingme access to his code and helping me in updating the YSoSerial.Net project.
Updates
06/08/2019:
The following blog posts are related to this research:
A video link for Immunity Canvas was added to the references and also in the “Other tools” section.
This post has been nominated in the “pwnie for most under-hyped research” category in 2019 pwnie awards[30]!
References
[1] https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.losformatter
[2] https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.objectstateformatter
[3] https://devblogs.microsoft.com/aspnet/farewell-enableviewstatemac/
[4] https://www.owasp.org/index.php/Anti_CSRF_Tokens_ASP.NET
[5] https://docs.microsoft.com/en-us/previous-versions/aspnet/hh975440(v=vs.120)
[6] https://github.com/Microsoft/referencesource/blob/master/System.Web/Util/AppSettings.cs#L59
[7] https://github.com/Microsoft/referencesource/blob/master/System.Web/UI/Page.cs#L4034
[8] https://www.troyhunt.com/understanding-and-testing-for-view/
[9] https://portswigger.net/kb/issues/00400600_asp-net-viewstate-without-mac-enabled
[10] https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/viewstate-mac-disabled/
[11] https://www.acunetix.com/vulnerabilities/web/view-state-mac-disabled/
[12] https://github.com/pwntester/ysoserial.net/
[13] https://docs.microsoft.com/en-us/dotnet/api/system.web.configuration.machinekeysection
[14] https://docs.microsoft.com/en-us/dotnet/api/system.web.configuration.machinekeysection.compatibilitymode
[15] https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.control.templatesourcedirectory
[16] https://docs.microsoft.com/en-us/previous-versions/dotnet/articles/ms972969(v=msdn.10)
[17] https://software-security.sans.org/developer-how-to/developer-guide-csrf
[18] https://github.com/pwntester/ysoserial.net/tree/master/ysoserial/Plugins/ViewStatePlugin.cs
[19] https://github.com/pwntester/ysoserial.net/tree/v2/ysoserial/Plugins/ViewStatePlugin.cs
[20] https://docs.microsoft.com/en-us/iis/get-started/planning-your-iis-architecture/understanding-sites-applications-and-virtual-directories-on-iis
[21] https://github.com/nccgroup/VulnerableDotNetHTTPRemoting/tree/master/ysoserial.net-v2
[22] https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2019/march/finding-and-exploiting-.net-remoting-over-http-using-deserialisation/
[23] https://www.slideshare.net/ASF-WS/asfws-2014-slides-why-net-needs-macs-and-other-serialization-talesv20
[24] https://media.blackhat.com/bh-us-12/Briefings/Forshaw/BH_US_12_Forshaw_Are_You_My_Type_Slides.pdf
[25] https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2013/2905247
[26] https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf
[27] https://www.slideshare.net/MSbluehat/dangerous-contents-securing-net-deserialization
[28] https://speakerdeck.com/pwntester/dot-net-serialization-detecting-and-defending-vulnerable-endpoints?slide=54
[29] https://vimeopro.com/user18478112/canvas/video/260982761
[30] https://web.archive.org/web/20190803165724/https://pwnies.com/nominations/
In this post, we will cover the difference between two popular frameworks by Microsoft – NET Core vs NET Framework.
Intro
.NET is the development platform used by a large number of developers to create apps, websites, and services on any device and OS, with amazing performance and great developer productivity.
New audiences moving to .NET are mostly confused about the starting point. Is it the .NET framework they need to learn or start with .net core?
Sometimes the question arises in minds of the existing .NET developers.
- Should I learn .NET Core?
- Will Microsoft replace .NET Framework with .NET Core completely?
Thinking about all the battle of these frameworks – NET Core vs NET framework, trying an attempt to list out the differences between .NET Core and .NET framework with the help of this post.
.NET Framework
The .NET Framework helps you create mobile, desktop, and web applications that run on Windows PCs, devices, and servers, and it’s included in Visual Studio.
This post is specific to NET Core vs NET framework, if you want to read more on .NET Framework please refer to the article:
👉 What is the .NET Framework?
.NET Core
.NET Core is a cross-platform, open-source framework that helps us to develop web, mobile, and desktop applications.
.NET Core and ASP.NET Core gives you a blazing fast and modular platform for creating server applications that run on Windows, Linux, and Mac.
👉Learn More
NET Core vs NET Framework
I have jotted down a few of the differences between .NET Core and .NET Framework.
Please feel free to add to this list by commenting on your inputs in the comments section, if you have something to add.
.net Framework 4 7 Download
.NET Core | .NET Framework |
The .NET Core is an open-source platform. | Not an open-source platform |
.NET Core is cross-platform. It runs on Windows, Linux, and Mac operating systems. | .NET framework is not cross-platform. It runs only on the Windows operating system. |
Can be used while building applications that can run on any platform, including ASP.NET Core for cross-platform web apps. | Can be used while building a desktop Windows app or working with ASP.NET. |
Distributed with the app. | Distributed with Windows. |
.NET Core is a subset of .NET Framework and is compatible with .NET Framework.
Net Framework 4.6
Which one to choose?
I have listed down a few criteria to make a choice of NET CorevsNET Framework. Few years down the line, you may not want to choose the .NET Framework at all.
.NET Core is a better choice if you:
- Want to target your apps across platforms such as Windows, Linux, and Mac operating systems.
- Open towards learning new things.
- Are not afraid to explore things, since .NET Core is not fully matured yet.
- Ready for many more changes on the way and learning new things.
.NET Framework is a better choice if you:
- Do not need cross-platform support for your app.
- Not open towards learning new things.
- Are already working on an existing app and extending its functionality.
- Need a stable environment to work in.
- Have to meet your already planned schedule (deadlines).
- Already have an existing team with .NET Framework expertise.
Hope you found this post useful and you got to know the differences between .NET Core and .NET framework.
👉 Further reading – docs.microsoft.com
Please share it with your fellow developer friends as someone rightly said that –
Power is gained by sharing knowledge, not hoarding it.
Our Insta Page
.net Framework 4 For Mac
Follow @dotnetcrunch to learn concepts in a few minutes.
A post shared by DotNetCrunch️️ (@dotnetcrunch) on
What are your thoughts?
Net Framework 4.6.2 Download
Dear Reader,
If you have any questions or suggestions please feel free to email us or put your thoughts as comments below. We would love to hear from you. If you found this post or article useful then please share along with your friends and help them to learn.
Happy Coding!
.net Framework 4
[mashshare]