Fourteen privileges that can be abused in Windows 2000, Part 1

In order to properly administer and secure your Windows 2000 system you should be knowledgeable on the privileges that can be granted to user and group accounts. In the first of a two-part series, Roberta Bragg focuses the attention of those responsible for system security (auditors, systems administrators, security administrators, security analysts, etc) to these critical system privileges that they may keep their systems secure.

This tip has been extracted from presentation materials prepared by Roberta Bragg for the MCP Magazine TechMentor conferences. All rights reserved by the author.

From the author of

From the author of

Windows 2000 uses the concept of assignment of privileges to users and
groups.

Processes running on the system may be designed to run as services, that is,
like Unix daemons, they run in the background. Services can use the LocalSystem
account, or be assigned a Administratively controlled user account for logon
purpose and rights assignment. In order to properly administer and secure your
Windows 2000 system you should be knowledgeable on the privileges that can be
granted to user and group accounts.

While every privilege can be abused, you should be especially cognizant of
those powerful privileges, which if abused, can be most devastating. Knowledge
is power. Anyone can easily find this information—it is widely published.
Default assignment of these privileges is set appropriately for administrators
and the LocalSystem Account *; but default privileges can be changed.

My purpose here is to focus the attention of those responsible for system
security (auditors, systems administrators, security administrators, security
analysts, etc) to these critical system privileges that they may keep their
systems secure. A brief list of these privileges and their possible abuse is
detailed below:

User Right/Privilege

Default Assignment

Use

Abuse

1. Act as part of the operating system

The LocalSystem account (an account used by the operating system to run
services.) The LocalSystem account does not show up in the user database
GUIs and is not under administrative control. An administrator can, however,
require services running on W2K to use the LocalSystem account for logon

The ability to perform kernel level processing.

An extremely dangerous privilege. It should not be assigned to any group
or account in most environments. This privilege would allow a user to
logon as a user and while logged on run processes that would have the
right to add additional privileges. A process could be written that would
leave no identity for tracking events in the audit log.

2. Change the system time

Power Users, Administrators

Change time on the internal computer clock.

Seems innocuous enough. However, you should be aware that Windows 2000
relies on accurate system time to defeat replay attacks, and to coordinate
logon events. The ability to change the system time can severely hamper
these processes, create denial-of-service attacks (no one can logon) and
potentially offer an attacker further abilities to create sophisticated,
time related attacks.

3. Create a token object

(while not visible in the User Rights container, this privilege is
granted to the LocalSystem account.)

If the token is created and attached to a process (see the right 'Replace
a process level token' below) elevation of privileges is possible.
A user account with no administrative rights could potentially gain them,
or gain access to other protected objects.

4. Debug programs

Administrators

Attach a debugger to a process.

To debug a program, access to sensitive and critical operating system
components may be necessary. This is not a privilege that should be widely
distributed

5. Enable computer and user accounts to be trusted for delegation

Activities such as storing encrypted files on computer from across the
network require this right. It is required in order to set the 'Trusted
for Delegation' setting on a computer or user object in the Active
Directory.

In a client/server, multi-tier application it can be used to allow a
front-end service to use user credentials to authenticate to a back-end
service. (both systems, front-end and back-end must be 'trusted for
delegation'. )

Trojan horse programs could be written that would abuse this privilege
by impersonating clients and then gaining access to network resources.

6. Generate Security audits

(Typically granted to accounts that will be used by services. Native
W2k processes already have this privilege.)

Generate entries in the security log

Abuse of this privilege could result in inaccurate and misleading information
being posted to the log, thus preventing accurate audit trails. System
administrators and auditors wouldn't be able to gain an accurate
picture of system and user activity. The security log could be rendered
useless by abuse of this privilege. It would seem, at least to this non-lawyer,
that legal proof of system tampering would be absent or inadmissible.

7. Increase quotas

Administrators

Increase the processor quota assigned to a process. Used to fine tune
the system.

Could also be abused in a denial-of-service attack.

* An exception to this rule is the additional assignments of some of these
privileges to User level groups on Windows 2000 Professional systems. This
practice is proper. For example, users should generally have the privilege to
'Shut Down the system' on the Windows 2000 Professional computer they
operate. Users should not have this privilege on servers.

This tip has been extracted from presentation materials prepared by
Roberta Bragg for the MCP Magazine TechMentor conferences. All rights reserved
by the author.