Protect Administrator Privileges

Understanding security weaknesses to prevent intrusion

Gaining administrator access is the ultimate coup for a system intruder, so protecting administrative privileges needs to be high on your security priorities list. However, safeguarding your administrator accounts is more complicated than merely assigning a good password. Windows NT idiosyncrasies and bugs and insecure default configuration settings constitute a list of security holes that an intruder can exploit to take over your system. Many overworked systems administrators compound this problem by using some common but insecure administrative practices. Understanding these weaknesses is essential to protecting and monitoring your administrator accounts.

Administrator Account Vulnerabilities
I discussed NT's administrator vulnerabilities in detail in "NT's Top Security Problems," October 1998. I noted that, because of the Administrator account's design, NT is vulnerable to administrator attacks. You can't delete this all-powerful account; therefore, intruders have a clear target for password guessing. To make matters worse, a default-configured NT system won't lock out the Administrator account after repeated unsuccessful logon attempts, even if you set lockout thresholds in usermanagerpolicyaccount. Fortunately, you can plug this security hole. First, execute the Passprop utility with the /ADMINLOCKOUT switch enabled. (Passprop is a Microsoft Windows NT 4.0 Resource Kit utility that first appeared in Service Pack 3—SP3.) The Administrator account will be subject to the same lockout policy as all other accounts are.

Next, rename the Administrator account so that intruders won't have an easily identifiable target. Merely renaming this account will give you a dangerously false sense of security, however. For example, the RedButton exploit program uses anonymous connections to enumerate accounts on a remote system and can use the built-in account's SID, which never changes, to discover the new Administrator account name. To prevent this attack, install SP3 and enable the RestrictAnonymous Registry value. Be aware that doing so can cause some minor browsing problems, as I detail in "NT's Top Security Problems." When you rename the Administrator account, be sure you change its description and full name fields because the default values reveal the account's purpose. Many systems administrators further disguise the Administrator account by creating a decoy Administrator account. The decoy has no authority, but has the default description and full name. The systems administrator can closely monitor this account for logon attempts, which would show intrusion activity.

Bugs
OS bugs are another area of administrator vulnerability. Within NT, a crucial boundary exists between application processes and the system processes. This boundary prevents malicious applications from tampering with the OS and circumventing security controls. The boundary's implementation occurs through one of two modes. Application programs run in user mode, which the system restricts from arbitrarily accessing memory, hardware, and other processes. The OS runs in kernel mode, which is much less restricted. The boundary between user mode and kernel mode, combined with other design features, forms a solid wall, but some OS bugs still exist. For example, the getadmin and sechole programs let nonprivileged users gain administrator privileges on any system where the programs can execute. Another bug lets users run a malicious screen saver to elevate their privileges.

Users continually discover bugs. Microsoft responds to these discoveries by promptly creating patches. Implementing the patches is the only guaranteed protection against OS bugs and the administrator vulnerability they create. To stay up-to-date, subscribe to Microsoft's security bulletin service at http://www.microsoft.com/security. For more information about this important administrative practice, see my Web-exclusive article "Managing Service Packs and Hotfixes," http://www.winntmag.com/articles, InstantDoc ID 4996.

Registry Vulnerabilities
Intruders might try to gain administrator access in several roundabout ways that you can head off with some simple configuration and permission changes. First, the Registry has several keys that contain text values that the system runs as commands when a user logs on. The default ACLs for these keys are fairly weak. For example, when a user logs on, NT examines the HKEY_LOCAL_MACHINESOFTWARE MicrosoftWindowsCurrentVersionRun key. NT then executes each text value in this key as a command under the user's privileges. A nonprivileged user can add commands to the key and wait for an administrator to log on to the system. Then, the commands that the intruder specified will execute as administrator commands. The commands could do anything from adding the intruder to the Administrators group to changing permissions on crucial directories. By default, the Everyone group has Set Value access to this key, so you need to strengthen its ACL. Other Registry keys present the same risk, though the means to an intrusion might be slightly more complicated. For a complete list of keys and ways to secure them, see veteran security analyst Steve Sutton's "Windows NT Security Guidelines" (http://www.trustedsystems.com).

As with many security enhancements, implementing better security on Registry keys can cause compatibility problems with poorly written applications that assume your system is in an insecure default configuration. These compatibility problems are especially common on workstations. I recommend that you concentrate protection measures on servers and domain controllers, which have more stringent security needs than workstations have, and on which interactive use of applications is much lower. OS files under %systemroot% (C:winnt), with their default ACLs, are also vulnerable to modification. Nonprivileged users can replace critical OS files with their own malicious versions, which the system will execute as part of the privileged OS. The specific directories that contain these files and recommended ACL changes are available in many hardening documents such as Sutton's "Windows NT Security Guidelines."

You can give a general level of protection to your Registry and OS directories by restricting remote access to them. You can control who can remotely access your Registry, regardless of the individual key ACLs, through the permissions on the HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ControlSecurePipeServerwinreg Registry key. For more information about restricting remote access to the Registry, see the Microsoft article "How to Restrict Access to NT Registry from a Remote Computer" (http://support.microsoft.com/ support/kb/articles/q153/1/83.asp). Be careful to ensure that users can't access OS directories remotely with inadvertently created shares. When you take these simple steps, you will greatly restrict who can modify the Registry and file system and under what circumstances.

Services
Another way to help protect your administrator accounts is to pay special attention to the services that nonprivileged users have access to. Many services such as job schedulers and database servers let users submit commands that the service executes. Some schedulers are sophisticated enough to impersonate the submitting user before running the command, but other schedulers run the command under the service's own credentials. For example, Microsoft SQL Server has a task scheduler and SQL command that let SQL Server users submit OS commands. You have two ways to protect administrator privileges in this situation. First, you might be able to restrict users from executing commands through the service's internal configuration and options. Most services such as SQL Server and Microsoft Exchange Server have their own authentication and access control mechanisms. Make sure to configure these mechanisms correctly and keep the services up-to-date. Second, these services often run as the local System account, which is even more powerful than an Administrator account. You can create a separate account for the service, giving it only the rights and permissions it needs to do its job. Then, if someone succeeds in compromising the service, he or she will gain access only to that account and perhaps not the entire system.

These considerations are especially important with the NT Scheduler service. By default, this service runs as the local System account. If you run this service at all, run it as a nonprivileged user. In any case, be aware that members of the Server Operators group can execute commands through NT Scheduler if the HKEY_LOCAL_MACHINESYSTEM CurrentControlSetControlLSASubmitControl value is set to 1. If NT Scheduler is running as System or an administrator, server operators can elevate their own accounts to administrator level. Make sure to set SubmitControl to 0.

A final note regarding configuration: Remember that NT is vulnerable to physical access. If intruders can boot DOS or another OS, they can gain access to a system in several ways. You can provide protection by using BIOS-level passwords that limit booting and modification of CMOS settings. Don't rely too heavily on these features, however. An intruder can circumvent them by resetting the BIOS or removing the battery or hard disk. Web pages exist that list the factory backdoor passwords for many brands of BIOS. Your best protection is to keep your server and its backup tapes and Emergency Repair Disks (ERDs) under lock and key.

Best Practices for Administrators
A solid system configuration is important for protecting your administrator accounts, but don't stop there. Just as important is implementing strict usage rules for your administrative accounts.

I recommend against using the built-in Administrator account as the active Administrator account. Because the Administrator account is the first target for intruders, you can use it to track intruder activity. If you enable logon auditing and refrain from using the Administrator account, you'll be able to quickly identify probing activity by looking for event 528 (successful logon) or event 529 (failed logon) on the Administrator account in the security log. Simply keeping your applications patched and avoiding executing downloaded files doesn't afford adequate protection. The current environment is too complex, dynamic, and bug-ridden for that approach to work.

Another good reason not to use the Administrator account is to provide accountability among administrators. If more than one person shares the Administrator account (or any account, for that matter), accountability disappears. Audit trails won't tell you exactly who did what. Therefore, creating a separate administrative account for each person is a good practice. I've observed some spirited discussions about how more administrative accounts increase the probability of system compromise, but most critics agree in the end. Whether you use one Administrator account or multiple accounts, you have the same number of users who can divulge a password. Therefore, when you create separate accounts, you can track account activity precisely and avoid the problems that shared secrets create. In addition, when an administrator leaves the group, you don't need to change the shared account's password and determine whom you need to notify; you simply disable or delete the departing person's account.

An important rule for administrators is never to run untrusted programs when you're logged on with administrator privileges. An administrator running untrusted code is like a military officer executing a missile-launch command without authenticating the order. But putting this recommendation into practice is easier said than done in today's environment of dynamic macro content and omnipresent Internet access. Web browsing, for example, is nothing less than executing untrusted code and should therefore be forbidden when you're logged on as an administrator. Unfortunately, email is also dangerous. Several well-publicized recent events have demonstrated an intruder's ability to execute arbitrary code on a second machine simply by sending email to it. In one such case, the intruder leveraged a buffer overflow bug in Microsoft Outlook 98's handling of email attachment filenames. Similar dangers exist in applications such as Microsoft Word and Microsoft Excel because of the proliferation and power of macro viruses.

To really protect administrator accounts, you need to create two accounts for each administrator—one with administrator privileges and the other without those privileges. Administrators can perform their usual day-to-day activities with their nonprivileged accounts and log on with their administrative accounts only when they need to perform an administrative task such as maintaining user accounts or updating permissions.

You might wonder how you can refrain from running your Web browser, email, and other everyday applications and still perform your duties. Many administrators must switch back and forth between User Manager for Domains and email or other workflow applications on a minute-by-minute basis. Therefore, administrators seldom implement the important but impractical rule never to run untrusted programs. Fortunately, the resource kit has a nifty utility—SU—which Screen 1 shows. SU lets you run a given program under a specified user account. You can log on to one account and run applications under a different account from the same desktop. To protect your administrator privileges, make it your policy to log on to your desktop with your unprivileged account and launch your regular applications, such as email, word processors, and Web browsers, from their usual icons. Any malicious code you inadvertently execute will run under your restricted, unprivileged account. Then, set up a shortcut for applications such as User Manager for Domains and Server Manager that must run under administrative privileges. Use SU to configure these shortcuts to launch the applications. The only inconvenience you'll experience is that you'll have to enter your password when you log on. For more information about SU, see Mark Minasi, This Old Resource Kit, "SU," January 1998.

Member Servers and Workstations
You'll benefit from monitoring security settings on member servers and workstations that you've assigned to persons with access to critical resources, because these systems are vulnerable to administrator attacks. Each member server and workstation retains its SAM for local rights assignments and membership in local groups. Many advanced user rights, such as Act as part of the operating system, and rights dealing with tokens let intruders circumvent controls and steal administrator privileges. The built-in Administrators and Power Users groups have some powerful privileges over the local system.

Finally, be sure you know who is responsible for rolling out NT workstations in your company. Contractors or interns often handle this task, and because they install the OS, they choose the passwords for built-in Administrator accounts. Most users aren't aware of the built-in Administrator account, and most administrators never think about it after a workstation is set up. In addition, the Server service is enabled by default on NT workstations, making a workstation a file server. Should outside contractors or junior staff members have administrator access to workstations after you've assigned the workstations to users? Probably not, but they often do, depending on a company's installation method. Picture this scenario: A junior IT staff person who has been at a company only a few months has access to the vice president of marketing's or human resources' (HR's) workstation. I frequently find this scenario in assessments that companies hire me to perform. Workstations are vulnerable treasure troves for system intruders because applications cache temporary files locally, as do users who store sensitive information on their local hard disks, despite policies to the contrary. Don't make system break-ins any easier. Reset the Administrator password on workstations and member servers, and consider disabling the Server service.

Some of my suggestions are controversial among systems administrators, and some administrators might argue that I'm advocating security through obscurity. But administrator privileges are an obvious target for system intruders, and with the ever-increasing frequency of intrusions, exercising vigilance is wise. Perhaps the most embarrassing thing that can happen to an administrator is for an intruder to steal administrator privileges to break into a system.