Practically every time you read a trade journal, there’s news of a new security threat looming over your network. One of the most talked about security attacks is the denial of service (DoS) attack, but one you may not have heard of is the elevation of privilege (EoP) attack. Through an EoP attack, the attacker tricks Windows 2000 into thinking that the attacker has legitimate administrative privileges. With these faked privileges, the attacker can do anything a real administrator could do, including open files, change user accounts, or completely destroy Active Directory. In this Daily Drill Down, I’ll take a closer look at SID-based EoP attacks and explain how you can protect your Windows servers against them.
Elements of the attack
There are two key components of Windows that are behind an elevation of privilege attack: access tokens and the SID History. The access token is basically a list of the user’s SID and the SIDs of any groups of which the user may be a member. The SID History is an Active Directory attribute that tracks the changes of an object’s SID as the object moves from one domain to another. When a user logs into the system, the user’s access token will contain his or her present SID, the SIDs of any groups that he or she may belong to, and any SIDs that were previously associated with the user account through the SID History. Added together, these two elements determine whether the user can access the network and what level of access he or she will have.
How does an elevation of privilege attack work?
To pull off a SID-based elevation of privilege attack, the attacker must be able to determine the SID of another user, preferably either the Administrator account or an account with Administrator rights. Then the attacker must add that SID to his own SID History list. Doing so will grant that user the same privileges as the user from which he has stolen the SID.
As you can probably guess from the description of the attack, this is no small feat to accomplish. It’s very difficult for a hacker from the Internet to succeed in this kind of attack. The hacker would first have to access your network directly, either through a dial-up account or by hacking your VPN.
Most attacks of this type are actually inside jobs, performed by a disgruntled current employee, rogue administrator, or curious user with too much free time on her hands. These attacks are also most common in large companies where there are multiple administrators of multiple domains across multiple locations. The size difference plays a big role in the nature of the attack. In a small company, there are fewer user objects with administrator rights from which the attacker could use to try and obtain an SID History.
EoP attacks work in large environments because there are trust relationships that exist within all of the forest domains of a large network. If you have a rogue administrator within a forest, it would be easy for that user to look up the SID for another administrator from another domain. The rogue administrator could then use an API tool, disk editor, or debugger to add the stolen SID to the SID History list of an account within his own domain. With the stolen SID added to the user’s SID History, the rogue administrator would have administrative privileges in the domain that the stolen SID belongs to along with his own domain.
Reducing the risk
There are a few different things that you can do to reduce the risk of an EoP attack. For example, your organization could do thorough background screening on all administrators, to ensure that they are highly trustworthy. Another step that you could take is to prevent the use of SID histories by avoiding such things as running in Native mode or migrating users to new domains. However, these are only preventative measures. The only real way to prevent the SID-based EoP attack is to implement SID filtering. Unfortunately, as you’ll see, SID filtering is a fairly dramatic step that should be well thought out before implementation.
Before going any further, you must determine the current risk level. To do so, I recommend making a list of all of the domains in your entire enterprise. Then go through the list and rate each domain as trustworthy or untrustworthy. You can base this rating on any criteria that you like, but the reputation of the administrator and the level of security within the domain should definitely be factors.
Now comes the messy part. Earlier, I stated that all domains within a forest have an implicit trust between each other. Therefore, it stands to reason that domains that can’t be trusted shouldn’t be included in the forest. Because of this, you must move untrustworthy domains out of the primary forest and place them into their own individual forest. Company politics being what they are, you may have trouble doing this. You can bet that when you tell another administrator that you are going to isolate her domain from the rest of the company, she will throw a fit, especially if she has been using the present domain structure to gain access to unauthorized resources.
If your position carries enough weight in the company, then move all untrustworthy domains to a separate forest. If you don’t have that kind of clout, then try convincing whoever’s in charge to place all parent-level domains and the child domains beneath them into their own individual forest. If this proves to be impossible, then isolate your own domain into its own individual forest.
Whatever technique you use, you must move your domain into a separate forest from the domains that you’ve deemed to be untrustworthy. The reason that this is so important is that SID filtering doesn’t work properly within a common forest. Implementing SID filtering within a single forest prevents the global catalog from replicating properly and destroys transitive trusts. To put it bluntly, your network will come to a grinding halt if you use SID filtering within a common forest.
Ideally, if you don’t trust a domain, it’s a good idea to cut off all communications with it. Unfortunately, with company politics and business needs, this may not be possible. Therefore, if you simply must have communications with a domain that you don’t trust, then your best bet is to have your domain exist in a separate forest from the questionable domains and then form a Windows NT-style trust relationship between the domains. Once you’ve created the trust relationship, you can implement SID filtering as a way of protecting yourself from EoP attacks from the trusted domain.
Earlier, I mentioned that an SID is composed of the domain identifier and the relative identifier. SID filtering works by looking at the domain identifier of all entries on access tokens from the remote domain. Implementing SID filtering is like quarantining the domain. Once you’ve implemented SID filtering, the domain can’t pass packets to you that originated from another domain. This means that if the domain has a transitive trust relationship with other domains, the transitive trust won’t extend to your domain.
Suppose that your domain is domain A and that the questionable domain is domain B. In a normal Windows 2000 inter-forest trust relationship, if domain A trusts domain B and domain B trusts domain C, then domain A instinctively trusts domain C. However, once you’ve implemented SID filtering then domain A may trust domain B, but it won’t trust domain C.
There are two different ways to implement SID filtering. If you’ve got a Windows NT domain, you’ll have to implement SID filtering by modifying the registry. If you’re using a Windows 2000 domain, you’ll use the NETDOM utility.
Windows NT SID filtering
Before I show you how to implement SID filtering in a Windows NT environment, I should point out that modifying the registry could be dangerous. Editing the registry incorrectly can destroy Windows and/or your applications. Therefore, always make a complete system backup before modifying the registry.
With that said, open the Registry Editor by entering the REGEDIT command at the Run prompt. Next, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. Now, create a new registry key beneath this location. The new key should be called QuarantinedDomains. The new key should be of the type REG_MULTI_SZ. The new registry key’s value should be the NetBIOS name of the domain that you want to filter.
Once you’ve created the necessary filter, you must stop and restart the Netlogon service before the changes will take effect. To do so, enter the following commands:
NET STOP NETLOGON
NET START NETLOGON
The filter should now be active. However, you must remember that the registry is computer specific. Therefore, you’ll have to repeat this procedure for every domain controller in your domain.
If you decide to disable the SID filtering at a later time, simply delete the registry key that you created and then stop and restart the Netlogon service.
Windows 2000 SID filtering
If you’re going to be implementing SID filtering in a Windows 2000 domain, you’ll have to use the NETDOM utility. The NETDOM utility isn’t installed as a part of the Windows 2000 operating system, but it is available on the Windows 2000 CD as a part of Windows 2000 Support Tools. To install the NETDOM.EXE utility, insert your Windows 2000 Server installation CD and wait for the splash screen. On the splash screen, select Explore The CD’s Contents. Next, navigate to the \SUPPORT\TOOLS folder and double-click the Setup icon. When you do, you’ll see a wizard that’s used for installing the Windows 2000 Support Tools. The wizard is relatively self-explanatory. Once you’ve completed the wizard and installed the Windows 2000 Support Tools, reboot your server.
Once your server reboots, log on as the Administrator. Next open a command Prompt window and navigate to the \Program Files\Support Tools folder. Finally, enter the following command to implement SID filtering:
NETDOM /FILTERSIDS YES domain_name
Because you’re working in an Active Directory environment, you only need to issue this command on a single domain controller. The replication service will implement SID filtering on the other domain controllers. To disable SID filtering, enter the following command:
NETDOM /FILTERSIDS NO domain_name
You can also check the filter status by using this command:
NETDOM /FILTERSIDS domain_name
Although an EoP attack isn’t the most common threat you’ll face, if you’re in an environment where security is paramount, you shouldn’t leave anything to chance. Because an EoP attack gives the attacker full administrator rights to your network, an attacker that successfully uses it can do quite a lot of damage to your network, from stealing data to destroying your Active Directory tree. It may take some radical steps to protect your network against an EoP attack, but in a high-security environment, it may be worth the effort.