Quantcast
Channel: Security
Viewing all articles
Browse latest Browse all 1881

Locking down IIS APPPOOL inherited permissions locks out local administrators except for the BUILTIN\Administrator account

$
0
0

In a nutshell,

we have been locking down the IIS APPPOOL account used by an Internet facing web application. The  IISAPPPOOL account by default belongs to a number of mandatory groups when the security token is injected into the w3wp.exe process:

  Token contents:
    User:
      IIS APPPOOL\XXX XXXX XXXX
    Groups:
      Mandatory Label\High Mandatory Level             INTEGRITY
      Everyone                                         MANDATORY
      BUILTIN\Users                                    MANDATORY
      NT AUTHORITY\SERVICE                             MANDATORY
      CONSOLE LOGON                                    MANDATORY
      NT AUTHORITY\Authenticated Users                 MANDATORY
      NT AUTHORITY\This Organization                   MANDATORY
      IIS APPPOOL\XXX XXXX XXXX LOGONID,MANDATORY

      BUILTIN\IIS_IUSRS                                MANDATORY
      LOCAL                                            MANDATORY
      S-1-5-82-0                                       MANDATORY
    Privileges:
      SeAssignPrimaryTokenPrivilege                    DISABLED
      SeIncreaseQuotaPrivilege                         DISABLED
      SeAuditPrivilege                                 DISABLED
      SeChangeNotifyPrivilege                          ENABLED
      SeImpersonatePrivilege                           ENABLED
      SeCreateGlobalPrivilege                          ENABLED
      SeIncreaseWorkingSetPrivilege                    DISABLED

What this means is that anyone who can execute code on the web server (i.e a hacker) has potentially access to the operating system files and processes via their membership in the Users and Everyone groups courtesy of the IIS APPPOOL security token.

So to prevent this we have removed the permissions on the root folders and all child files and folders of the Everyone and Users groups for everything but the web root (When you do this the OS security UI complains if you try to do this when it reaches the Windows and windows\system directories). The Administrators group is left untouched.This has now locked down our web server and the IIS APPPOOL inherited permissions to our satisfaction and all applications behave as required.

However a side effect of this security lockdown is that any local administrative accounts on the local machine (there is no Domain security)except the BUILTIN\Administrator default account now have no read write or execute permissions ("Access denied") which is not what we would expect. This is despite the administrators belonging properly to the Administrators group and the Administrator group being correctly set on files (After all The default Administrator account works as expected.).

Any suggestions on how to give back Administrative privileges to non default administrative accounts without having to reinstate the Authenticated User and Everyone group permissions or to explicitly set any non Default administrator accounts (we actually ony need one additional non default admin account)

The environment is Windows Server 2008 R2 IIS 7.5

Additional comment:

This is not specifically an IIS problem.  This is a side efect of our APP POOL lockdown. This could be replicated on any default Windows installation. Remove the default Everyone and Users Groups from the root of a drive. Add or leave Administrators group with full control to the root of a drive if not already. Logon as a non default administrator (i.e not the BUILTIN\Administrator account). The so called "administrative user" can not enumerate files, launch programs on that drive (Using RunAs Administrator leads to "The Parameter is incorrect" dialog. In other respects the administrator has some administrative abilities, i.e. can interrogate Permissions/Security UI, Can logon remotely without explicit membership in Remote Users etc. Running Process monitor readily demonstrates "ACCESS DENIED".  The "problem" can be solved by explicitly adding permissions for each administrative account. But that should not normally be necesary. Group membership should be sufficient. 

We would appreciate anyone else reproducing this or for someone to note some configuration we may have missedor general discussion about dealing with the Everyone/Users groups, especially outside the webroot itself.


Viewing all articles
Browse latest Browse all 1881

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>