Knowledgebase: Dedicated Server Guides
Security Notice: Securing ASP.NET
Posted by Jay Sudowski (Import) on 11 September 2004 02:29 PM
A recent security audit has revealed that some of our fully managed and semi-managed dedicated servers may have been configured with default settings that could leave the server vulnerable to privilege escalation attacks through ASP.NET scripting.
If you are a fully managed dedicated customer, we have already taken the actions outlined below. The only action you need to take is to check any ASP.NET sites to ensure that they are operating correctly. If they are not, please open a helpdesk ticket by emailing [email protected] or visiting
If you are a semi-managed dedicated customer, please review the changes we recommend below. We recommend that all customers implement these changes. Please note these changes may cause disruptions to some of your ASP.NET based domains. After making these changes, we recommend checking your ASP.NET sites to ensure that they are working properly.
Step 1: Application Pool Settings
The first and most important thing is that all of your application pools in IIS are running under the "Network Service" account.  If any application pools are running under the local system account, then it's possible for users to execute .exes they upload under the local system context and gain full access to your server.
To make this change, please follow these steps:

- Login to your server using Terminal Services
- Open up the Internet Services Manager
- Expand the "Application Pools" folder. Right click on each application pool and go to Properties.
- Click on the Identity tab. Change the drop down to "Network Service"
- Click OK
NOTE: Do not make any changes to the MSSharePointAppPool
Step 2: MACHINE.CONFIG Changes
The second item that's crucial is making some configuration changes to your .NET configuration files that force impersonation - that is, they force ASP.NET pages to be executed under the web sites user account, not the network service account. In a shared hosting environment, this will ensure that users cannot use ASP.NET to access other domain's content in any way.   Please follow these steps to make this change:
- Open C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG\Machine.Config using Notepad
- Search for "<identity impersonate="false" userName="" password=""/>" or "<identity impersonate="false" userName="" password=""/>"
- Replace that entire line with:
<location allowOverride="false">
<identity impersonate="true" userName="" password=""/>
-Save and close the file.
Step 3: NETWORK SERVICE permissions
The third change that's necessary is ensuring that 'Network Service' account has the proper permissions on your c:\domains folder.  This user account needs to have READ / EXECUTE permissions on the c:\domains folder for ASP.NET to work correctly. The simplest way to affect this change is as follows:
 - Create a batch file with the following contents:
cacls c:\domains /E /C /G "Network Service":R
FOR /D %%c IN (C:\domains\*) DO cacls %%c /T /E /C /G "Network Service":R 
- Now, execute the batch file.
NOTE: If you have a large number of sites / files on your server, running this script may take a long period of time. Ensure that you keep your terminal services session active. If your session times out, you will have to re-run the batch file from the beginning.
Known Issues: 
- Any sites running DotNetNuke will require some manual permission changes.  You will need to grant the NETWORK SERVICE account Modify permissions on the domain's wwwroot folder.
(1130 vote(s))
Not helpful

Comments (0)
Post a new comment
Full Name:
CAPTCHA Verification 
Please enter the text you see in the image into the textbox below (we use this to prevent automated submissions).