A workaround you can use to protect your application from
the public exploit is to enable the <customErrors> feature of ASP.NET,
and explicitly configure your applications to always return the same error
response - regardless of the error encountered on the server. By mapping
all error pages to a single error page, you can make it more difficult for an
attacker using the public exploit to distinguish between the different types of
errors that occur on a server. I covered how to implement the workaround in
this blog post.
If you are using .NET Framework version 3.5 SP1 or 4.0, the
workaround provides further protection by also helping to mitigate against
potential timing analysis attacks. The workaround uses the redirectMode="ResponseRewrite"
option in the customErrors feature, and introduces a random delay in the error
page. These approaches work together to make it more difficult for an
attacker to deduce the type of error that occurred on the server by measuring the
time it took to receive the error.
Can I configure a custom 404 error page response and a
default redirect for all other errors?
No. By doing this you are still letting an attacker draw
distinction between a 404 and other errors. Homogenizing errors is a crucial
component to mitigating this attack. Note that this is a workaround until
a security patch is available to fix the underlying product vulnerability. This
workaround will not be required once we release a security update.
Am I vulnerable if I have my own custom error module?
If the responses that are sent out from your custom logging
module do not let the client distinguish between error responses either through
its content or time that it takes to serve out, then such a module is an
adequate replacement for the customErrors workaround. These responses include
both the entire HTTP response and the HTTP error code. If any of the above is
not true at all times, then this is not sufficient. Instead you should
send out the same error response for all errors until the security update is
available to fix the underlying vulnerability.
Should I be concerned about this vulnerability if I don’t
store any sensitive information in my viewstate?
Yes you should. There is a combination of attacks that
was publicly demonstrated that can leak the contents of your web.config file,
including any sensitive, unencrypted, information in the file. You should
apply the workaround to block the padding oracle attack in its initial stage of
the attack. The security update will fix this vulnerability.
What are best practices to secure my data within the
web.config file?
It is always a best practice to encrypt sensitive
configuration data within web.config files. That way if your web.config file is
ever exposed, attackers can not use its contents maliciously. This MSDN
documentation describes how to encrypt web.config file configuration sections: http://msdn.microsoft.com/en-us/library/zhhddkxy(VS.80).aspx.
This tutorial also provides more samples of how to encrypt web.config file
contents: http://www.4guysfromrolla.com/articles/021506-1.aspx
Why am I getting an error running the vulnerability
detection .vbs script?
In my initial blog post I pointed at a .vbs script that you can
run against a server to identify any applications within it that need to have
their <customErrors> sections updated as a workaround against the
publicly disclosed exploit.
On IIS 7, the script requires you to have the IIS 6 management
compatibility feature installed to be able to use this script. To enable
this, run Add/Remove Programs on workstations and Add Web Server Role Services
on server operating systems and select the IIS 6.0 Management Compatibility
feature under the “Internet Information Services” feature area. If this feature
is already installed, please ensure that you are running the script with
Administrator privileges.
