Introduction Anyone familiar with security architecture of the Windows NT family of operating systems knows that one of the

biggest threats to the structure is in the NetBIOS services. Such threats were discovered early on in the existence of NT in both versions 3 and 4. Since then, administrators have learned a few things about how to harden an NT host to protect it from nasty NetBIOS information-gathering tricks. Now there's a new Microsoft operating system on the block, with new directory services and authentication mechanisms, namely, Active Directory and a "Microsoftized" version of the Kerberos authentication system respectively. Administrators with security concerns might be glad that NetBIOS and the old NT domain model are disappearing. They might be thinking, "phew, no more NetBIOS to worry about!" They may be anticipating that there will be no more null session holes and concerns, no more insane L0pht Crackers, no more master browser disputes, and no more quick easy dumps of every critical server on a network by the service they provide. Administrators may think they are safe now, right? Wrong! Issues like these still exist, they've just changed according to the new architecture. In fact, unless NetBIOS is explicitly turned off, it still runs on a default install of Win2K. Unfortunately, while one might think the new technology is more secure than earlier versions, it's still going to have to be tested in the real world before some very big, nasty issues are discovered, publicized, patched, and people are educated about them. Until then, users may be resting on a lot of yet undiscovered bugs. These bugs may prevent people from embracing Active Directory, despite all of its wonderful features. This article is the first in a series that will discuss some potentially major security issues that may exist in the implementation of Active Directory. As Active Directory is a very large, complicated technology, these articles will come nowhere near reviewing the entirety of the subject. This installment will offer a brief overview of Active Directory, as well as a very introductory look at some of the security issues surrounding it. The next few articles will discuss the following subjects:

Understanding the Security Implications of Active Directory Default Settings Understanding SASL, Kerberos, LDAP v2 & v3, and What They Have to Do With Active Directory Security The Configuration Naming Context (Keys to the Kingdom), Some Caveats, Some Issues A Theoretical Attack on the Multi-Master Replication Scheme in a Massively AD Enabled Network in the Enterprise (a.k.a. what the disgruntled employee/ex-employee could do to really screw up an organization.)

This article is targeted primarily at readers who are running Active Directory right now, or who are considering migrating at some point in the near future. In order to better understand the issues that will be discussed throughout this series, it may be helpful to first talk about some basics of Active Directory and the technology that it is based on. In some cases, the issues to be discussed are more to, or are inherited by the technology that most very high speed network directory services (such as AD) rely on these days: LDAP. LDAP

LDAP stands for Lightweight Directory Access Protocol. It is based upon X.500 Directory Access Protocol technology, but is much smaller and faster, with a lightened feature set that allows for it to be run and scaled on most hardware. LDAP is the basis for numerous commonly-used systems, and has quickly become THE technology for high speed, directory enabled programs and networks: Novell NDS (in recent versions) is based on LDAP as are many implementations of UNIX workgroup technology, to name but a few. LDAP v2 has been fairly prevalent in the past and many systems still run on it. LDAP v3 now exists as well and has many improvements over LDAP v2, some in the security realm, others in the schema and performance realm. Active Directory is compatible with both versions of LDAP, but only in certain distributions. While there is much discussion and dispute over exactly which distributions will and won't work with AD, this series won't comment on that issue other than the discussion of LDAP v2 integration with AD and the security thereof. As Active Directory is a very large, complicated technology, this series cannot offer an overview of the entire technology (For a more in-depth overview, please see Support WebCast: Windows 2000: Directory Services, Part One.) For readers who are not currently using Active Directory, but who are considering migrating to it, the following section will offer a brief overview of a dump of an Active Directory tree for a hypothetical domain name, dgs.com. It is the result of a connection event (just a connection, not a bind or an authentication, a distinction that will become important to understand later) to the Active Directory "root" server for dgs.com using Microsoft's excellent ldp.exe tool. For reasons of brevity, I haven't included the whole dump, only a few select portions of it for now.

Established connection to active. Retrieving base DSA information... Result <0>: (null) Matched DNs: Getting 1 entries: >> Dn: 1> currentTime: 6/28/2001 20:32:48 Pacific Standard Time Pacific Daylight Time; 1> subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=dgs,DC=com; 1> dsServiceName: CN=NTDS Settings,CN=DGS-ACTIVE,CN=Servers,CN=Default-FirstSite-Name,CN=Sites, CN=Configuration,DC=dgs,DC=com; 3> namingContexts: CN=Schema,CN=Configuration,DC=dgs,DC=com; CN=Configuration,DC=dgs,DC=com; DC=dgs,DC=com; 1> defaultNamingContext: DC=dgs,DC=com; 1> schemaNamingContext: CN=Schema,CN=Configuration,DC=dgs,DC=com; 1> configurationNamingContext: CN=Configuration,DC=dgs,DC=com; 1> rootDomainNamingContext: DC=dgs,DC=com; information removed here 1> highestCo serverName: CN=DGS-ACTIVE,CN=Servers,CN=Default-First-Site-Name,CN=Sites, CN=Configuration,DC=dgs,DC=com; 1> supportedCapabilities: 1.2.840.113556.1.4.800; 1> isSynchronized: TRUE; 1> isGlobalCatalogReady: TRUE;

Here's a quick legend to help you understand the acronyms used: DN = Domain Name DC = Domain Controller CN = Canonical Name (or short/easy name) NTDS = NT Directory Services USN = Updated Sequence Number SASL = Simple Authentication & Security Layer GSSAPI = General Security Services API GSS-SPNEGO = General Security Services - Service/Security Protocol Negotiator DN = Distinguished Name RDN = Relative Distinguished Name

Those of you that understand LDAP or have worked with Novell NDS will see that some of these names look familiar. For those of you that don't, or those of you that don't understand Active Directory in general. I recommend that you visit Microsoft's knowledge base or refer to the Support WebCast: Windows 2000: Directory Services, Part One. Let's start from the top of the dump: the name of the server is 'active.' The name 'active' is one that I have included in my host file for quick entry. The actual name of the server is DGSACTIVE. Hence we actually have a connection to DGS-ACTIVE. The next entry states that the base information for the directory services agent is being retrieved. A receipt of a null signifies the completion of that run, and then we get a match of the domain name for the entry of DC=dgs,DC=com. Those of you who are familiar with Netware (which is also based on LDAP) might be seeing something that looks familiar. This information signifies that this server is the root server for the dgs.com domain. This concept ties directly to DNS, where there are also root name servers. In DNS terms, you might consider that this server is known as .dgs.com (with and underline on the . to signify root status.) Next, a time stamp is attached to the report and we get the first pieces of information about the actual server and tree. A standard response is included in the next entry, in which the aggregate information for the Schema Configuration for the DGS.COM tree is shown. The last line for that entry is the directory service type that will be providing this information. Theoretically, this entry could be LDAP, or NDS, or NTDS, or NTDS2. However, since we are connecting to an AD server after a default installation, the only entry we should expect to see is NTDS. Next, we move on to the general settings for this particular tree. The numbers that start each entry denote that there is only one piece of information listed in the directory for each entry. You'll note that later on in the list, there is a '3', which means that the naming contexts available are each of the entries separated by a semi-colon, namely: 'schema,configuration,dgs,com', 'configuration,dgs,com', and 'dgs,com'. If you're wondering why I separated the CNs by commas, it's because that's how one separates CNs in a syntactically correct manner. The next few entries should logically fit according to their labels before the DN is given. What is a DN? A DN is simply a linking of all CNs and DCs relative to an entry. For example, one might call the c:\winnt\system32 directory the 'system32' directory and others would probably know what was being referred to. This naming convention would be referring to the c:\winnt\system32 directory name via its RDN, or Relative Distinguished Name, which is okay because most admins know that the system32 directory is commonly relative to the c:\winnt directory. If one wanted to be more specific, he or she might use the Distinguished Name, which means they would need to call the directory c:\winnt\system32. Active Directory and Security Among the advantages of implementing Active Directory on a network are the features and functionality it allows: it makes user administration, security policy administration, Exchange administration, and a host of other things much easier, efficient, and less time consuming. However, as alluded to in the introductory section, security concerns must be taken into account? Administrators must consider that with a massive directory service (such as AD) running on their network, with the power and flexibility that it provides, much more detail is going to needed in the security policy, both in technical and personnel sections. As well,

incident response, the monitoring of both performance and security will also need to be taken into account in order to protect the information systems of the organization. In an AD network, in order to function, everybody has to connected in order to operate properly. This means that all users are exposed to potential propagation of viruses, trojans, and worms, as well as other security threats. Any administrators who have used MS SMS products have probably made the humbling error of selecting the wrong group of PC's to receive an immediate package roll-out. Some might have selected the wrong group with a title like "Entire Enterprise NT 4.0 Group." Some might have seen all of their systems reboot and start installing an incompatible package that would blow a number of machines away. Meanwhile, they have realized this and started scrambling to unplug the SMS servers from the network in a mad panic. Readers who have made this mistake realize that it was an innocent, dumb mistake. But imagine what could have been done if this mistake was committed intentionally by an intruder who meant to do harm. As we shall see in subsequent installments in this series, Active Directory can be used towards similar, broadly effective ends. Conclusion It is hoped that this article has provided readers with a bit of an understanding of some of the security issues raised by Active Directory; however, it was only intended to serve as an introductory overview. In the next article, "Understanding the Security Implications of Active Directory Default Settings", we will begin to attempt to break down some of the many issues to face with AD , considering AD at its point of default inception on a network, including some information that will lead into the following article on AD management and authentication mediums.

In the last article, there was a brief introduction to Active Directory as it relates to LDAP, NT 4 directory services, and a few other things. Understanding the structural and syntactical layout of an LDAP/AD database was also covered in brief. Lastly, some general thoughts were given out about the implications of making a computer network as integrated, reliant, and controlled by a massive directory service like AD. In this article, we'll begin to approach AD security implications in a more technical manner. The scope of this particular article is largely around accounting, permission, enumeration, and logging issues. This article does not cover default DNS settings. This article begins considering AD security with the installation of the first Win2K domain controller in an AD network: the root through which the rest of the AD tree/forest will grow. Most networks with AD in them are still in large part based on NT 4 directory services. As such, the AD network will be installed with permissions compatible with pre-Windows 2000 networks. Herein, we discover our first major security implication. Selecting that option grants most of the information gathering options that were available on NT 4 networks when an attacker established a what's been known as a null or IPC$ connection. This connection

allows an attacker to gather all sorts of information about users on the domain and may also include listing which services the server has available, which ones are running, descriptions of those services, and a host of other things. In short, installing in non-native mode will bring back security issues that might have been thought lost by moving to Win2K. Be aware of this when installing Active Directory in non-native mode. (As a note, NetBIOS is still active on any machine, including domain controllers, in a default Win2K install). Another thing to be aware of is that logging may not be set up the way you may have hoped. For instance, by default, security logging is not enabled?at all. Good login, bad login, service lookup, none of these things are logged. Some readers with administrative experience will remember that security logging is not turned on by default in NT 4, and so will not consider this an issue, rather, they will consider it as something that should be known in advance by anybody who is going to set up a domain in the first place. In the case that you are not aware, make sure that security logging is turned on in your policy. While on the topic of policy, the question may arise around which events to enable, and when one should enable successful and unsuccessful audits. One item that should be checked, at least for failures, is Directory Service Access. Administrators might, for various reasons, decide to keep this particular policy at default settings. This is not a wise idea. If logging is not enabled for Directory Service Access, any attempts to alter the directory will not be logged. If you don't understand the meaning of this, consider the following: The directory is a lot like any normal windows registry, except that the directory exists on the network and a windows network depends on the directory to function well. Any amount of mischievous tweaking with a normal windows registry can render a system unusable. Following that line of thinking, any amount of mischievous tweaking with the directory can render a network unusable. Hence, you probably want to be aware in the case that a user is trying to alter objects in the directory that he shouldn't be. We'll touch more on the topic of directory fragility in the fifth article in this series, but for now, keep that concept on the back burner. Another thing that might be cause for concern, and is not "point and clickably" easy to prevent (a workable solution is not present within this article) is that by default, authenticated users can view a number of things within the directory which they should not be able to view in a secure environment. For instance, users can view the domain configuration (DC=domain, DC=com), the schema (CN=Schema, CN=Configuration, DC=domain, DC=com), the configuration naming context (CN=Configuration, DC=domain, DC=com), and another area of the directory that does not have an official name, to my knowledge: (CN=System, DC=domain, DC=com). In the next few paragraphs, we'll consider the significance of each of these sections of the directory. We'll start with domain configuration. I prefer Microsoft's LDP tool as a means for browsing the directory. Here, we have attached to the tree with the user joebob1. We opt to view the DC=dgs, DC=com portion of the directory. These are the options presented to us.

It would be fair to say that there are at least a few things within this context that would be considered sensitive material. At this point, not only are these things sensitive material, they are sensitive material stored in a nicely centralized, organized, viewable container. For example, from here, we can list all domain controllers. As you can see below, our domain controller, DGS-ACTIVE is listed, along with some other sensitive information (for instance, drive and path where sysvol is located on each particular domain controller, such that an attacker has information available on where he needs to place files to be replicated across the domain). Once this information has been obtained, these servers can be targeted individually if desired, as they are all listed within DNS.

Continuing on, we'll move to the schema. A screenshot has not been taken of the schema because it's too large to fit in this document (there are hundreds of entries). However, for those that don't know what the schema is, I will offer a brief explanation. The schema is a section of the directory that defines what else can be stored in the directory. You might consider it as a global inventory system of sorts for the directory. Whatever is listed in the schema, how it is listed, and the information allowable for each listing, as well as the formatting for that information, is what is available to be put into the rest of the directory. For example, Canonical-Name is one of the listings in the schema. Having Canonical-Name listed in the schema means that Canonical-Name can and may be listed elsewhere in the schema. Removing Canonical-Name from the schema means that the rest of the directory can no longer support the attribute Canonical Name. (Some of you who have a penchant for seeing the evil and nasty possibilities of manipulating such things, or just flat out removing them probably have wicked grins on your faces right now). Those of you that learned anything about the active directory schema probably remember that one of the first things you learned about the schema is that manipulating the schema can lead to very hazardous consequences. Before getting too carried away with concern, remember that

your average user only has read-access to this information (all of these contexts only have read access-available to them), so he/she can't manipulate it at this point (only schema admins can manipulate it). Being aware of each of these pieces of information and having access to see exactly how each of these things is configured is the first step in gaining access to them, however. It would be better if these things were not viewable in the first place. One other thing (of possibly many things) to be concerned about with being able to view the schema depends on whether or not the schema has been expanded to suit new features or applications. Be aware that if those expansions have not had security-attention paid to them, they may become very critical pieces of information picked up on the road to compromising your network? as has been iterated before; be careful what you do with your schema. On to the configuration naming context! The configuration naming context is one of the most critical objects in AD. It controls and stores a number of things; but perhaps most importantly, it controls how Active Directory "lives" on the network. By that I mean that it stores the information and configuration for how the directory is replicated throughout an AD network. Here's some of the information available to any domain user by default (note, the screenshot doesn't cover everything here, but would go for pages if it did):

Lastly, RDN System is another section of the directory that exposes critical information. Due to size constraints for this article, I won't show a screen shot, but I encourage you to run the LDP tool (or some other LDAP client of your choosing) against your directory and verify

these details for yourself. A couple of particularly interesting sections to look at are IP Security, MicrosoftDNS, and File Replication Service. Hopefully, this article has been enlightening to you and you'll continue reading the series when the next article, Understanding SASL, Kerberos, LDAP v2 & v3, and What They Have to Do With Active Directory Security is published. All of the topics in the next article could have books dedicated to them. We'll just touch on some of the key topics as they relate to Active Directory. I'm sure that it's already clear that there's a lot to be learned and to be considered about the relative security of this new technology. This article is the third in a series devoted to discussing security issues surrounding Active Directory, also known as AD. The first article offered a brief overview of Active Directory. The second article offered an overview of the security implications of AD's default settings. This article will offer an overview of the relationship between LDAP, SASL and Kerberos, and examine what they have to do with Active Directory Security. Some Feedback From Last Time Before I start the article, I'd like to include feedback that was received from one of the readers of the second installment in this series. I feel that it is timely to the subject and might make those that deploy Active Directory consider whether or not connection to the Internet is an issue. I'd originally written this series of articles (especially the upcoming Part Five) with the thought in mind that most attacks on AD from within the organization or company. However, as this message illustrates, it may be possible to exploit the things that have been mentioned in the two previous articles from outside the network. Readers who have made the error of making their AD available at the perimeters of their networks should take caution from the words of this reader.
#/snip When it comes to AD and security I think that the problems already have started to grow. Both from performing security investigations for our clients and from analyses of our firewall and network monitoring logs we have seen that the hunt for finding ADs and trying to exploit them already has begun. In fact, at least here in Sweden, I'm horrified to see the number of badly (read: default) configured w2k/AD servers that are out there. Another obstacle is that some firewalls seems to be configured to let port 389 through since some companies have been using LDAP-directories in a rather public manner. When they install boxes that makes use of AD's, the forget to check their firewall(s). Running the following small script (on a Linux box, similar scripts can probably easily be made for MS systems as well) with a host list generated by nmap or similar scanners that has been told can for port 389 will get you incredible amounts of AD-related information. #!/usr/bin/perl # Replace with nmap scan for port 389, then # read list of hostnames from a file, cmdline etc. # and read it into @hostlist foreach $host (@hostlist) { open(CMD,"|ldapsearch -s base -b "" -h $host *=* > $host.ldif"); close(CMD); } We've already seen several probes which seem to utilize such a principle. #/snip

The meaning of this message should be apparent, especially if you've read the past two articles in the series. It is also a perfect lead-in to this article because it notes one of the cornerstones of AD technology: LDAP. LDAP

As was mentioned in the first article, LDAP, or Lightweight Directory Access Protocol, is the technology on which AD is based. It is also the basis for Novell NDS. Some of you may know of a wonderfully talented hacking group at the Nomad Mobile Research Center. This group released a number of things that relate to hacking Novell's Netware. Not only did they produce a number of FAQs and how-tos concerning faults in the Netware OS, they also released a well known tool called Pandora, which simplifies and automates the ability to attack a Netware-based host/network. Some of the most dangerous (in my opinion) components of their research dealt not so much with Netware, but with LDAP. For instance, one of the problems with Netware was that a user could glean all sorts of critical, sensitive information from an NDS tree (through an action called "attaching" in Novell-ese. Some call it binding, but that might confuse those familiar with older versions of Netware.) without even needing a valid login and password. This vulnerability was not based so much on Novell and NDS as it was LDAP. So, do you think Microsoft implemented solutions for these kinds of problems? In short, the answer is 'no.' It's not so much Microsoft's fault either; rather it is the fault of LDAP. It is simply not possible to write a directory service that is fully (or mostly, or partly, depending on who you ask) standards-compliant, compatible and capable of being integrated with other LDAP directory services (like NDS and some other UNIX-based releases) without inheriting these problems. I have been led to believe that many of the vulnerabilities discovered by NMRC are "almost portable" to AD. These problems stem from the very beginnings of LDAP, so that is where we'll start. LDAP v2 is where our problems begin. (We won't cover LDAP v1, largely because I've had little experience with it and it's not really involved with AD.) To begin with, we need to cover the process of how one connects to an LDAP-based directory service (this all applies to AD). The connection goes as follows (I've taken the liberty of calling the LDAP database a "tree") in the diagram:

The important lesson to learn here is just how much one can gather from an LDAP tree without authenticating. In some cases, if permissions are set strictly for user objects but nothing is considered for the "anonymous attach-er", the "attach-er" will be able to get a cursory vision of more of the tree than an authenticated user object. Likewise, making an anonymous connection and/or attachment to an AD tree (as was mentioned in the e-mail snippet) may earn a curious/malicious party quite a bit of sensitive information. Also, as the flowchart illustrates, in LDAP v2, unless some secure authentication module has been added to the LDAP server, authentications are done in clear text. Out of the box, Active Directory does a decent job of not allowing clear text authentications. However, if users are integrating AD with some other LDAP server, they should beware. They may unthinkingly allow clear text authentication to occur simply to be compatible. Readers should take care when considering just how much LDAP v2 functionality they will allow in their network. However, as was mentioned previously, as far as out-of-the-box requirements for encryption is concerned, AD does a good job handling the authentication. That's not to say that there aren't problems with the authentication systems (see SecurityFocus's Windows 2000 LDAP SSL Password Modification Vulnerability report as one big example), but AD is capable of doing a better job because it is also built to support LDAP v3. LDAP v3 is stronger than v2 in terms of authentication and security. The possibility for making anonymous attachments to gather information still exists; however, LDAP v3 integrates SASL into the picture. With SASL, any authentication/encryption system can be implemented. In the case of Active Directory, Microsoft chose to go with Kerberos v5? sort of. Active Directory and Kerberos

Microsoft's version of Kerberos is based on the MIT standard for Kerberos v5 but Microsoft has taken the protocol one step further, in a Microsoft direction, so to speak. That's not to say that this is necessarily a bad thing. What it does mean is that a tried and true system developed by the IETF has been tweaked it a little; as a result, it is now not a tried and true system, which means that there could be security design issues that could affect users directly. That could mean some compatibility issues with other authentication systems in network that uses Kerberos v5. Microsoft has written the Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability in order to facilitate the interoperation of Kerberos with other systems (like some UNIX systems using kinit). Bear in mind, however, that such compatibility deviates both from the Windows 2000/AD norm and from the UNIX norm. Why would this be a problem? Because within interoperability, the two authentication systems are now no longer being implemented as they were originally intended. Some readers may be thinking that this particular approach to the topic represents an attempt to do spread fear, uncertainty and doubt. However, my own preliminary research and my views on computing security history lead me to feel some uncertainty and doubt about the degree of security that interoperability can offer. The following analogy may serve to illustrate this point. Anyone who is bilingual or multilingual will tell you that there are occasions in which words, ideas, and phrases don't translate exactly between two languages. In a case like this, one is forced to make some assumptions and some changes to the original word, idea, or phrase in order to properly process it in another language. In other words, some leeway, extra room to operate, and flexibility is required. Leeway, extra room to operate, and flexibility may be important in language, but they are not good when designing a secure system. In fact, they detract from making a system act/behave in an exact manner. A system can generally be considered secure when it acts the same way, all the time, regardless of circumstances and conditions, and is incapable of acting any other way. This is desirable because generally when an attacker breaks into a system, they are able to do so by getting it to act differently than it should. Accordingly, getting an authentication system to act abnormally can result in such things as false authentications, bypassed authentications, and more. How will Microsoft's Kerberos stand up to the test? Time (and more research) will tell. LDAP and SASL Getting back to the topic of LDAP v3, we come across a security technology introduced with LDAP v3 called SASL, which stands for Simple Authentication and Security Layer. In the case of AD authentication, SASL works with another technology: SPNEGO, or Security Protocol NEGOtiation. SASL and SPNEGO determine exactly what protocol or protocols can be used to authenticate to the directory (in an ideal situation, where all LDAP v2 functionality is as removed as possible.) Currently, SPNEGO only seems to choose between two protocols, NTLM and Kerberos. (Some more experienced readers may be asking why I'm not mentioning the component called GSS-API. I'm choosing to ignore it in this case for simplicity's sake). Users who opt to authenticate to the directory with some other protocol will get an error message stating that no common authentication mechanisms are available.

One additional note about NTLM in the AD environment: using NTLM may effectively nullify most of the benefits of using Kerberos. If an attacker can force NTLM negotiation in networks and then crack the password hashes, it doesn't matter how effective Kerberos is in preventing the option of sniffing for passwords, because an attacker has a way around it. (I'm currently in the process of researching and developing a utility that will effectively allow a third-party attacker to force two systems to authenticate via NTLM, even when Kerberos is available for usage between them. This is still very much in the research phase, so please don't e-mail me to ask for it. I hope to publish an article on the topic sometime in the reasonably near future.) As long as NTLM is in existence on a network, Kerberos should not be trusted to protect passwords, because it cannot do so unless it's the only protocol available. Having a bad password on a network with NTLM available is like forfeiting the benefit of Kerberos altogether. Bringing It All Together: SASL, Kerberos, LDAP v2 and LDAP v3 and AD Security Having mentioned all of these technologies, let's answer the question of what SASL, Kerberos, LDAP v2 and LDAP v3 all have to do with AD security. AD is merely the directory that holds all the information. The technologies mentioned above are what protect it and make it function. A security weakness in any of these key technologies represents a huge problem with the integrity of AD security. We've only just touched the surface here by bringing up potential structural issues and there may be more structural issues at hand, resulting in all kinds of vulnerabilities. This article has addressed numerous, seemingly unrelated technologies; however, I would ask readers to keep in mind that this series of articles are intended to be as much an introduction to the topic of AD security as possible. My desire in writing them has been to get people talking, thinking, and researching things about AD security. Each of the technologies addressed in this installment deserves individual scrutiny well beyond the scope that is available in this series of articles. That said, the key message of this article is that readers should understand as much as possible about the components Active Directory before implementing it; otherwise, how secure can users, and their networks, really be? In the Next Installment That concludes this discussion of LDAP, SASL, Kerberos and AD security. Although this has by no means been a comprehensive look at the topic, I hope that it will give readers the basis to be aware of some important security issues. In the next article, "Keys to the Kingdom, the Configuration Naming Context: Some Caveats and Some Issues," will consider a very sensitive portion of the directory and some devious techniques for modifying it. We'll consider modifying it in a relatively quiet, transparent fashion. We'll also consider modifying it in a noisy, site-crashing manner. This is the fourth in a five-part series on auditing Active Directory security. The first article in the series offered a brief introductory overview of Active Directory. The second installment we examined some of the security implications of the ADs default settings. The third article we looked at LDAP, SASL and Kerberos in the context of AD security. This installment will look at some potential security concerns related to the Configuration Naming Context in AD. Content Naming Context

On to the topic at hand! I'd like to note that this particular article has been the longest in development in the series so far; the reason being that playing with the Configuration Naming Context (CNC) tends to crash the directory service, sometimes in very hard-to-recover ways, such as rebuilding the server. Try it yourself, you'll find that, until you become very educated on the topic of programming AD, the bulk of the changes you make will blow up your Active Directory and, most likely, the server(s) housing the directory. The title of this article (specifically the Keys to the Kingdom part) may seem a bit verbose but with good reason. The reason this article considers the CNC to be the proverbial keys to the kingdom is that many critical objects are stored in the CNC. All sorts of replication information is stored in the CNC, a factor that we shall be covering in the next article in this series. The AD schema and DSA behavior, privileges and such are all variables stored in the CNC. Query policies are stored in the CNC, as is information relating to DNS and the directory is also stored in the CNC. Basically, if AD had a brain and a set of operating procedures, it would be called the CNC. Key Components of CNC Well start with a couple of key components or attributes of Configuration Naming Context. While most of the components in the CNC could be considered as important, I am discussing certain components as particularly important because they are crucial to an attack strategy on AD that I developed for this article. I have come across a number of ways that one might attack AD but I consider this particular attack strategy to be the most devious that I know of. Because of the way I have layered the attack, it would be extremely difficult to trace unless AD administrators keep extensive logs backed up on AD access activity or happen across the trigger for the attack fairly soon after the trigger has been planted. So what are the key components of the CNC that I have referred to? Some are simply attributes of sub-contexts of the CNC, like some replication attributes (replUpToDateVector, repsFrom, repsTo,), which govern how components of the CNC replicate from server to server and from database to database within the AD network. Others are sub-contexts or elements of those sub-contexts like DisplaySpecifiers (used in the social engineering example exploit discussed later in this article,) Services, Sites, Partitions, and Extended-Rights, which carries important security information for the directory. Some key components, such as replication, don't really become key components until the directory reaches large scale, as would be indicated by many domain controllers, locations, and forests. A full treatise on the CNC and all of its components would occupy a small book, one that, to the best of my knowledge, has yet to be written by anyone. Hence, we won't enter any extended detail on any of these sections unless they involve the quiet and noisy attacks/modifications to the CNC. We'll start with the quiet attack: Quiet Attacks on CNC This particular attack also utilizes the Microsoft Management Console (MMC) as the ultimate point of execution. The attack is considered quiet because it doesn't directly damage or cause any sort of malfunction in the directory and is not incredibly noticeable. That's not to say that the MMC is necessarily the target of the attack (remember, this is all about the Directory,) it's just the medium used to channel the attack. Consider the following screenshot:

As you can see, the subnet type listed below has been modified to say, "My Father's Name is Mary 2", rather than what it should read, which is, "Subnet". On its own, this is probably fairly innocuous, a simple little joke made to change the directory type listing. This change has been made simply to illustrate that applications may access the directory to determine what and how to behave. However, this little change can get to be fairly serious if implemented properly and creatively. Suppose that rather than modifying the string with "My Father's Name is Mary 2," Subnet were inserted with a "binary blob" (as they call it in AD-ese,) in front of it. Suppose also that this binary blob caused the machine that was running the management console to execute a piece of malicious code in the background, all without the knowledge of the administrator who launched the program and referenced the menu. Now, I'm not saying that modifying this exact section of the directory in this manner would create the capability of yielding such results, but modifying it or other sections could. (Incidentally, the RDN for this particular change is CN=subnet Display,CN=409, CN=DisplaySpecifiers in the CNC, under the attribute classDisplayName.) If you're still unclear as to what, why, or how this works, look at it this way: you may know that Microsoft's MMC is very expandable programmatically. What you may not know is just how expandable it is. You really don't need a buffer overflow to dump in the kind of codebomb I am (vaguely) talking about. Consider the ability to dump this kind of code in as a feature courtesy of Microsoft (like the programmatic/macro features of e-mail with MS Outlook.) What makes this dangerous is that normally an MMC is entirely dependent on local installation and configuration. Lacking some fancy SMS rollouts and some tricky install script tweaking (with malicious intent,) you'd be hard pressed to find a good way to Trojan an entire enterprise's MS administrative controls - until AD, which allows certain portions of an MMC, such as the AD sites and services or AD "User Manager", to be modified to an entire enterprise because portions of the MMC are loaded from the directory itself. The screenshot that you see above isn't the result of modifying a local machine's MMC controls; it's the result of modifying the directory, which is then read by the machine and executed locally. Now, there are certain small formatting bounds for different sections of the MMC: for instance, some sections of the MMC will say that they only interpret, and therefore execute, certain sets of characters or formatting schemes (i.e., ASCII strings versus hex values.) In at least one case, you can actually write a "binary blob" in C and implant it "raw to the directory", and it will work (meaning that, in this case, if you could program malware in C, you'd be fully prepared to infect the directory.)

Therefore, if one presents data (say, in the form of a RAT) to the MMC in the proper format, the MMC will read and execute it, with nearly boundless possibilities. With the current superpowerful nature of the languages/programming features for MMC there is no need for a buffer overflow or some such thing. However, with the current open nature of MMC in general and the lack of documented security testing for it, I wouldn't be surprised if they also exist. I haven't searched for buffer overflows because I didn't need to. So, without providing the actual code-bomb, there you have it. In terms of the formatting and understanding of how MMC executes things that is necessary to pull it off, you can consider it similar in some respects to representing Web requests with a Unicode string. After all, how many people thought that one might be able to manipulate a Microsoft Web server just by presenting it with a differently formatted request? The same principle applies here. The effects of this could be similar to downloading hostile content from Web sites. This is much different in that people know they need to be careful about the nature of sites that they visit, but no administrator is going to think twice before launching his MMC and naively clickety-clicking his or her way into infection/exploitation. Nobody has infected an MMC yet, but now they can and, by so doing, may have an effective means of distribution. The impact could be equal to what the Remote Explorer virus did to MCI a few years ago. However, this requires much less skill to write because the writer doesn't really have to focus on getting the malware to network in the code once it is implanted in the directory - the directory networks the malware. I mentioned in an earlier article in this series that the directory was like one giant living registry. We all know about viruses that base themselves in the registry to some extent, and there is probably a way to fully implant a virus in the registry on a machine that doesn't use AD. There is definitely a way to fully implant a virus in AD, which means that there is a way to get that virus to other machines on the AD network. One thing to note in this example is that, because the administrator has launched this particular MMC snap-in, the code will be executed with high privilege, thereby allowing it to do just about anything (other than going out to get the administrator some coffee.) Some other thoughts on this quiet binary blob payload and an attack strategy... AD is distributed. Suppose one were to code this payload to modify other portions of the directory by self-replicating to them. Suppose that in addition to a self-replication feature, this payload contained some kind of RAT or virus that would replicate itself to nodes on the directory/network (like workstations, or exchange servers) when they access the portions of the directory that have been implanted with the payload. Supposing all that were to be accomplished, the distributed AD would become a means for quietly and effectively distributing attacks. Some would go so far as to consider an AD modified in such a way to be one very large Trojan. This Trojan would be particularly mean and nasty because removing it could risk corrupting the directory and bringing down an entire network, rather than just one workstation. Just imagine the additional bandwidth that would be used up when workstations receive the replication. Also imagine the fact that the Trojan would continue to reinfect machines (or, at least, attempt to) until the directory were replaced or cleaned. Your average system administrator isn't going to have the necessary skill to go in and modify the directory to clean

the Trojan without substantial risk of destroying the directory. (I get panicky just thinking about it!) Nimda and Code Red were death to corporate networks with unauthorized web servers installed inside the network, especially in regard to bandwidth utilization. The solution in there was to remove all the unauthorized Web servers and harden those that were authorized. What's the solution here? Remove the rogue directory? I see a possible need for AD virus scanners and reference-based integrity checkers in the future. Now, as to modifying AD in a noisy, site-crashing manner: well, there are many easy ways to do that - just delete a major subsection of the directory. The deletion DisplaySpecifiers has an especially nifty effect, although in my experience, this will only intermittently result in immediate site crashing (I personally have had intermittent behavior with this.) Deleting DisplaySpecifiers makes it really difficult to administer an AD though, because most of the AD MMC administration software will no longer have any labeling to it! Deleting WellKnown Security Principals or Extended-Rights will usually bring a site to its knees as well. Obviously, deleting the Schema or modifying a critical attribute name in the Schema will also cause serious damage. Caveats and Issues What lessons are to be learned from this? The caveats and issues mentioned in the title are quite simple. The primary caveat being that CMC is not necessarily secure and that systems administrators need to be aware of these potential vulnerabilities. Do you think that Microsoft paid much mind to the security of the actual directory in the creation of AD? It doesn't appear so. Perhaps it is not their main concern, but it is my opinion that particular sections of the directory mentioned in this article should have some additional levels of protection to them, both in the way they are accessed and in the way they function. Until that protection is implemented, I would not before I'd want to subject my network to the level of broad reaching power given by the directory. What are the issues? The issues are that, to the best of my knowledge (and I've done some pretty steady investigation on this point,) nobody in the security community seems to have noticed, let alone developed a solution to this problem. I'll concede that administrative access is required to make changes like this. However, by my experience, gaining administrative access to most NT networks once a person has any sort of access to those networks is not incredibly difficult. Just because AD is now attackable doesn't mean the world ends, it just means that with AD, an attacker with the proper tools and knowledge would have an incredibly potent weapon in his hands. Conclusion Stay tuned for the next article, entitled: A Theoretical Attack on the Multi-Master Replication Scheme in a Massively AD Enabled Network in the Enterprise (a.k.a. what the disgruntled employee/ex-employee could do to really screw up an organization). We'll consider fundamental weaknesses in multi-master replication technology and the impact that has on AD and the security of an AD network. This is the fifth and final installment in a five-part series on auditing Active Directory security. The first article in the series offered a brief introductory overview of Active Directory. In the second installment we examined some of the security implications of the ADs default settings. The third article looked at LDAP, SASL and Kerberos in the context of AD security. The fourth part looked at some potential security concerns related to the

Configuration Naming Context in AD. This article will examine some issues surrounding the multi-master replication scheme. The basis for this article begins with the following question: if two separate nodes on a directory-enabled network commit actions on the same object in the directory at (approximately) the same time, which nodes actions will be considered final, and how will the details be replicated accurately? The purpose of this question is to lay the groundwork for a discussion of the theoretical attack mentioned in the title of this article. Hence, we will first establish a hypothetical scenario that illustrates how and why such an attack may be possible in a generalized multi-master directory service, after which we will jump into a discussion of how Active Directory handles the conditions mentioned in the hypothetical scenario. Upon completion of that discussion, we will discuss how to circumvent Active Directory's controls and make the hypothetical scenario (and worse) happen anyway. A Hypothetical Situation Suppose my fellow system administrator, Bob, and I have both been given a long list of changes that we need to make to our organizations Active Directory. Suppose that neither Bob nor I are aware that the other has a list of changes to make. Bob and I have separately planned to make these changes at the same interval in time during the work-day. Finally, suppose that Bobs list and my list differ slightly on most changes to be made (say, Bob has version 1.0 of the list and I have version 1.1). When Bob and I make our respective changes, what impacts could they have on the directory? Assuming that the directory has no controls in place to deal with activity of this sort, any number of things could happen. The directory could end up with two instances of the same object, a corrupted object, and or an object with some of Bobs changes and some of my changes in effect. Any of these could result in user objects having an amalgamation of rights and/or multiple passwords (among other things). They could also result in critical portions of the directory (whether critical to the system or to the user base, it doesnt matter) getting changed and replicated in such a way to cause serious problems. Replication could be an especially big problem if the changes were made on separate servers posessed of the same replica (as is commonly the case in a multi-master scheme). Ever play the rumor game in which one person whispers something in the ear of another person, who then whispers it to the next person down the line of people, so that the end message sounds nothing like the original? This is much like what could happen in replication. However, the replication cycle would probably be endless (as opposed to the rumor game) as there would never be a finalized copy. This could create a number of problems on a directory-enabled network. For instance, the directory could crash/shutdown, effectively causing network outages (especially if DNS is integrated into the directory). Furthermore, the various master-nodes (replica-carrying servers) could get into contention over which has the most recent object, forcing constant replication, chewing up CPU clock-cycles and bandwidth.

While one might say that the biggest problem underlying this scenario is simply the fact that Bob and I are not communicating adequately to properly coordinate our efforts. In this case, I am giving it serious consideration because it represents a significantly common situation and, therefore, should be addressed. Managing Coincident Changes with Active Directory Active Directory takes a very simple approach to tackling this problem. For the purpose of describing Active Directorys solution to this problem, well consider that the Active Directory network we are talking about here constitutes one site. From here, well note what Active Directory does at each step of the process of Bob and I implementing our respective changes. When I implement my changes at Server A and Bob makes his changes at Server B, each object that we move, add, and/or modify carries a number called an Updated Sequence Number (USN), which is incremented on each server. The same object, on two different servers, carries a unique USN. In addition to that, each servers replica of the directory carries a unique USN that increases in increments every time a change is made to that replicas contents. The servers keep track of their partners replicas USN and the USN(s) of each object/attribute on that partner in order to keep track of change. The general effect that this has is to improve the stability of the overall directory state in regards to data integrity in the replica. It also means that consistency between replicas is maintained more loosely and that automatic (unforced) synchronization is generally much less timely than one might expect. The exception to this consistency rule is if the object in the directory is labeled with an attribute called isCriticalSystemObject, in which case, synchronization is forced. So when Bob and I make our changes to the same data on separate servers at roughly the same time on the same objects and/or attributes, the server with the highest change in USN for each object is treated as the most recent copy for each object and attribute. In other words, the USNs are compared before replication and the highest USN wins. AD replication geeks can poke holes in this example for incompleteness, but, as stated previously, it serves as a basic example for arguing the theoretical attack. For those who would like a more comprehensive explanation, although by no means complete, check out the following URLs: http://support.microsoft.com/servicedesks/webcasts/so_projects/so12/soblurb12.asp http://support.microsoft.com/servicedesks/webcasts/so_projects/so13/soblurb13.asp http://support.microsoft.com/servicedesks/webcasts/so_projects/so14/soblurb14.asp http://support.microsoft.com/servicedesks/webcasts/so_projects/so15/soblurb15.asp The Theory Behind the Potential Attack But how does Active Directory behave when the conditions created by Bob and I become exceptional (i.e., are widely expanded and implemented at much more drastic speeds than usual)? This is where the theory comes into play, and the simplest way to apply the theory is to start changing USNs at random, to random objects, and at rapid speeds. In other words, to accelerate the application of the theory, start changing USNs, objects, and attributes at

random, while always adding the option TRUE to the attribute isCriticalSystemObject, to all objects in the directory. Now, before we start talking about the effects of this on Active Directorys behavior, and the global effect that such behavior will have, lets talk about what is required to commit such behavior. First off, rights that are higher than that of Administrator are required. In order to change USNs at will, Local System authority is required. Otherwise, in order to put the theory in effect, one would have to come up with an engine that would still require at least administrative rights to operate, and would randomly and rapidly request random changes to the objects in the directory, thus effecting changes to the USNs of these objects. With administrator rights, one can still utilize the accelerating effect of isCriticalSystemObject: TRUE. So, having completed all the aforementioned items, stop and take a breath for a moment Now, toss in a replication cycle or two (if the system even makes it past one cycle) By now, I would expect that you realize what this could do to a large, massively AD-enabled organizations network: highly distributed, effective, denial of service to both the network itself and the respective Multi-Master nodes (and all components of desktop operation that require the directory in order to function). By my best estimates, such a denial of service would also be extremely difficult to stop, and even more difficult to repair the damages. Prevention of the Potential Attack Readers who are inclined to consider the effects of this will quickly see that there are a number of ways to spin and or enhance this theorys intent. That much is easy, but how does one attempt to prevent such a thing from happening? I assume that in order to have the time, permissions, and malice to do this, one would have to be a system administrator employee/ex-employee of an organization that owns a sizeable AD enabled network. So the first step in preventing this could simply be considered good, secure, careful internal security administration. However, if all people and all organizations were completely effective at such a thing, distributed denial of service would not be the topic of discussion that it is today. The use of ingress and egress filters to monitor rates of change and change requests in the directory might also be effective at preventing bandwidth blackouts, but I dont believe that such a system (the way I imagine most think of ingress/egress monitors) would prevent a more slow and generalized data corruption that would occur. Having reading this, some will ask: Why waste your time with such a theory when you could just as effectively cause a mass denial of service through other non-electronically-based means (such as bombs, wire cutters, fires, etc)? The explanation is simple and threefold. First of all, I would not discount the possibility of something like this happening, as there is clear record of similar things that have happened in the past (like the chaos that the RemoteExplorer virus/worm wrought, or the script that some disgruntled sysadmin wrote at Company XYZ that went through and randomly deleted files over time). Secondly, discussions of hypothetical situations like this raise awareness of issues that need to be addressed, like the general state of security with Active Directory, small parts of which have already been brought to light both within and without this series of articles. Thirdly, I'm

speculating here, but I'm pretty sure I'm not the only person who has considered such vulnerabilities. In Conclusion To close this series, I hope that this series of articles have raised your level of Active Directory enlightenment and awareness. I sincerely enjoyed the time that I have had researching and writing it all. Despite the criticisms leveled here and elsewhere against AD, and despite its inherent problems, I still hold the opinion that it is a fantastic technology because of its relative ease of use, scalability, and integration. However, as has been mentioned before by others, these things all come with a price greater than the one you pay out of your wallet.