Important: ASP.NET Security Vulnerability
A few hours ago we released a security advisory in ASP.NET (Microsoft Security Advisory). This vulnerability exists in all versions of ASP.NET.
This vulnerability was publicly disclosed Friday evening at a security conference. We recommend that all clients using ASP.NET immediately apply a temporary solution (described below) to prevent attacks from using it.
What is dangerous vulnerability?
')
Using this vulnerability, an attacker can request and download files from an ASP.NET application such as web.config (which often contains secret data) from the server.
An attacker could also decrypt data sent to the client in an encrypted state (such as ViewState data on the page) by exploiting this vulnerability.
How vulnerability works
To understand how vulnerability works, you need to have an idea about cryptographic oracles. An oracle in the context of cryptography is a system that provides hints in response to questions that you ask it. In this case, the vulnerability is present in ASP.NET and acts as an oracle. This allows an attacker to send encrypted text to a web server and find out if it is correctly decrypted by examining the error codes returned by the server. By completing many similar requests (and observing what errors are returned), an attacker can get enough information to decrypt the rest of the ciphertext.
How to close a vulnerability
A temporary solution that you can use to close this vulnerability is to enable the ASP.NET option and explicitly configure your applications so that they always return the same error page regardless of what error actually occurred on the server. Having redirected all error pages to a single error page you will not allow a hacker to distinguish between different types of errors that occur on the server.
Important : It is not enough to simply turn on the CustomErrors option and set its RemoteOnly attribute to true. You also need to make sure that all errors are configured to return the same page. You need to explicitly set the “defaultRedirect” attribute of the <customErrors> section and make sure that the post-status codes are not set.
Workaround on ASP.NET from V1.0 to V3.5
If you are using ASP.NET 1.0, ASP.NET 1.1, ASP.NET 2.0 or ASP.NET 3.5 then you must follow these steps to enable and address all errors on the same error page:
1) Edit the Web.Config file in the root directory of your ASP.NET application. If the file does not exist, create it in the root directory of the application.
2) Create or edit a section in the web.config file so that its settings are as follows:
3) Then you can add an error.html file to your application that contains the error page of the corresponding appearance. This file will be displayed every time an error occurs in the web application.
Remarks : This is what should be noted in the example above that customErrors is set to “on”, and all errors are handled by the error page specified in the “defaultRedirect” attribute. What is also not defined postatal error pages - you can check this by making sure that there are no <error> elements within the <code> <customErrors> </ code> section. Fulfillment of these conditions will not allow an attacker to distinguish between errors when they occur on the server and prevent information disclosure.
Workaround for ASP.NET V3.5 SP1 and ASP.NET 4.0
If you are using ASP.NET 3.5 SP1 or ASP.NET 4.0 then you need to follow the steps below to enable the <customErrors> option and address all errors on one error page:
1) Edit the Web.Config file of your ASP.NET application. If it does not exist, create it in the root directory of the application.
2) Create or modify the <customErrors> section of the web.config file so that you end up with the following content. Note the use of redirectMode = "ResponseRewrite" in .NET 3.5 SP1 and .NET 4.0:
3) You can add to your application Error.aspx which contains the error page of the corresponding appearance. This file will be displayed every time an error occurs in the web application.
4) We recommend adding the following code to the Page_Load () event handler in the Error.aspx file to add a small random small delay. This will help in further obfuscation errors.
VB version
Below is a version of the Error.aspx file for VB that you can use and which has a small random delay. You do not need to compile this code in the application, optionally you can simply save the Error.aspx file in the application directory on the web server:
C # version
Below is the version of the Error.aspx file for C # that you can use and which has a small random delay. You do not need to compile this code in the application, optionally you can simply save the Error.aspx file in the application directory on the web server:
How to verify that the workaround works
After you have applied the above workaround, you can check that the <customErrors> section is correctly configured by requesting a URL like this from your site: mysite.com/pagethatdoesnotexist.aspx
If you’re not requesting, then you shouldn’t configure correctly. If you see one of the steps above. If you’re connecting to your local browser, you would like to make it possible.
How to find vulnerable ASP.NET applications on a server
We published a .vbs script that you can save and run on your web server to determine if there are installed ASP.NET applications that have the section disabled or that distinguish error messages by the status code.
You can download the .vbs script from here . Just copy / paste the script into a text file called "DetectCustomErrors.vbs" and save it to disk. Then open a command prompt window that runs as administrator and run “cscript DetectCustomErrors.vbs” to run this script on the local web server. It will scan all applications on the web server and check if the correct <customErrors> configuration is specified.
The script will mark every application that has found that the web.config file does not have a <customErrors> section (in which case you need to add it) or it is not configured correctly to offer a temporary solution to disable the vulnerability (in which case you need to update her). The script will display “ok” for the web.config file of each application that will be defined as properly configured. We hope that this will facilitate the search for sources of errors.
Note: We have developed this defining scenario in the last few hours and will improve it further in the future. I will update this section every time we make changes to it.
How to find more information about this vulnerability
You can learn more about this vulnerability from the following sources:
Forum for questions
We set up a separate forum on www.asp.net to help answer questions about this vulnerability.
Post questions here to ask and get help on vulnerabilities.
findings
We will publish more details as we will learn more, and also release a patch that can be used to correct the very cause of the problem (and no longer use the above temporary solution).
Up to this point, please apply the temporary solution mentioned above to all your ASP.NET applications to avoid exploitation of the vulnerability by hackers.
Thank,
Scott
This vulnerability was publicly disclosed Friday evening at a security conference. We recommend that all clients using ASP.NET immediately apply a temporary solution (described below) to prevent attacks from using it.
What is dangerous vulnerability?
')
Using this vulnerability, an attacker can request and download files from an ASP.NET application such as web.config (which often contains secret data) from the server.
An attacker could also decrypt data sent to the client in an encrypted state (such as ViewState data on the page) by exploiting this vulnerability.
How vulnerability works
To understand how vulnerability works, you need to have an idea about cryptographic oracles. An oracle in the context of cryptography is a system that provides hints in response to questions that you ask it. In this case, the vulnerability is present in ASP.NET and acts as an oracle. This allows an attacker to send encrypted text to a web server and find out if it is correctly decrypted by examining the error codes returned by the server. By completing many similar requests (and observing what errors are returned), an attacker can get enough information to decrypt the rest of the ciphertext.
How to close a vulnerability
A temporary solution that you can use to close this vulnerability is to enable the ASP.NET option and explicitly configure your applications so that they always return the same error page regardless of what error actually occurred on the server. Having redirected all error pages to a single error page you will not allow a hacker to distinguish between different types of errors that occur on the server.
Important : It is not enough to simply turn on the CustomErrors option and set its RemoteOnly attribute to true. You also need to make sure that all errors are configured to return the same page. You need to explicitly set the “defaultRedirect” attribute of the <customErrors> section and make sure that the post-status codes are not set.
Workaround on ASP.NET from V1.0 to V3.5
If you are using ASP.NET 1.0, ASP.NET 1.1, ASP.NET 2.0 or ASP.NET 3.5 then you must follow these steps to enable and address all errors on the same error page:
1) Edit the Web.Config file in the root directory of your ASP.NET application. If the file does not exist, create it in the root directory of the application.
2) Create or edit a section in the web.config file so that its settings are as follows:
< configuration >
< system.web >
< customErrors mode ="On" defaultRedirect ="~/error.html" />
</ system.web >
</ configuration >
* This source code was highlighted with Source Code Highlighter .3) Then you can add an error.html file to your application that contains the error page of the corresponding appearance. This file will be displayed every time an error occurs in the web application.
Remarks : This is what should be noted in the example above that customErrors is set to “on”, and all errors are handled by the error page specified in the “defaultRedirect” attribute. What is also not defined postatal error pages - you can check this by making sure that there are no <error> elements within the <code> <customErrors> </ code> section. Fulfillment of these conditions will not allow an attacker to distinguish between errors when they occur on the server and prevent information disclosure.
Workaround for ASP.NET V3.5 SP1 and ASP.NET 4.0
If you are using ASP.NET 3.5 SP1 or ASP.NET 4.0 then you need to follow the steps below to enable the <customErrors> option and address all errors on one error page:
1) Edit the Web.Config file of your ASP.NET application. If it does not exist, create it in the root directory of the application.
2) Create or modify the <customErrors> section of the web.config file so that you end up with the following content. Note the use of redirectMode = "ResponseRewrite" in .NET 3.5 SP1 and .NET 4.0:
< configuration >
< system.web >
< customErrors mode ="On" redirectMode ="ResponseRewrite" defaultRedirect ="~/error.aspx" />
</ system.web >
</ configuration >
* This source code was highlighted with Source Code Highlighter .3) You can add to your application Error.aspx which contains the error page of the corresponding appearance. This file will be displayed every time an error occurs in the web application.
4) We recommend adding the following code to the Page_Load () event handler in the Error.aspx file to add a small random small delay. This will help in further obfuscation errors.
VB version
Below is a version of the Error.aspx file for VB that you can use and which has a small random delay. You do not need to compile this code in the application, optionally you can simply save the Error.aspx file in the application directory on the web server:
<%@ Page Language="VB" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>
< script runat ="server" >
Sub Page_Load()
Dim delay As Byte() = New Byte(0) {}
Dim prng As RandomNumberGenerator = New RNGCryptoServiceProvider()
prng.GetBytes(delay)
Thread.Sleep(CType(delay(0), Integer))
Dim disposable As IDisposable = TryCast(prng, IDisposable)
If Not disposable Is Nothing Then
disposable.Dispose()
End If
End Sub
</ script >
< html >
< head runat ="server" >
< title > Error </ title >
</ head >
< body >
< div >
Sorry - an error occured
</ div >
</ body >
</ html >
* This source code was highlighted with Source Code Highlighter .C # version
Below is the version of the Error.aspx file for C # that you can use and which has a small random delay. You do not need to compile this code in the application, optionally you can simply save the Error.aspx file in the application directory on the web server:
<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>
< script runat ="server" >
void Page_Load() {
byte [] delay = new byte [1];
RandomNumberGenerator prng = new RNGCryptoServiceProvider();
prng.GetBytes(delay);
Thread.Sleep(( int )delay[0]);
IDisposable disposable = prng as IDisposable;
if (disposable != null ) { disposable.Dispose(); }
}
</ script >
< html >
< head runat ="server" >
< title > Error </ title >
</ head >
< body >
< div >
An error occurred while processing your request.
</ div >
</ body >
</ html >
* This source code was highlighted with Source Code Highlighter .How to verify that the workaround works
After you have applied the above workaround, you can check that the <customErrors> section is correctly configured by requesting a URL like this from your site: mysite.com/pagethatdoesnotexist.aspx
If you’re not requesting, then you shouldn’t configure correctly. If you see one of the steps above. If you’re connecting to your local browser, you would like to make it possible.
How to find vulnerable ASP.NET applications on a server
We published a .vbs script that you can save and run on your web server to determine if there are installed ASP.NET applications that have the section disabled or that distinguish error messages by the status code.
You can download the .vbs script from here . Just copy / paste the script into a text file called "DetectCustomErrors.vbs" and save it to disk. Then open a command prompt window that runs as administrator and run “cscript DetectCustomErrors.vbs” to run this script on the local web server. It will scan all applications on the web server and check if the correct <customErrors> configuration is specified.
The script will mark every application that has found that the web.config file does not have a <customErrors> section (in which case you need to add it) or it is not configured correctly to offer a temporary solution to disable the vulnerability (in which case you need to update her). The script will display “ok” for the web.config file of each application that will be defined as properly configured. We hope that this will facilitate the search for sources of errors.
Note: We have developed this defining scenario in the last few hours and will improve it further in the future. I will update this section every time we make changes to it.
How to find more information about this vulnerability
You can learn more about this vulnerability from the following sources:
- Microsoft Security Advisory 2416728
- Understanding the ASP.NET Vulnerability
- Microsoft Security Response Center Blog Post
Forum for questions
We set up a separate forum on www.asp.net to help answer questions about this vulnerability.
Post questions here to ask and get help on vulnerabilities.
findings
We will publish more details as we will learn more, and also release a patch that can be used to correct the very cause of the problem (and no longer use the above temporary solution).
Up to this point, please apply the temporary solution mentioned above to all your ASP.NET applications to avoid exploitation of the vulnerability by hackers.
Thank,
Scott
Source: https://habr.com/ru/post/104511/
All Articles