Service Account Dependencies

Service Account Dependencies

The second extremely common type of dependency is a service account dependency. This is best described in terms of Windows systems, although UNIX employs similar techniques under the hood.

When a Windows system starts a service, it must do so in the context of some user. Most services run as LocalSystem (the machine account, which has unlimited rights on the system), LocalService (a restricted version of the machine account), or NetworkService (identical to LocalService,except it can authenticate as the machine account to other systems on the network). However, it is often necessary to use ordinary user accounts for services. For instance, most common network backup software requires a custom service account. This service account needs to be able to back up all files and settings, as well as connect to the system over the network. To enable centralized backup, these accounts are usually local administrators. Many backup solutions explicitly request the use of a domain administrator account to enable backup of all systems in the domain.

To start the service, the operating system must generate a security token for it. For that token to be valid for all needed purposes, it is constructed by authenticating that user using the LSALogonUser function. LSALogonUser verifies the user's password, and then returns a token that can be used to start the service as that user. This, however, means that the OS must have access to the service account's password. To protect the password, the OS stores it in a location called the LSA Secrets. The LSA Secrets is a protected storage area maintained by the operating system capable of storing 4,096 different secrets. It is used primarily by the operating system itself. When the system is turned off, the secrets are encrypted using the system key and stored in the Registry on disk. When the system powers on, the encrypted secrets are retrieved from the Registry at which point they are available to the LSA in plain text. Using the lsadump tool mentioned in Chapter 2, any administrator can obtain a copy of these secrets. In short, the password for any service account used on the system is available in clear text to all administrators of that system.

Some people consider the LSA Secrets a horrible security problem. That is incorrect. Consider the laws mentioned earlier. Administrators can already do anything they want on the system, and you have to be an administrator to extract the LSA Secrets. There is no privilege escalation (within system anyway) here, and therefore this is not considered a vulnerability. As we shall see, there may be a privilege escalation across systems, but that is a network-specific problem and is not an operating system vulnerability.

Now consider a real implementation and the problem should be readily apparent. Suppose we have a network with 5,000 clients and 200 servers. We use an enterprise management system (EMS) to manage and patch all these systems. The EMS has a client component that runs as a service on each system, in the context of the DOMAIN\_MyEMS account. To ensure that all systems can be managed, the DOMAIN\_MyEMS account is a member of Domain Administrators. Now one of these systems gets hacked, perhaps through an unpatched vulnerability. The attacker dumps out the LSA Secrets and discovers the password for the DOMAIN\_MyEMS account. At this point, the attacker has access to a domain admininistrative account and the entire network has effectively been compromised.