Home > Articles > Operating Systems, Server > Microsoft Servers

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

  • Print
  • + Share This
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

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

Create access tokens. Access tokens contain user account group membership and user rights.

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.

  • + Share This
  • 🔖 Save To Your Account