Take Control of the ASPNET Account

CoreCoder

LANGUAGES: C#

ASP.NET VERSIONS: 1.0 | 1.1

Take Control of the ASPNET Account

Learn more about the ASP.NET security context.

By Dino Esposito

ASP.NET performs a sequence of tasks - dubbed collectivelythe ASP.NET process model - aimed at servicing a client request. Currently,ASP.NET supports two models - the default model and the IIS 6 model - and theiruse depends on your operating system and how IIS is configured. The defaultmodel used on Windows 2000 and Windows XP with IIS 5.x is based on an ISAPIextension and an ASP.NET-specific worker process (aspnet_wp.exe) that hosts theCommon Language Runtime (CLR). This model also is used on Windows Server 2003when IIS 6.0 is configured to run in compatibility mode. But the normal mode ofoperation of IIS 6.0 on Windows Server 2003 is known as the IIS 6 processmodel, and it consists of an ISAPI extension and an IIS worker process(w3wp.exe). Within this process, the request goes through an ISAPI extension,which loads the CLR in the process and activates the HTTP runtime pipeline.With IIS 6.0, IIS manages ASP.NET and no longer concerns itself with tasks suchas process recycling, gardening, and isolation from the Web server. Althoughkey differences exist between the two process models, they both leverage acouple of components - an ISAPI extension, and a worker process that hosts theCLR and runs managed code. The interaction of these two components determineshow the ASP.NET subsystem works as well as its security settings.

In this article, I'll focus on the security context inwhich ASP.NET requests are served. The security context in which the ASP.NETruntime operates is affected by privileges and permissions set on thecomponents of the ASP.NET process model. I'll refer mostly to the default IIS5.x process model, and I'll signal any relevant differences in the IIS 6process model.

Serve the Request

When a request hits IIS, the Web server first ensures thatthe request comes from a trusted IP address. If not, the request is rejectedwith the 403.6 HTTP error; if the requested resource belongs to a protectedtype, such as .asax files, IIS returns an HTTP error 403.2. If the resource canbe accessed, IIS attempts to authenticate the caller using Windows' Integrated,Digest, or Basic authentication methods. Which method is used depends on howIIS is configured. To handle the request, IIS picks up a thread from its pooland gives it the identity of the authenticated user; if anonymous access isperformed, the IIS thread has the anonymous identity. The thread now does itsjob and dispatches the request to the ASP.NET ISAPI extension.

The ISAPI extension, named aspnet_isapi, is hosted by theIIS process and therefore runs under the SYSTEM account. The ISAPI extension isa piece of unmanaged code responsible for starting up the ASP.NET workerprocess. The extension must guarantee that the worker process is available andhealthy, and it sends requests to the process for processing. The ISAPIextension and the worker process communicate through a set of named pipes (seeFigure 1). In particular, synchronous pipes are used for callbacks from theworker process into the ISAPI extension to retrieve some server variables andobtain information from IIS. Asynchronous named pipes are used for transportingrequests and responses to and from the worker process.

Figure 1. The ASP.NET ISAPI extension hosted by IIS forwards the HTTPrequest to the ASP.NET worker process using a set of asynchronous named pipes.Then the request is processed through the ASP.NET managed HTTP pipeline.

The ISAPI extension has its own pool of threads, but ituses them only for asynchronous calls to the worker process. The extension doesnot process the HTTP request. The worker process receives the request toprocess along with the security token of the authenticated, or anonymous, IISuser. By default, the worker process runs under the ASPNET account.

The thread within the worker process that picks up therequest inherits the identity token of the IIS thread. If impersonation isdisabled, the thread runs under the account of the parent process - the ASPNETaccount. In the IIS 6 process model, the account of the worker process(w3wp.exe) is a built-in account named NetworkService.

Get to Know the ASPNET Account

The ASPNET account is a local account created when the.NET Framework is installed (see Figure 2). Unlike SYSTEM, which is the defaultaccount for classic ASP applications, ASPNET has few privileges: Access thiscomputer from the network, Deny logon locally, Deny logon through TerminalServices, Log on as a batch job, and Log on as a service. ASPNET also has someNTFS permissions to operate on certain folders and create temporary files andassemblies, including access to the root of the .NET Framework installationfolder, the "Temporary ASP.NET Files" directory, the global assembly cache(GAC) folder, and the Windows system directory.

Figure 2. Here is the Properties dialog box of the ASPNET user account.The account is created when the .NET Framework is installed, and its password isgenerated automatically and stored in the Windows local security authority.

Let's review some common scenarios that involve theASP.NET system security context as opposed to the ASP.NET application securitycontext, which is the context in which you use your own code to authenticateand authorize users.

To create or edit a local file, the worker process threadserving the current request requires access to the file or the containingfolder. The thread runs within the context of the aspnet_wp process (ASPNETaccount) and impersonates an identity only if impersonation is on, which bydefault is false. If impersonation is enabled, the thread might impersonate theaccount propagated by IIS or IUSR_Machine in case of anonymous access; if thethread has an identity token, the token must provide write access to the file.By default, ASP.NET applications don't impersonate accounts and are accessed bythe anonymous user frequently. In this case, the worker process thread inheritsno identity and uses that of the host process - ASPNET. Because ASPNET couldhave no write permissions on the Web space, an exception is thrown if you tryto create or edit a file.

A nearly identical situation occurs if your Webapplication attempts to open a connection to a database. In this case, you needa login defined for ASPNET or the identity being impersonated.

If a new process is to be created, it will inherit theaccount of the parent process. The new process will run under the ASPNETaccount whether or not impersonation is set.

The limited set of privileges granted to the ASPNETaccount helps fend off revert-to-self attacks. This is a typical attack ahacker can conduct once accessing your Web application (for example, exploitinga buffer overrun) simply by reverting the security token of the impersonatedclient to the token of the parent process. In ASP.NET, the most a hacker canobtain is the ASPNET account - the "weak" account of the worker process. Bearthis in mind if you decide to change the default account for the ASP.NET workerprocess.

Change the Process Account

The base identity for the ASP.NET ISAPI extension is setto the account of IIS (SYSTEM) and is not configurable. The base identity forthe ASP.NET worker process by default is ASPNET, but you can change it to anyother system- or user-defined account (including SYSTEM). Information about theprocess account is set in the section of machine.config.Here are the default contents:

Setting the userName attribute to Machine indicates thedefault account - ASPNET or NetworkService if the IIS 6 process model isenabled. Setting the password attribute to AutoGenerate indicates that thepassword is generated cryptographically during setup. The password is stored inthe Local Security Authority (LSA) of the operating system. You can configurethe worker process to run under the SYSTEM account, although this approach ishighly discouraged. Here's how you can give administrative privileges to your Webapplication:

You also can set an arbitrary Windows account byindicating the username and password:

Do not take lightly the decision to change to the defaultaccount - you must review a few aspects carefully. In particular, the newASP.NET account shouldn't be less powerful than ASPNET; otherwise you seriouslyrisk tearing down some ASP.NET functionality. At a minimum, you should guaranteethat the new account is granted full access to the Temporary ASP.NET Filesfolder. You can set the section only within themachine.config file, and this affects all applications running on the machine.To mitigate this problem, you can apply settings to a specific resource byusing a tag with an appropriate path attribute. You can usethe path attribute to identify a specific file or folder to which uniqueconfiguration settings apply.

In addition, you should note that settings in the section are read by aspnet_isapi.dll, not by managed code.For this reason, changes to are not applied until IIS isrestarted. Also, be aware that when you use the IIS 6 process model, thesettings in the section are ignored. To configure theprocess identity (or other process model values), use the Configuration Managerand apply changes in the IIS metabase directly.

When you change the process account, you need to indicatethe password in a clear text file, which never is a safe practice. In ASP.NET1.1, you can encrypt and store usernames and passwords in the registry and linkthem to the .config files. This feature has been extended to ASP.NET 1.0 withService Pack 3. In the .config file, you can indicate usernames and passwordslike this:

userName="registry:HKLMpathkey, user"

password="registry:HKLMpathkey, pswd"

You indicate the path of the registry where theinformation is stored. A new utility, aspnet_setreg.exe, is provided with SP3and ASP.NET 1.1 to encrypt and store credentials in the registry. Note that youcan use this encrypting feature only for the ,, and sections.

Enable Impersonation

Unlike classic ASP, ASP.NET works with impersonationdisabled by default. This setting is configurable, however, and you can enableimpersonation by editing this line in the web.config file:

Because the web.config file can be defined in each childfolder, you could configure the application so it assumes different identitiesin different folders. This feature also depends on the fact that you can setthe section at all levels of the configuration hierarchy - notonly at the machine or application root level.

When impersonation is enabled, the thread processing therequest can have a different identity from the ASP.NET process. In particular,the thread's security token is any token IIS uses to accept the request. Theidentity is that of the currently logged-on Windows user. Note that editing the section really is the only way to change the identity ofthe worker process. This is different from impersonating the current, or afixed, user. If you change the identity of the process, all threads will usethe new identity and no extra work is needed on thread switches.

An alternative to default impersonation is to impersonatea specific user by providing its username and password:

userName="..."password="..." />   This case deserves a bit of attention. To impersonate auser in Windows 2000, a process needs to call the LogonUser Win32 API. But thisfunction requires an administrator-level privilege - the SE_TCB_NAME privilege- set on the calling process. In reality, the privilege does not need to beenabled, but it must be granted; the LogonUser function enables it ifnecessary. If the calling process does not have this privilege, the LogonUserfunction simply fails. What does this mean to you? If you want to supportimpersonation by name, you must grant the ASP.NET worker process a criticalprivilege. The default ASPNET account doesn't have such a privilege; as aresult, you can't impersonate accounts in Windows 2000 unless you replace theASPNET account with a stronger one that boasts the SE_TCB_NAME privilege. Forthis reason, impersonating by name in ASP.NET 1.0 might be dangerous. InWindows XP and Windows Server 2003, the SE_TCB_NAME privilege is no longerneeded to log on as a particular user.   In ASP.NET 1.1, the situation is a bit differentregardless of the underlying operating system. Even if the privilege is notgranted to the worker process, impersonation by name still is supported byvirtue of a smart trick. In ASP.NET 1.1 on Windows 2000, in fact, theaspnet_isapi, which runs under SYSTEM, creates the token and copies it back tothe memory of the worker process. As a result, the weak ASPNET accountimpersonates any fixed identity.   ASP.NET counts three different security layers. One isrepresented by the worker process, which by default runs under a weak accountsuch as ASPNET. The second layer is the security context of the thread withinthe worker process that actually serves the request; this token is affecteddirectly by impersonation settings. Finally, the last layer of the ASP.NETsecurity is the application-specific infrastructure for authentication andauthorization. Interspersed between these three layers are many system featuresthat have been improved significantly in ASP.NET 1.1 to make the runtime moresecure.   Dino Esposito is a trainer and consultant whospecializes in ASP.NET, ADO.NET, and XML. Author of Building Web Solutions with ASP.NET andADO.NET and ProgrammingMicrosoft ASP.NET, both from Microsoft Press, Dino also is a co-founderof http://www.VB2TheMax.com.E-mail him at mailto:[email protected].   Tell us what you think! Please send any comments aboutthis article to [email protected] include the article title and author.