|
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.
To read An Audit of Active Directory Security, Part Four: Keys to the Kingdom - the Configuration Naming Context , click here.
|