In the Exploiting Deserialisation in ASP.NET via ViewState blog post, I explained how it is possible to run code on an ASP.NET web application using compromised Machine Key secrets. It covers cases in which the keys are hard coded and could be read using another vulnerability such as local file disclosure. However, most websites do not hard code these keys and use automatically generated values by ASP.NET. As a result, it is not simply possible to steal the keys by reading the configuration files.
Now I want to explain how hackers who have already exploited an ASP.NET application can read the auto generated parameters to maintain their access even after their original vulnerability has been patched.
This can also be abused very similar to a hidden key or a backdoor by malicious developers to execute code on a server when they do not have their access anymore.
What do
you do with a comprised box?
Assume this generic scenario: An outdated ASP.NET CMS on IIS
has been hacked using a vulnerability that has been patched in the latest
version of the software.
This is what we know:
The exploit and its patch
are public
A web shell was dropped
No other file changes have
been recorded
Database values have not
been modified by the attacker
No fixed machine key is in
the web.config file
This is what we have done after pulling the server offline:
The web server has been
restored to its pre-attack condition:
Web shell has been deleted
Database has been restored
to its pre-attack condition
Any potential data changes
have been reversed
The CMS application has
been updated
Vulnerability has been
patched
All the hardcoded secrets and
credentials within the application files or the database have been changed
Users’ passwords and other
sensitive tokens in the accessible databases have been reset
Can we go online now without risk of attackers coming
back?
Although some people may say “NO” for other reasons, I like
to say “NO” as the auto generated Machine Key might have been stolen! This can
be enough for hackers to run code on the server whenever they want.
Reading
the Generated Keys
Attackers should be able to calculate the validation and
decryption keys by reading the following registry keys (depends on the .NET
version):
These registry keys belong to the IIS user (Application Pool)
that runs the application.
However, when attackers can run ASP.NET code on the website,
it easier to extract the keys directly. It should be noted that used keys where
ASP.NET Framework 4.5 has been targeted are different than the previous versions.
Auto generated keys can have two modes:
IsolateApps
In this case, it uses the value of HttpRuntime.AppDomainAppVirtualPath (e.g. /dir/appname/) when transforming the auto-generated key to make the validation and decryption keys
IsolateByAppId
In this case, it uses the value of HttpRuntime.AppDomainAppId (e.g. /LM/W3SVC/1/ROOT/dir/appname/ where ‘1’ is the AppId) when transforming the auto-generated key to make the validation and decryption keys. This is useful when two different applications use the same virtual path so their keys will be different.
Different ASP.NET pages within the same application uses the
same set of transformed keys.
I have created a simple proof of concept code in the following GitHub gist in order to extract auto generated validation and decryption keys:
Create a new Application Pool for your ASP.NET application
when you need to reset all the credentials for any reasons. This will ensure
that a new ASP.NET key will be generated for the application.
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 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 [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:
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:
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 well
known web application scanners had rated the “ASP.NET ViewState without MAC
enabled” vulnerability with low and medium severity which shows the lack of
awareness in this area:
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. 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:
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. 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 to
see the details of error messages (so it is not possible to look for “Validation
of viewstate MAC failed”). However, when the ViewStateUserKey
property has been used, the page would not ignore the errors, and without
seeing the actual error message, it is hard to say whether the MAC validation
has been disabled.
As the targeted box might not send any requests externally, 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:
System.Threading.Thread.Sleep(10000);
The above code could be executed using the ActivitySurrogateSelector gadget of YSoSerial.Net. Modifying other gadgets can be useful if a shorter payload
is required. For instance, the xaml_payload variable in the TextFormattingRunProperties
gadget can be changed to:
Knowledge of used validation and
decryption 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 mentioned
previously, this is the default configuration for all .NET Framework versions
since September 2014. The following machineKey section shows
an 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 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] 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:
--examples to show a few examples. Other parameters will be
ignored
-g, --gadget=VALUE a gadget chain that supports LosFormatter.
Default: ActivitySurrogateSelector
-c, --command=VALUE the command suitable for the used gadget (will
be ignored for ActivitySurrogateSelector)
--upayload=VALUE the unsigned LosFormatter payload in (base64
encoded). The gadget and command parameters will
be ignored
--generator=VALUE the __VIEWSTATEGENERATOR value which is in HEX,
useful for .NET <= 4.0. When not empty, 'legacy'
will be used and 'path' and 'apppath' will be
ignored.
--path=VALUE the target web page. example: /app/folder1/pag-
e.aspx
--apppath=VALUE the application path. this is needed in order to
simulate TemplateSourceDirectory
--islegacy when provided, it uses the legacy algorithm
suitable for .NET 4.0 and below
--isencrypted this will be used when the legacy algorithm is
used to bypass WAFs
--viewstateuserkey=VALUE
this to set the ViewStateUserKey parameter that
sometimes used as the anti-CSRF token
--decryptionalg=VALUE the encryption algorithm can be set to DES,
3DES, AES. Default: AES
--decryptionkey=VALUE this is the decryptionKey attribute from
machineKey in the web.config file
--validationalg=VALUE the validation algorithm can be set to SHA1,
HMACSHA256, HMACSHA384, HMACSHA512, MD5, 3DES,
AES. Default: HMACSHA256
--validationkey=VALUE this is the validationKey attribute from
machineKey in the web.config file
--isdebug to show useful debugging messages!
A few examples to create a ViewState payload are as follows.
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:
.\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"
The ViewStateUserKey parameter can also be provided as an
argument.
As mentioned previously, 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.
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.
The created plugin handles the requirement when it needs to
be all in lowercase or uppercase automatically. The following URL shows an
ASP.NET page as an example to make this clearer:
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).
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.
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] 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
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. During this research,
I managed to use the TextFormattingRunProperties gadget in YSoSerial.Net to exploit
an 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 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:
<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:
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.
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:
Another option for a stand-alone website would be to set the
machineKey
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 attack
as 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 the
MAC validation errors with the following setting even when the ViewStateUserKey
property is used:
This different behaviour can make the automated testing using
error messages complicated especially when custom error pages are used.
Recommendations
The following list shows how to mitigate risks of this
attack:
Ensure that the MAC validation is enabled.
If the ViewState parameter is only used on one machine, ensure
that the MachineKey parameters are being generated dynamically at run time per
application.
Encrypt any sensitive parameters such as the machineKey section within the
configuration files.
Consider using the ViewStateUserKey
property. Its value can be consist of two parts: The first part that is used as
the anti-CSRF protection mechanism can be disclosed to the users. The second
part should be robustly random and unpredictable and remain as a secret on the
server-side.
Any disclosed validation or decryption keys need to be
regenerated.
Ensure that custom error pages are in use and users cannot see
the actual ASP.NET error messages.
The History
Since when do we
know about the RCE using ViewState?
Exploiting untrusted data deserialisation via the ViewState
is not a new attack. In fact, it has been known publicly for at least 5 years
at 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 please
feel free to enlighten me by leaving me a comment or message me in Twitter; I
will 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:
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. I like the fact that the
viewgen application has been written in Python as it makes it portable to other
platforms as well as web scanners such as Burp Suite. I hope to see further
developments in these tools to support the missing features.
I confirm that I did not use any of the above tools during
this research and creation of the ViewState YSoSerial.Net plugin.
Thank You!
Kudos to NCC Group and my colleagues for their support
whilst performing a major part of this research.
Additional kudos to Alvaro Muñoz for his support by giving
me 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:
