Windows | Compass Security Blog

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

LocalService or LocalSystem
(Should obviously not be choosen at all, since they are high privileged built-in system accounts)

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.)

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

IUSR
( Built-In account with least privileges designed to provide file system access for anonymous users of web applications. )

ApplicationPoolIdentity
(The “virtual” account configured as the Application Pool Identity. –> Check IIS Application Pool Identity )

Check ASP.NET Authentication Scheme

<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)

<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)

<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 )

Group Policy preferences are a new feature set available since Windows Server 2008, which shouldn’t be confused with the well known Group Policy objects (GPOs) dating back to Windows NT. The main idea behind the creation of Group Policy preferences is the ability to push so-called “unmanaged” settings. Compared to “managed” GPOs, group policy preferences can be altered by the end user and aren’t enforced on a regular basis.

Before the release of the Group Policy feature, administrators could already set user preferences via scripts or .reg files. This lead to complex login scripts potentially containing sensitive information. Using Group Policy features, you can now manage this kind of settings centrally and in a convenient way.

While this addition was released with Windows 2008 Server, you can install the client-side extensions on client computers running on Vista, Windows XP SP2 or Windows 2003 SP1 for backward compatibility with all your workstations.

Let’s see an example on how we can define a local user on some workstations. It starts with the creation and edition of a group policy object:

In the Group Policy Management Editor, we still see our well-known Policies folder, but also a new hierarchy for these unmanaged preferences. Creating a local administrator on the machines targeted by the GPO “GPO_local_accounts” is only a matter of clicks:

Where is this setting stored and how secure is it? Group Policy Preferences are stored, as all other GPOs, within the SYSVOL folder on the domain controllers (%LOGONSERVER%\SYSVOL) but within xml files.

The above created policy gets translated into the following groups.xml file:

<?xml version="1.0" encoding="utf-8"?>
  <Groups clsid="{3125E937-EB16-4b4c-9934-544FC6D24D26}">
    <User clsid="{DF5F1855-51E5-4d24-8B1A-D9BDE98BA1D1}"
     name="ladmin_gpo" image="0" changed="2012-02-03 07:10:48"
     uid="{FE47E73C-7525-46CD-B2E0-F68D3022EDCE}">
      <Properties action="C" fullName="Local admin created by GPO"
       description=""
       cpassword="9QHhFTUdm6rDgu30J7ShZfqt07T6vOUGkyAFG3G7M+5AotJjkOva7E9KSAcamdrruTgly0O/uVTB/UUdLNU4775b5381hyuUzkd4lJW+llcNNNrQlYu7zqH3/i+8jfjhUq9lqPn8VjCtb9iaEqWbKQ"
       changeLogon="0" noChange="0" neverExpires="0"
       acctDisabled="0" userName="ladmin_gpo"/>
    </User>
    <Group clsid="{6D4A79E4-529C-4481-ABD0-F5BD7EA93BA7}"
     name="Administrators (built-in)" image="2"
     changed="2012-02-06 10:45:50"
     uid="{4D0CE71D-D2E4-42B1-9BF3-147C910A15F1}">
      <Properties action="U" newName="" description=""
       deleteAllUsers="0" userAction="ADD" deleteAllGroups="0"
       removeAccounts="0" groupSid="S-1-5-32-544"
       groupName="Administrators (built-in)">
        <Members>
          <Member name="ladmin_gpo" action="ADD" sid=""/>
        </Members>
      </Properties>
    </Group>
  </Groups>

So how secure is my password, stored within the cpassword attribute? According to the documentation, it’s using AES-256 – so pretty secure, isn’t it?

Well, not exactly, as the key is public and documented in the MSDN. All you need to do is open CrypTool, add some padding to the value to be base64 compliant, and perform a base64 decoding:

Choose then the AES decryption option (Analysis – Symmetric Encryption (modern) – Rijndael (AES) and paste the public key:

That’s it, the password is decrypted without any brute-force attack:

As conclusion, while Group Policy preferences are a great tool to distribute unmanaged settings, it should not be used to push down features containing credentials such as:

User preferences
Database connections strings
Scheduled tasks
Mapped drives settings
Service preferences

References

Compass Security Blog

A Blog about Information Security…

Tag Archives: Windows

Impact of IIS 7.5 Service Accounts for file system audits

Introduction

Contents

Check IIS Application Pool Identity

Check IIS Anonymous Authentication Identity

Check ASP.NET Authentication Scheme