Introduction

It can be very tricky to analyze the relevant service account and its file system permissions in order to evaluate if a compromised ASP.NET application can access sensitive resources (file system / network / processes) on the web server. Especially from IIS 6 to IIS 7.5 there is quite a big change in how the service accounts are isolated on IIS.

Contents

Many different factors influence under which identity an IIS Worker Process runs. All the following settings need to be evaluated in order to be able make a clear statement which service account(s) are relevant.

Check IIS Application Pool Identity

  1. LocalService or LocalSystem
    (Should obviously not be choosen at all, since they are high privileged built-in system accounts)
  2. NetworkService
    (Built-In service account with least privileges designed for low trusted network services like a web application. It was best practice to use this account prior to IIS6 or 7. Problem is that the web application shares the process memory and file access permissions with all the other services using the NETWORK SERVICE account. This causes insufficient application isolation.)
  3. ApplicationPoolIdentity
    (New and better application isolation with IIS 7.5: A “virtual” account is generated automatically with the name of the application pool, e.g. “    IIS AppPool \ DefaultAppPool ” or IIS ” AppPool \ XSSViewStateUser ” and cannot be seen in the Users and Group Configuration Dialog. You need to specify exact user name in the FilePermission Dialog to give this account permission on a certain folder. Using this option, no custom service accounts need to be configured anymore for the application pools since IIS handles them automatically. This provides a maximum isolation of applications.)

Check IIS Anonymous Authentication Identity

  1. IUSR
    ( Built-In account with least privileges designed to provide file system access for anonymous users of web applications. )
  2. ApplicationPoolIdentity
    (The “virtual” account configured as the Application Pool Identity. –> Check IIS Application Pool Identity )

Check ASP.NET Authentication Scheme

  1. <authentication mode=”Windows” /><identity impersonate=”false” />
    (With Windows authentication but without impersonation, ASP.NET will run as the Application Pool Identity and needs read and write access, depending on the application. –> Check IIS Application Pool Identity
    but as well needs the     IIS-authenticated caller read access –> Check IIS Anonymous Authentication Identity)
  2. <authentication mode=”Windows” /><identity impersonate=”true” />
    (With Windows authentication and impersonation, ASP.NET runs as the IIS-authenticated caller and needs read and write access, depending on the application. –> Check IIS Anonymous Authentication Identity
    but as well needs the Application Pool Identity read access –> Check IIS Application Pool Identity )
    (Attention, In IIS 7 you need to consider the fact that impersonation can only be used with the “Classic Managed Pipeline Mode” and not the “Integrated Managed Pipeline Mode” mode. Second is the default)
  3. <authentication mode=”None” /> or <authentication mode=”Forms” />
    (Without Windows authentication, ASP.NET runs as the as the Application Pool Identity . –> Check IIS Application Pool Identity )

Verify Identity of the IIS Worker Process in the TaskManager

You could as well check the worker process identity in the task manager. The relevant process to check is w3wp.exe “IIS Worker Process”. This means that the User under which this process currently runs is the one which needs all the access the ASP.NET application needs. But in order to run the application it might be necessary, dependent on the settings above, that another account needs read access to the web folder as well.

Check Identity of the IIS Root Process in the Services

The relevant service to check for the IIS root process is W3SVC “World Wide Web Publishing Service“. This means that the port binding and writing the logs (W3C) is with the LOCAL SYSTEM account.

Examples

The following are the most common scenarios in the Internet area whereas no impersonation is used and Forms or None ASP.NET authentication is used.

First Scenario with Forms authentication

  • IIS Application Pool Identity = NetworkService
  • IIS Authentication Identity = IUSR
  • ASP.NET Authentication Scheme = Forms or None

==> Result: The account NetworkService needs all the access the application needs. Whereas the IUSR does not need access at all.

Second Scenario with Forms authentication

  • IIS Application Pool Identity = ApplicationPoolIdentity
  • IIS Authentication Identity = IUSR or ApplicationPoolIdentity
  • ASP.NET Authentication Scheme = Forms or None

==> Result: The account IIS AppPool \<Name of Application Pool> needs all the access the application needs. Whereas the IUSR or NetworkServicedo not need access at all.

First Scenario with Windows authentication

  • IIS Application Pool Identity = NetworkService
  • IIS Authentication Identity = IUSR
  • ASP.NET Authentication Scheme = Windows with Impersonation

==> Result: The account IUSR needs all the access the application needs. Whereas the NetworkService does only need read access on the web application folder.

Second Scenario with Windows authentication

  • IIS Application Pool Identity = NetworkService
  • IIS Authentication Identity = IUSR
  • ASP.NET Authentication Scheme = Windows without Impersonation

==> Result: The account NetworkService needs all the access the application needs. Whereas the IUSR does only need read access on the web application folder.

third Scenario with Windows authentication

  • IIS Application Pool Identity = ApplicationPoolIdentity
  • IIS Authentication Identity = IUSR
  • ASP.NET Authentication Scheme = Windows without Impersonation

==> Result: The account IIS AppPool \<Name of Application Pool> needs all the access the application needs. Whereas the IUSR does only need read access on the web application folder.

fourth Scenario with Windows authentication

  • IIS Application Pool Identity = ApplicationPoolIdentity
  • IIS Authentication Identity = ApplicationPoolIdentity
  • ASP.NET Authentication Scheme = Windows without Impersonation

==> Result: The account IIS AppPool \<Name of Application Pool> needs all the access the application needs. Whereas the IUSR does not need access at all.

Conclusion

When it comes to file system audits, you need to be aware of all the above options. However, when you deploy your own web application, it is recommended to rely on the ApplicationPoolIdentity whenever possible. This new feature has several security advantages:

  • Dedicated memory space
  • ACLs can be set very specifically
  • No other dependencies
  • …

References