ACCESS CONTROL OVERVIEW
The security subsystem is the primary gatekeeper through which subjects access objects
within the Windows operating system. We use the terms subjects generically here to
describe any entity that performs some action, and objects to mean the recipient of that
action. In Windows, subjects are processes (associated with access tokens), and objects are
securable objects (associated with security descriptors).
Processes are the worker bees of computing. They perform all useful work (together
with subprocess constructs called threads). Securable objects are the things that get acted
upon. Within Windows are many types of securable objects: files, directories, named
pipes, services, Registry keys, printers, networks shares, and so on.
When a user logs on to Windows (that is, authenticates), the operating system creates
an access token containing security identifiers (SIDs) correlated with the user’s account
and any group accounts to which the user belongs. The token also contains a list of the
privileges held by the user or the user’s groups. We’ll talk in more detail about SIDs and
privileges later in this chapter. The access token is associated with every process created
by the user on the system.
When a securable object is created, a security descriptor is assigned that contains a
discretionary access control list (DACL, sometimes generalized as ACL) that identifies which
user and group SIDs may access the object, and how (read, write, execute, and so on).
To perform access control, the Windows security subsystem simply compares the
SIDs in the subject’s token to the SIDs in the object’s ACL. If a match is found, access is
permitted; otherwise, it is denied.
The remainder of this chapter will take a more detailed look at subjects, since they are
the only way to access objects (absent kernel-mode control, again). For further information
on securable objects, see “References and Further Reading.”
SECURITY PRINCIPALS
As we noted earlier, the fundamental subject within Windows is the process. We also
noted that processes must be associated with a user account in order to access securable
objects. This section will explore the various account types in Windows, since they are
the foundation for most attacks against access control.
Windows offers three types of fundamental accounts, called security principals:
• Users
• Groups
• Computers
We’ll discuss each of these in more detail shortly, just after we take a brief detour to
discuss SIDs.
SIDs
In Windows, security principals generally have friendly names, such as Administrator or
Domain Admins. However, the NT family manipulates these objects internally using a
globally unique 48-bit number called a security identifier, or SID. This prevents the system
from confusing the local Administrator account from Computer A with the identically
named local Administrator account from Computer B, for example.
The SID comprises several parts. Let’s take a look at a sample SID:
S-1-5-21-1527495281-1310999511-3141325392-500
A SID is prefixed with an S, and its various components are separated with hyphens.
The first value (in this example, 1) is the revision number, and the second is the identifier
authority value. Then four subauthority values (21 and the three long strings of numbers,
in this example) and a relative identifier (RID—in this example, 500) make up the remainder
of the SID.
SIDs may appear complicated, but the important concept for you to understand is that
one part of the SID is unique to the installation or domain and another part is shared across
all installations and domains (the RID). When Windows is installed, the local computer
generates a random SID. Similarly, when a Windows domain is created, it is assigned a
unique SID (we’ll define domains later in this chapter). Thus, for any Windows computer or
domain, the subauthority values will always be unique (unless purposely tampered with
or duplicated, as in the case of some low-level disk-duplication techniques).
However, the RID is a consistent value across all computers or domains. For example,
a SID with RID 500 is always the true Administrator account on a local machine. RID 501
is the Guest account. On a domain, RIDs starting with 1001 indicate user accounts. (For
example, RID 1015 would be the fifteenth user account created in the domain.) Suffice to
say that renaming an account’s friendly name does nothing to its SID, so the account can
always be identified, no matter what. Renaming the true Administrator account changes
only the friendly name—the account is always identified by Windows (or a malicious
hacker with appropriate tools) as the account with RID 500.
Why You Can’t Log on as Administrator Everywhere
As is obvious by now (we hope), the Administrator account on one computer is different
from the Administrator account on another because they have different SIDs, and
Windows can tell them apart, even if humans can’t. This feature can cause headaches for
the uninformed hacker.
Occasionally in this book, we will encounter situations where logging on as
Administrator fails. Here’s an example:
C:\>net use \\192.168.234.44\ipc$ password /u:Administrator
System error 1326 has occurred.
Logon failure: unknown user name or bad password.
A hacker might be tempted to turn away at this point, without recalling that Windows
automatically passes the currently logged-on user’s credentials during network logon
attempts. Thus, if the user were currently logged on as Administrator on the client, this
logon attempt would be interpreted as an attempt to log on to the remote system using
the local Administrator account from the client. Of course, this account has no context on
the remote server. You can manually specify the logon context using the same net use
command with the remote domain, computer name, or IP address prepended to the
username with a backslash, like so:
C:\>net use \\192.168.234.44\ipc$ password /u:domain\Administrator
The command completed successfully.
Obviously, you should prepend the remote computer name or IP address if the
system to which you are connecting is not a member of a domain. Remembering this
little trick will come in handy when we discuss remote shells in Chapter 7; the technique
we use to spawn such remote shells often results in a shell running in the context of the
SYSTEM account. Executing net use commands within the LocalSystem context cannot
be interpreted by remote servers, so you almost always have to specify the domain or
computer name, as shown in the previous example.
Viewing SIDs with user2sid/sid2user
You can use the user2sid tool from Evgenii Rudnyi to extract SIDs. Here is user2sid being
run against the local machine:
C:\>user2sid \\caesars Administrator
S-1-5-21-1507001333-1204550764-1011284298-500
Number of subauthorities is 5
Domain is CORP
Length of SID in memory is 28 bytes
Type of SID is SidTypeUser
The sid2user tool performs the reverse operation, extracting a username given a SID.
Here’s an example using the SID extracted in the previous example:
C:\>sid2user \\caesars 5 21 1507001333 1204550764 1011284298-500
Name is Administrator
Domain is CORP
Type of SID is SidTypeUser
Note that the SID must be entered starting at the identifier authority number (which is
always 5 in the case of Windows Server 2003), and spaces are used to separate components,
rather than hyphens.
Users
Anyone with even a passing familiarity with Windows has encountered the concept of
user accounts. We use accounts to log on to the system and to access resources on the
system and the network. Few have considered what an account really represents,
however, which is one of the most common security failings on most networks.
Quite simply, an account is a reference context in which the operating system executes
code. Put another way, all user mode code executes in the context of a user account. Even some
code that runs automatically before anyone logs on (such as services) runs in the context
of an account (often as the special and all-powerful SYSTEM, or LocalSystem, account).
All commands invoked by the user who successfully authenticates using the account
credentials are run with the privileges of that user. Thus, the actions performed by
executing code are limited only by the privileges granted to the account that executes it.
The goal of the malicious hacker is to run code with the highest possible privileges. Thus,
the hacker must “become” the account with the highest possible privileges.
Built-ins
Windows comes out of the box with built-in accounts that have predefined privileges.
These default accounts include the local Administrator account, which is the most
powerful user account in Windows. (Actually, the SYSTEM account is technically the
most privileged, but Administrator can execute commands as SYSTEM quite readily
using the Scheduler Service to launch a command shell, for example.) Table 2-1 lists the
default built-in accounts on various versions of Windows.
Note a few caveats about Table 2-1:
• On domain controllers, some security principals are not visible in the default
Active Directory Users and Computers interface unless you choose View |
Advanced Features.
• Versions of Windows including XP and later “hide” the local Administrator
account by default, but it’s still there.
• Some of the accounts listed in Table 2-1 are not created unless specific server
roles have been configured; for example, Application Server (IIS).
• The group Guests, the user accounts Guest, and Support_388945a0 are assigned
unique SIDs corresponding to the domains in which they reside.
Service Accounts
Service account is an unofficial term used to describe a Windows user account that
launches and runs a service non-interactively (a more traditional computing term is batch
accounts). Service accounts are typically not used by human beings for interactive logon,
but are used to start up and run automated routines that provide certain functionality to
the operating system on a continuous basis. For example, the Indexing service, which
indexes contents and properties of files on local and remote computers, and is located in
%systemroot%\System32\cisvc.exe, can be configured to start up at boot time using the
Services control panel. For this executable to run, it must authenticate to the operating
system. For example, the Indexing service authenticates and runs as the LocalSystem
account on Windows Server 2003 in its out-of-the-box configuration.
Service accounts are a necessary evil in Windows. Because all code must execute in
the context of an account, they can’t be avoided. Unfortunately, because they are
designed to authenticate in an automated fashion, the passwords for these accounts
must be provided to the system without human interaction. In fact, Microsoft designed
the Windows NT family to cache passwords for service accounts on the local system.
This was done for the simple convenience that many services need to start up before the
network is available (at boot time), and thus could not be authenticated to domain
controllers. By caching the passwords locally, this situation is avoided. Here’s the
kicker:
Non-SYSTEM service account passwords are stored in cleartext in a portion of the Registry
called the LSA Secrets, which is accessible only to LocalSystem.
We highlighted this sentence because it leads to one of the major security failings of the
Windows OS: If a malicious hacker can compromise a Windows NT family system with
Administrator-equivalent privileges, he or she can extract the cleartext passwords for
service accounts on that machine.
“Yippee,” you might be saying, if you’re already Administrator-equivalent on the
machine; “What additional use are the service accounts?” Here’s where things get
sticky: Service accounts can be domain accounts or even accounts from other trusted
domains. (See the section “Trusts” later in this chapter.) Thus, credentials from other
security domains can be exposed via this flaw.
Service Hardening Services represent a large percentage of the overall attack surface in
Windows because they are generally always on and run at high privilege. Largely because
of this, Microsoft began taking steps to reduce the risk from running services in more
recent versions of the OS.
One of the first steps was to run services with least privilege, a long-accepted access
control principle. Beginning in Windows Server 2003, Microsoft created two new built-in
groups called Local Service and Network Service, and started running more services
using those lower privileged accounts rather than the all-powerful LocalSystem account.
(We’ll talk more about Local and Network Service throughout this chapter.)
In Vista, Microsoft implemented Windows Service Hardening, which defined per-
service SIDs. This effectively made certain services behave like unique users (again, as
opposed to the generic and highly privileged LocalSystem identity). Default Windows
access control settings could now be applied to resources in order to make them private
to the service, preventing other services and users from accessing the resource.
Additional features included within Service Hardening in Vista include removal of
unnecessary Windows privileges (such as the powerful debugging privilege), applying
a write-restricted access token to the service process to prevent writing to resources
that do not explicitly grant access to the Service SID, and linking Windows firewall
policy to the per-service SID to prevent unauthorized network access by the service.
For more information about Service Hardening, see “References and Further
Reading.”
The Bottom Line
Here’s a summary of Windows accounts from the malicious hacker’s perspective:
Administrators and the SYSTEM account are the juiciest targets on a Windows system
because they are the most powerful accounts. All other accounts have limited privileges
relative to Administrators and SYSTEM (one possible exception being service accounts).
Compromise of Administrators or the SYSTEM account is thus almost always the
ultimate goal of an attacker.
Groups
Groups are primarily an administrative convenience—they are logical containers for
aggregating user accounts. (They can also be used to set up e-mail distribution lists in
Windows 2000 and later, which historically have had no security implications.)
Groups are also used to allocate privileges in bulk, which can have a heavy impact on
the security of a system. Windows in its various flavors comes with built-in groups,
predefined containers for users that also possess varying levels of privilege. Any account
placed within a group inherits those privileges. The simplest example of this is the
addition of accounts to the local Administrators group, which essentially promotes the
added user to all-powerful status on the local machine. (You’ll see this attempted many
times throughout this book.) Table 2-2 lists built-in groups in Windows Server 2003.
Other versions of Windows may have fewer or different built-in groups, but those listed
in Table 2-2 are the most common.
To summarize Windows groups from the malicious hacker’s perspective:
Members of the local Administrators group are the juiciest targets on a Windows system
because members of this group inherit complete control of the local system. Domain
Admins and Enterprise Admins are the juiciest targets on a Windows domain because
members of those groups are all-powerful on every (properly configured) machine in
the domain. All other groups possess very limited privileges relative to Administrators,
Domain Admins, or Enterprise Admins. Becoming a local Administrator, Domain Admin,
or Enterprise Admin (whether via directly compromising an existing account or by
adding an already-compromised account to one of those groups) is thus almost always
the ultimate goal of an attacker.
Special Identities
In addition to built-in groups, Windows has several special identities (sometimes called
well-known groups), which are containers for accounts that transitively pass through
certain states (such as being logged on via the network) or from certain places (such as
interactively at the keyboard). These identities can be used to fine tune access control to
resources. For example, access to certain processes may be reserved for INTERACTIVE
users only (and thus blocked for all users authenticated via the network). These well-
known groups belong to the NT AUTHORITY “domain,” so to refer to their fully
qualified name, you would say NT AUTHORITY\Everyone, for example. Table 2-4 lists
the Windows special identities.
Some key points worth noting about these special identities:
The Anonymous Logon group can be leveraged to gain a foothold on a Windows
system without authenticating. Also, the INTERACTIVE identity is required in many
instances to execute privilege escalation attacks against Windows (see Chapter 7).
Restricted Groups
A pretty nifty concept that was introduced with Windows 2000, Restricted Groups allows
an administrator to set a domain policy that restricts the membership of a given group.
For example, if an unauthorized user adds himself to the local Administrators group on
a domain member, upon the next Group Policy refresh, that account will be removed so
that membership reflects that which is defined by the Restricted Groups policy. These
settings are refreshed every 90 minutes on a member computer, every 5 minutes on a
domain controller, and every 16 hours whether or not changes have occurred.
Computers (Machine Accounts)
When a Windows system joins a domain, a computer account is created. Computer
accounts are essentially user accounts that are used by machines to log on and access
resources (thus, computers are also called machine accounts). This account name appends
a dollar sign ($) to the name of the machine (machinename$).
As you might imagine, to log on to a domain, computer accounts require passwords.
Computer passwords are automatically generated and managed by domain controllers.
(See the upcoming section “Forests, Trees, and Domains.”) Computer passwords are
otherwise stored and accessed just like any other user account password. (See the
upcoming section “The SAM and Active Directory.”) By default, they are reset every 30
days, but administrators can configure a different interval if they want.
The primary use for computer accounts is to create a secure channel between the
computer and the domain controller for purposes of exchanging information. By default,
this secure channel is not encrypted (although some of the information that passes through
it is already encrypted, such as password hashes), and its integrity is not checked (thus
making it vulnerable to spoofing or man-in-the-middle attacks). For example, when a
user logs on to a domain from a domain member computer, the logon exchange occurs
over the secure channel negotiated between the member and the domain controller.
We’ve never heard of a case where exploitation of a machine account has resulted in
a serious exposure, so we will not discuss this much in this book.
User Rights
Recall the main goal of the attacker from the beginning of this chapter:
To execute commands in the most privileged context, in order to gain access to resources
and data.
We’ve just described some of the “most privileged” user mode account contexts, such
as Administrator and LocalSystem. What makes these accounts so powerful? In a word
(two words, actually), user rights. User rights are a finite set of basic capabilities, such as
logging on locally or debugging programs. They are used in the access control model in
addition to the standard comparing of access token SIDs to security descriptors. User
rights are typically assigned to groups, since this makes them easier to manage than
constantly assigning them to individual users. This is why membership in groups is so
important—because the group is typically the unit of privilege assignment.
Two types of user rights can be granted: logon rights and privileges. This is simply a
semantic classification to differentiate rights that apply before an account is authenticated
and after, respectively. More than 40 discrete user rights are available in Windows Server
2008 (code name Longhorn), and although each can heavily impact security, we discuss
only those that have traditionally had a large security impact. Table 2-5 outlines some of
the privileges we consider critical, along with our recommended configurations.
Note that the “deny” rights supersede their corresponding “allow” rights if an
account is subject to both policies.
Some user rights relevant to security were implemented in Windows Server 2003,
including the following:
• Allow logon through Terminal Services
• Deny logon through Terminal Services
• Impersonate a client after authentication
• Perform volume maintenance tasks
The Terminal Services–related rights were implemented to address a gap in the
“Allow/ deny access to this computer from the network” rights, which do not apply to
Terminal Services. The “Impersonate a client after authentication” right was added to
help mitigate privilege escalation attacks in which lower privileged services impersonated
higher privileged clients.
Last but not least in our discussion of user rights is a reminder always to use the
principle of least privilege. We see too many people logging on as Administrator-
equivalent accounts to perform daily work. By taking the time up front to consider the
appropriate user rights, most of the significant security vulnerabilities discussed in this
book can be alleviated. Log on as a lesser privileged user, and use the runas tool ) to escalate privileges when necessary.
