ZDNet UK


Skip to Main Content

ZDNet.co.uk - Winner of Best Business Website 2007
  1. Home
  2. News
  3. Blogs
  4. Reviews
  5. Jobs
  6. Resources
  7. Community
  8. My ZDNet

 

ZDNet UK RSS Feeds


Server platforms Toolkit

Protect your network against elevation of privilege attacks

Brien M Posey

Published: 29 Aug 2002 16:17 BST

  • Email
  • Trackback
  • Clip Link
  • Print friendly
  • Post Comment

Among the attacks available to hackers, one of the most insidious is the elevation of privilege (EoP) attack. Through an EoP attack, an attacker tricks a system Windows 2000 into thinking that he 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 the Active Directory implementation.

This article will look at how EoP attacks work on Windows 2000 systems, and how you can protect your Windows servers.

Elements of the attack

On Windows 2000 systems, EoP attacks exploit the way the system uses security IDs (SIDs) to allocate privileges.

Two key components of Windows 2000 are behind an EoP 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 an elevation of privilege attack works

To pull off a SID-based EoP 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 whom he has stolen the SID.

As you can probably guess from the description of the attack, this is no small feat. 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 disgruntled current employees, rogue administrators, or curious users with too much free time on their hands. These attacks are also most common in large companies with 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 try to obtain a SID History.

EoP attacks work in large environments because trust relationships 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

You can do a few things to reduce the risk of an EoP attack. For example, your organisation 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 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. As you'll see, SID filtering is a fairly dramatic step that should be well thought out before implementation.

Next

Previous

1 2 3


  • Email
  • Trackback
  • Clip Link
  • Print friendlyPrint with Konica

Did you find this article useful?
134 out of 287 people found this useful


Full Talkback thread

0 comments

Company/Topic Alerts

Create a new alert from the list below: