Endpoint Protection

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 AD’s 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

We’ll 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 code-bomb 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 super-powerful 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.