Protect Administrator Privileges

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 \usermanager\policy\account. 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_MACHINE\SOFTWARE\ Microsoft\Windows\CurrentVersion\Run 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_MACHINE\SYSTEM\CurrentControlSet\ Control\SecurePipeServer\winreg 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.