|
|
|
|
| |
Credit:
The information has been provided by Microsoft Security.
The original article can be found at: http://www.microsoft.com/technet/security/Bulletin/MS06-033.mspx
|
| |
Vulnerable Systems:
* .NET Framework 2.0 for the following operating system versions: Download the update (KB922481)
* Microsoft Windows 2000 Service Pack 4
* Microsoft Windows XP Service Pack 1 or Windows XP Service Pack 2
* Microsoft Windows XP Professional x64 Edition
* Microsoft Windows XP Tablet PC Edition
* Microsoft Windows XP Media Center Edition
* Microsoft Windows Server 2003 or Windows Server 2003 Service Pack 1
* Microsoft Windows Server 2003 for Itanium-based systems and Microsoft Windows Server with SP1 for Itanium-based Systems
* Microsoft Windows Server 2003 x64 Edition
* ASP.NET
Immune Systems:
* Microsoft .NET Framework 1.0
* Microsoft .NET Framework 1.1
* Microsoft Windows 98, Microsoft Windows 98 Second Edition (SE), and Microsoft Windows Millennium Edition (Me)
.NET 2.0 Application Folder Information Disclosure Vulnerability - CVE-2006-1300
This Information Disclosure vulnerability could allow an attacker to bypass ASP.Net security and gain unauthorized access to objects in the Application folders explicitly by name. Note that this vulnerability would not allow an attacker to execute code or to elevate their user rights directly, but it could be used to produce useful information that could be used to try to further compromise the affected system.
Mitigating Factors for .NET 2.0 Application Folder Vulnerability - CVE-2006-1300:
* Directory browsing is not enabled by default on Application folder directories. An attacker would have to guess or know the names of the files they are attempting to retrieve or view.
* By default, file extensions that are used by Visual Studio and ASP.NET web projects are mapped to the aspnet_isapi.dll System.Web.HttpForbiddenHandler and as a result, files with these extensions cannot be retrieved or viewed remotely using this vulnerability.
Here's the full list of file extensions that are protected (and not vulnerable): *.asax, *.ascx, *.master, *.skin, *.browser, *.sitemap, *.config (but not *.exe.config or *.dll.config), *.cs, *.csproj, *.vb, *.vbproj, *.webinfo, *.licx, *.resx, *.resources, *.mdb, *.vjsproj, *.java, *.dd, *.jsl, *.ldb, *.ad, *.ldd, *.sd, *.cd, *.adprototype, *.lddprototype, *.sdm, *.sdmDocument, *.mdf, *.ldf, *.exclude, *.refresh
* IIS 6.0 will not send any file types that do not have a MIME mapping defined for the IIS 6.0. IIS 6.0 only stores the allowed MIME mappings in the metabase.
For example if a custom file type with a .data file extension is located in the app_data folder on an IIS6 server, but there is no MIME association for .data files defined in IIS or the Windows Registry on that server, Internet Information Services (IIS) will not serve this type of file and will return a 404 error (regardless of what folder / directory the file resides in).
* Customers using URLScan who have followed the guidance in Knowledge Base Article 815155 for hardening ASP.NET web applications are at less risk from this vulnerability.
Workarounds for .NET 2.0 Application Folder Vulnerability - CVE-2006-1300:
Microsoft has tested the following workarounds. While these workarounds will not correct the underlying vulnerability, they will help to block known attack vectors. When a workaround reduces functionality, it is identified in the following section.
* Remove Read permission from all ASP.NET 2.0 Application folders.
Removal of the Read permissions for Web content helps protect the affected system from attempts to exploit this vulnerability.
To set permissions for Web content on Windows 2000 running IIS5.0 using the Microsoft Management Console (MMC):
1. Click Start, then click Run and then type: %systemroot%\system32\inetsrv\iis.msc
2. When the Internet Information Services MMC snap-in loads, in the left pane, click the plus (+) sign next to the computer name to expand the list of web sites hosted on that server.
3. Expand the first web site by clicking the plus (+) sign next to it.
4. For each ASP.NET 2.0 Application Folder , right click on the folder and select Properties
For a complete list of ASP.NET 2.0 Application Folders visit this website.
5. On the Directory or Virtual Directory tab clear the checkbox next to Read and press OK
6. Repeat step 3 for each web site and application hosted on the server.
To set permissions for Web content on Windows 2003 with IIS 6.0 using the Microsoft Management Console (MMC):
1. Click Start, click Run and then type: %systemroot%\system32\inetsrv\iis.msc
2. When the Internet Information Services MMC snap-in is finished loading, in the left pane, click the plus (+) sign next to the computer name
3. Click the plus (+) sign next to the Web sites folder to expand the list of web sites hosted on that server.
4. Expand the first web site by clicking the plus (+) sign next to it.
5. For each ASP.NET 2.0 Application Folder , right click on the folder and select Properties
For a complete list of ASP.NET 2.0 Application Folders visit this website.
6. On the Directory or Virtual Directory tab clear the checkbox next to Read and press OK
7. Repeat step 4 for each web site and application hosted on the server.
Impact of Workaround: Denying read access on the virtual directory would block reflection and therefore inhibits remote debugging.
* Use URLScan with the DenyUrlSequences setting to disallow URLs that request protected file extensions.
1. If URLScan is already installed, make a backup copy of the URLScan.ini before continuing to the next step.
2. Configure the URLScan.ini (located in the %windir%\system32\inetsrv\urlscan folder by default) with the following settings:
3. In the [Options] section, ensure that NormalizeUrlBeforeScan is set to 1
4. In the [Options] section, ensure that VerifyNormalization is set to 1
5. In the [DenyUrlSequences] section, ensure that the backslash \ character is listed
6. Re-start IIS for the changes to take effect.
Note The above settings are enabled by default in versions of URLScan installed by the IIS Lockdown wizard and for all stand-alone installations of URLScan 2.5.
Note For additional information on configuring URLScan to work with ASP.NET applications refer to Knowledge Base Article 815155.
Impact of Workaround: Improper configuration of URLScan could prevent some web applications from functioning properly.
Use file extensions for files in the App_* folders that are not mapped to ASP.NET and that have no MIME type mapping that IIS can use.
If a static file extension has no MIME type mapping Internet Information Services 6.0 (IIS) will not serve it.
Impact of Workaround: None
FAQ Workarounds for .NET 2.0 Application Folder Vulnerability - CVE-2006-1300:
What is the scope of the vulnerability?
This information disclosure vulnerability could allow an attacker to bypass ASP.Net security and gain unauthorized access to objects in the Application folder explicitly by name. Note that this vulnerability would not allow an attacker to execute code or to elevate their user rights directly, but it could be used to produce useful information that could be used to try to further compromise the affected system.
What causes the vulnerability?
ASP .NET 2.0 does not properly validate the URL passed.
What is ASP.NET ?
ASP.NET is collection of technologies within the.NET Framework that enable developers to build Web applications and XML Web Services.
Unlike traditional Web pages, which use a combination of static HTML and scripting, ASP.NET uses compiled, event-driven pages. This enables developers to build Web-based applications with the same richness and functionality usually associated with applications built in languages such as Visual Basic or Visual C++. Because ASP.NET is a Web-based application environment, it requires an underlying Web server to provide basic HTTP functionality. For this reason, ASP.NET runs on top of IIS 5.0 on Windows 2000, IIS 5.1 on Windows XP and IIS 6.0 on Windows Server 2003.
What might an attacker use the vulnerability to do?
An attacker who successfully exploited this vulnerability could gain unauthorized access to parts of a Web site. The actions the attacker could take would depend on the specific content being protected.
Who could exploit the vulnerability?
In a Web-based attack scenario, an attacker would have to have access to a Web site that contains an Application Folder to attempt to exploit this vulnerability. Note that this vulnerability would not allow an attacker to execute code or to elevate their user rights directly, but it could be used to produce useful information that could be used to try to further compromise the affected system.
What systems are primarily at risk from the vulnerability?
Internet facing systems are primarily at risk from this vulnerability. In addition, internal Web sites that use ASP.NET to host sensitive data can be at risk from this vulnerability.
Could the vulnerability be exploited over the Internet?
Yes. An attacker could try to exploit this vulnerability over the Internet.
What does the update do?
The update removes the vulnerability by modifying the way that ASP.NET validates URL paths.
When this security bulletin was issued, had this vulnerability been publicly disclosed?
No. Microsoft received information about this vulnerability through responsible disclosure. Microsoft had not received any information to indicate that this vulnerability had been publicly disclosed when this security bulletin was originally issued.
When this security bulletin was issued, had Microsoft received any reports that this vulnerability was being exploited?
No. Microsoft had not received any information to indicate that this vulnerability had been publicly used to attack customers and had not seen any examples of proof of concept code published when this security bulletin was originally issued.
|
|
|
|
|
