Although modifying the SIDHistory attribute of AD user accounts isn't easy (it can be done only when AD is in offline mode), it's possible. Tools are available that help malicious administrators populate the SIDHistory attribute. A good example is the SHEdit tool that can be downloaded from http://www.tbiro.com/projects/shedit/index.htm.
This attack can be carried out in any kind of Windows domain trust setup: between the domains of a single forest or between domains that are linked by an external or forest trust relationship. In a single forest setup, for example, rogue child-domain administrators or any rogue users with physical access to a DC could attempt to leverage the SIDHistory vulnerability to elevate themselves to the Enterprise Administrators group.
ATTACK THREE
Prevention
To mitigate the risks related to the SIDHistory attribute, you must make sure that members of the Enterprise Admins group and Domain Admins groups are very trusted individuals. You must also ensure a high level of physical security on your DCs to prevent rogue users from taking DCs offline and exploiting this vulnerability.
To prevent an administrator from changing the SIDHistory attribute, you can also use the SID filtering feature on trust relationships set up between domains in different forests. SID filtering allows administrators to quarantine domains. When SID filtering is enabled, the DCs of the trusting domain check whether the authorization data included with resource access requests from the trusted domain is related to the trusted domain. The DCs of the trusting domain automatically remove the SIDs that aren't related to the trusted domain. Because this operation also removes SIDs that were added to the authorization data because of the SIDHistory attribute, SIDHistory and SID filtering are mutually exclusive features.
SID filtering is available in Win2K SP2 and later. You can turn it on or off by using the netdom.exe command-line utility; in Win2K, use the trust and /filtersids switches as described in the Microsoft article "MS02-001: Forged SID could result in elevated privileges in Windows 2000" at http://support .microsoft.com/?kbid=289243. In Windows 2003, use the trust and /quarantine switches. SID filtering is turned on by default for Windows 2003 external and forest trust relationships.
You shouldn't use SID filtering on trust relationships between domains in the same forest. Doing this breaks AD replication and transitive trust relationships. If you want to quarantine a domain, you should put it in a separate forest.
ATTACK FOUR
DoS Attack Based on Excessive AD Object Creations
Another way for users with administrator permissions to launch a Denial of Service (DoS) attack against AD is to flood it with new object creations. An authorized user can for example bring down an AD server by creating AD objects until the DC runs out of disk storage space. Another example is an authorized user adding many thousands of group members to a group by using one add command.
ATTACK FOUR
Prevention
To protect against this attack, you must again be extremely careful about whom you give AD object creation permissions to. Another feature you can use is the AD object quotas introduced in Windows 2003. A limited version of the object quota feature is also available in Win2K.
AD object quotas determine the number of objects that can be owned in an AD naming context (NC) or directory partition by a particular security principal. AD object quotas can be specified and administered separately for each AD NC and directory partition. However, you can't define them for the Schema NC. You can define a default quota for every AD NC and partition; if you don't explicitly set a default quota on a partition, the default quota for the partition is unlimited.
AD tombstone objects owned by a security principal are counted as part of the AD object quota consumption of the principal. Tombstone objects are temporary AD objects created when an AD object is deleted. AD uses them to keep deleted object data consistent across AD DCs. For each NC and partition, you can specify a tombstone quota factor that determines the weight given to a tombstone object in quota accounting. For example, if the tombstone quota factor for a given NC or partition is set to 25, then a tombstone object in the partition is counted as 0.25 of a normal AD object. The default tombstone quota factor for each partition is set to 100, so by default, a tombstone object has the same weight as a normal AD object.
You can assign quotas to every security principal, including the user, computer, group, and inetOrg-Person principals. A security principal can be covered by multiple quotas; for example, a user could be assigned an individual quota and also belong to a security group that has an assigned quota. In such a case, the quota that will be applied is the largest quota assigned to the security principal. Members of the Domain Admins and Enterprise Admins groups are exempt from AD object quotas.
Prev. page
1
2
[3]
4
next page 
