Access control in Windows

According to [Access Control, 2013], Access control refers to security features that control who [sic] can access resources in the operating system. Applications call access control functions to set who can access specific resources or control access to resources provided by the application.”

The Windows access control model is founded on two base components: access tokens and security descriptors. The relations and interactions between them are illustrated in the schema below, based on [Parts of the Access Control Model, 2013], [Access Tokens, 2013] and [Securable Objects, 2013].

Access Token visualisation

The following items of the schema were therefore further studied:

  • Security identifiers (SIDs) are unique and used to identify a trustee. SIDs are assigned by Active Directory for users within a Windows domain. Various well-known SIDs exist and while SIDs should not be used directly, they are consultable for everybody and their randomness or secrecy is not a security prerequisite [Security Identifiers, 2013]. SIDs are also used to identify logon sessions and are kept unique while a computer is running. The list of previously issued logon SIDs is reset on the reboot of the computer [Security Glossary – L, 2013].
  • Restricted tokens are copies of primary or impersonation access tokens with fewer enabled permissions. Compared to its original access token, a restricted token may contain fewer privileges, have the deny-only attribute set or specify a list of restricting SIDs [Restricted Tokens, 2013].
  • Primary versus impersonation tokens: a primary token is created by the operating system either on a user logon or when the user starts a process. An impersonation token is created when a server-side process captures the identity of a client and impersonates this client identity during the execution of the task. A server-side process using impersonation will have two tokens: first its primary token and a second impersonation token featuring details of the client. Moreover, an impersonation token has one of four different levels of impersonation: anonymous, identify, impersonate and delegate [Lebrun, 2013].

None of the above objects implement cryptography. No crypto-based verification is implemented in the checking process documented either [How AccessCheck Works, 2013].


Offline references

[Lebrun, 2013]: Lebrun, M. (2013, July-August). Faiblesse des mécanismes d’autentification: quelles solutions? MISC – Multi-System & Internet Securitry Cookbook(68), page 12-21.

Exploit credentials stored in Windows Group Policy Preferences

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"
      <Properties action="C" fullName="Local admin created by GPO"
       changeLogon="0" noChange="0" neverExpires="0"
       acctDisabled="0" userName="ladmin_gpo"/>
    <Group clsid="{6D4A79E4-529C-4481-ABD0-F5BD7EA93BA7}"
     name="Administrators (built-in)" image="2"
     changed="2012-02-06 10:45:50"
      <Properties action="U" newName="" description=""
       deleteAllUsers="0" userAction="ADD" deleteAllGroups="0"
       removeAccounts="0" groupSid="S-1-5-32-544"
       groupName="Administrators (built-in)">
          <Member name="ladmin_gpo" action="ADD" sid=""/>

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