For years, Microsoft has been telling IT professionals that the way to secure the administrator account in Windows NT and Windows 2000 is to rename it. However, renaming the administrator account does little to protect it. Hacker utilities such as Red Button can quickly determine the administrator account’s new name. Once hackers know the true administrator account name, they simply need to figure out the administrative password to gain unlimited access to the Windows domain.
Although the Windows administrator account is obviously a necessity, it’s also a great security risk because of how it can be exploited. I’m going to discuss some things you can do to protect the administrator account(s) in Windows.
Why the administrator account is so dangerous
We all know that if someone were to figure out the administrative password, the account could be used for all sorts of destructive purposes. But few seasoned administrators are stupid enough to have an administrative password that can be easily guessed or cracked by brute force, so what’s the big deal? You might be surprised at how easily passwords can be obtained, even in seemingly secure environments.
A cautionary tale
Recently, I was in Kentucky visiting a friend who teaches a computer class at a local college. To preempt any trouble, he has always worked diligently to make sure that the administrator account is well protected on his Windows networks.
The students in the class use Windows 2000 Professional on the client side. One of the students booted a workstation using a utility that allows direct access to the machine’s file system. Once he had access to the file system, he replaced the print spooler service with a utility that records keystrokes to a log file. Then, he called my friend over and told him that he was having trouble printing.
My friend tried all the basic quick fixes and then decided that he needed to reinstall the print spooler. He logged into the machine as the administrator and fixed the “corrupt” print spooler, and the problem was cured. The student then opened the log file that his keystroke recorder had created and instantly had the administrator password. No guessing, no deciphering, no brute-force cracking. He had stolen the password in a matter of minutes.
Fortunately, the student shared the password with some friends, one of whom reported him. But if the student hadn’t been caught, my friend might never have known that the password had been stolen. The student would have had free rein over the network until the next time the administrator password was changed. And of course, he could then have repeated his scheme and stolen the new password.
Other means of compromise
My friend had his administrator password stolen, but he was dealing with smart, computer-literate college students. I’ve worked in offices where I was the only one in the entire building who had anything above the most basic computer literacy skills. Yet the administrator password can be compromised in these environments as well.
For starters, someone can look over your shoulder as you type in the password. And even if you’re careful not to let anyone watch as you key in your password, the administrator account could still be compromised. For example, how many times have you fixed a problem at someone’s PC and accidentally forgotten to log out when you finished the job? Maybe I’m admitting too much here, but I’ve done this more than once. In a stressful corporate environment where everybody is pressuring you to fix their problem right this minute, it’s easy to get in a hurry and forget to log out without even realizing it.
Even if no one in your office is dishonest enough to steal a password and you’ve never forgotten to log out, your administrator account could still be exploited. Just because no one in your office would do anything unethical doesn’t mean there aren’t people elsewhere who would. Thanks to the Internet, your office is connected to the rest of the world.
Suppose that you run a small business no one has ever heard of, you don’t have a Web site, and the chances of your getting hacked are slim to none. In a case like this, hackers aren’t the real (or at least not the initial) problem. The real problem is the Trojan.
A Trojan is a program that appears to be a valid application but is secretly performing some other function. Typically, Trojans transmit information either about your network or about your Internet usage habits to some machine in the outside world. A hacker or another third party (such as an advertiser) then collects this information and exploits it.
You can pick up a Trojan by opening an e-mail attachment containing one, but that isn’t the only way. Scripting enables malicious Web sites to plant a Trojan onto your system when you visit the site. For example, you can go to many hacker Web sites to download hacker tools or to learn about hacking. But while you are distracted reading or downloading a file, the Web site may be planting a Trojan onto your system. Furthermore, most antivirus software does a poor job of detecting Trojans. (Remember, a Trojan isn’t really a virus.) The most reliable way to detect a Trojan is to use a program such as NetBarrier 2003 from Intego.
So what do Trojans have to do with the administrator account? They’re nothing but programs and are therefore constrained by the same rules that apply to any other program. A Trojan’s capabilities are limited by the operating system’s security and by the restrictions placed on the account of the user who’s logged in. So if you are logged in as a user with minimal privileges, the Trojan will be severely limited in what it can accomplish. If you are logged in as an administrator, the Trojan can do anything that its designers want.
Keeping the administrator account from being exploited
As you can see, your administrator account can be compromised through completely innocent acts, such as fixing a user’s printing problem, opening an e-mail message, or browsing the Web. Your job is to keep that from happening. Scanning for Trojans in the same way that you would scan for viruses is a start, but in the end, it isn’t enough. I recommend that you avoid using the default administrator account.
When I make this statement, my mind immediately flashes back to my first network administrator job. I worked for a large insurance company that was very security conscious. The company’s official policy stated that the administrator account was not to be used except in extreme emergency situations. Instead, each person on the administrative team had an individual account that was added to the administrators group. (Today, in Windows 2000, this would be the equivalent of the Domain Admins group or the Enterprise Admins group.)
The person who established the policy wasn’t just worried about the administrator account being exploited but was also worried about auditing. By having each administrator use a personal account, it was easy to track through the audit log who was responsible for each administrative action. Since this was back in 1992, it’s safe to say that the company was very forward thinking in its security policies. However, these days, this particular strategy would not only defeat the purpose of not using the administrator account, it would also compound the problem, because multiple administrator-level accounts could be compromised, rather than just one.
When I’ve written about security in the past, I’ve always stressed the importance of following the rule of least privileges. That rule states that users should have exactly the privileges needed to do their job—nothing more, nothing less. What many people fail to realize is that the rule of least privileges needs to apply to the network support team and to the help desk staff as well.
That said, I’ve been working with networks long enough to know that there are some tasks you just can’t do with anything but administrative privileges. Nevertheless, the vast majority of the tasks that administrators and help desk personnel perform don’t require the full power of an administrator-level account. Therefore, my number one rule is this: Never make anyone (including yourself) a member of the Domain Admins or Enterprise Admins group (in Windows 2000) unless it is absolutely necessary. My second rule: Never use the administrator account unless absolutely necessary.
Instead of using the administrator account, follow the example I mentioned earlier of allowing each person on the administrative and support staff to use his or her individual user account. Instead of granting these accounts administrative privileges, make them a member of the Users and the Power Users groups. This will give the accounts the authority they need to perform the most common tasks without having excessive capabilities that could be exploited.
If the administrative or the support staff needs capabilities beyond the ones offered by the Power Users group on a regular basis, you can always delegate those capabilities to them. For instance, if your support staff needs to be able to reset passwords, you can delegate the authority to reset passwords to the people who need it. First, open the Active Directory Users And Computers console and select the Organizational Unit (OU) containing the user or group you need to delegate authority to. Then, right-click the OU and select the Delegate Control command from the shortcut menu. This will launch the Delegation Of Control Wizard. The Wizard allows you to select users and groups and the permissions that you want to delegate to them.
The Run As command
You can accomplish the most common tasks through delegation, but what about those tasks that you simply can’t perform without full administrative permissions? For most of these tasks, you can use the Run As command. This command allows you to run a specific application as the administrator while logged in as a normal user.
At first, this might seem to contradict your security goals, because you are still logging in as an administrator. But only that one application is running with administrative privileges. All other applications are running under the privileges of the user who initially logged into the system. Therefore, if a Trojan is present in the system, it can’t exploit the administrative privileges. As far as the Trojan knows, it has only the basic user permissions.
To run a program with administrative privileges, hold down the [Shift] key and then right-click the program’s shortcut icon or menu selection. When the program’s shortcut menu appears, select the Run As command. You’ll then be prompted to enter a set of login credentials, which will be used to execute the application.
The Run As command also works for command line utilities. Just open a command prompt window and enter the Run As command. Listing A shows the syntax for the Run As command.
When you use the Run As command, you usually don’t have to worry about most of the command line switches. For example, if you wanted to open Notepad as the administrator, you could do so by entering the following command:
RUNAS /USER:administrator NOTEPAD.EXE
After entering the command, you’ll be prompted for a password. If you enter the password correctly, the application will open.
Although the Windows administrator account is necessary, it’s also quite dangerous. I’ve explained some of the ways that the account can be compromised and discussed some secure alternatives to working with it. These steps can be some of the most important actions you can take to secure a Windows network.