Administrative Security Dependencies

Administrative Security Dependencies

One of the most common forms of dependencies is an administrative dependency. Simply put, this is where the same administrator account is used on more than one machine. The simplest form of this dependency was demonstrated in Chapter 2, "Anatomy of a Hack: The Rise and Fall of Your Network." You may recall that the way we took over the DC once we had owned the database and Web servers was by using a Trojan horse that fired when an admin logged on to either of those servers. This is an active administrative dependency , where we use a single administrative account to administer several systems of different sensitivities. It can be used to actively take over a system as soon as the administrator logs on to a compromised system.

A related form of an administrative dependency is having identical administrative accounts on two or more systems. This was also used in Chapter 2. The user Mike was an administrator on both domains, and used the same password on both domains. Even though there was no explicit trust between the two domainsthey were not even in the same forestan implicit trust, which proved to be the downfall of the network, arose from the fact that a single administrator, with a crackable password, had identical accounts on two systems.

Now take a moment to think about all the systems where you use the same password! We all reuse passwords, don't we? Single sign on was created specifically to provide this functionality. It is a core tenet of "distributed systems," where systems cooperatively share processing and data in order to appear to a user as a single system. Well, as we mentioned in Chapter 1, "Introduction to Network Protection," that means they appear to the attacker as a single system too! This is why distributed systems is such a bad idea from a security perspective; they build passive administrative dependencies in to the network. The problem is passive, and is just waiting to be exploited by the attacker. However, the attacker does not get immediate access to the systems on the other side of the implicit trust. He needs to find them first. That means the security of networks designed to be "distributed" and using single sign on often is provided only by the time it takes for the attacker to find the next host to take over.

Ultimately, both of these types of dependencies stem from the same issueindiscriminate use of administrative credentials. By logging on as an administrator on a system that has been compromised, you basically just turned all the other nice and secure Windows Server 2003 boxes on the network into Windows 95. It is critical to keep four laws in mind when it comes to administrators:

1. If I can get you to run my code on your system, it ain't your system any more.

2. Any administrator on any system can run code as any other user who logs on to that system, now or in the future.

3. Any program executed by an administrator executes with administrative privileges.

4. Administrators are all-powerful and can do anything on the system. You cannot protect systems from administrators. The only way to restrict actions by an administrator is to turn them into a non administrator (or an ex-employee).

A Word About Administrators

When we say "administrator," using a lower-case a in either singular or plural form (usage at the beginning of a sentence or in a title is obviously excepted from this rule) we mean any user with administrative privileges, including members of the Server Operators and Power Users groups, as well as anything running with setuid root or setgid root on UNIX . If we use "Administrator" with a capital A in either singular or plural form we refer to the built-in Administrator account (singular usage) or Administrators group (plural usage). We may also prefix the group name by one of the modifiers "Domain" or "Enterprise" to refer to that specific group in Active Directory.

Let us examine each of these four laws in turn. The first law is critical. If you run evil code, that evil code is you! It can do anything you can do. If you are an administrator when you run that code, so is the guy who wrote it. This is essentially the issue exploited by e-mail worms.

Law number 2 says that any time a user logs on to a system or executes a program on that system s/he is at the mercy of all of the administrators on that system. Any administrator on that system can cause code to be run as another user. There are myriad ways to make this happen. For example, as was shown in Chapter 2, the administrator could cause a program to be executed at logon by including it in the Startup group or in the proper location in the Registry. The administrator could also directly inject code into a running process running as some other user. This can be done, for instance, by attaching a debugger to the process and then creating a new thread inside that process, or changing the context of an existing thread in that process. The former is the exact process used by the lsadump and pwdump tools shown in Chapter 2. The administrator could also construct a new security token for an arbitrary user, as long as she can successfully authenticate as that user. Should the administrator instead want to steal the user's cleartext password, this is simple by using a custom logon user interface (called a MSGINA) or a credential manager. Implementing two simple functions in a credential manager, for instance, ensures that the attacker gets cleartext passwords any time someone logs on or changes their password.

The third law says that any time an administrator executes a program, that program executes in the context of that administrator. There are ways to stop this from happening by using a restricted token, but such tokens are only valid after the program has proceeded a certain way in execution and created one. No attacker will write a program that does this. Therefore, when an administrator runs an untrusted program, that program can now do anything the administrator can do. Thus, when an administrator opens an e-mail attachment, that attachment has all the rights of the administrator. When the administrator browses a Web site, any code executed from that site has all the rights of the administrator. Because this cannot be restricted in any way, it is imperative to be careful about executing code when running as an administrator.

Finally, the fourth law says that there is no action on the system that an administrator cannot perform. We often try to restrict them, for instance, many people like to remove the "debug programs" privilege from administrators. This is mostly a futile effort. The administrator can trivially obtain any right denied to them.

We very often get asked questions such as "We have two administrators on our system, and we think one of them is trying to attack the other. How do we stop him from doing so?" The answer has never changed: you turn him into an ex-employee. If you have a system with an untrustworthy administrator, that system must be considered compromised. You stand no chance of restricting his actions. Worse, you stand no chance of auditing his actions on that system (auditing that system's interactions with another system through a trusted real-time auditing tool may still be valuable ) since administrators can add, delete, and edit event log entries as well as turn off logging entirely. Finally, if you decide to remove the administrator's administrative rights on the system, he can simply use any of the myriad back doors that were put in place before you did so. Simply put, administrative compromises are not really interesting to even try to mitigate technically since they cannot ever be mitigated effectively by technical means.

What all this means is that the actual administrators include all the administrators on the system in question, plus all the administrators on the systems those administrators log on to, plus all the administrators on all the systems they log on to, and so on, until you end up with a closed set. This means that the actual effective number of administrators on a system is much larger than what it seems if you only look at the Administrators group. After a penetration assessment, we analyzed a system for these dependencies. We started with a single system that had 17 administrators (quite good for a datacenter system). Those 17 administrators collectively logged on to about 35 systems. Those 35 systems had more than 50 distinct administrators. Those 50 administrative accounts were used on more than 100 systems, and those 100 systems had more than 250 distinct administrators. At this point, we got depressed and stopped . We only went two levels and went from 17 to 250 administrators. This is why administrative privileges should be used, and dispensed, very sparingly. In the last section of this chapter we show you how.

One final anecdote is worthwhile. A friend of ours was in Guatemala on business and decided to stop in at an Internet caf to check his e-mail. (Like us he tends to get withdrawal symptoms if he does not check it at least several times daily.) He paid for the time, sat down in front of a computer, and popped up Outlook Web Access. As soon as he typed his password, a dialog popped up that said "An updated version of Keystroke Logger 2.0 is available. Would you like to download and install it now?" That makes you wonder where you have used your administrative accounts, does it not?