By Tony Lee
Introduction:
Lightweight Directory Access Protocol (LDAP) is a powerful and often critical component in most large networks. But as you already know, centralized authentication and user management is a double-edged sword. On one hand, managing all users and objects in a central location makes user management much more efficient—for example, there is less chance of forgotten user accounts and unenforceable password policies across multiple devices. On the other hand, all attributes and eggs are in one basket—meaning a misconfigured basket could leave your eggs quite exposed.
Outline:
- Default findings
- Explanation
- Consequences
- Popular LDAP implementations
- How to validate
- Countermeasures
- Conclusion
Default findings
Regular use of vulnerability scanners is a critical part of a proactive layered defense. The goal is that network administrators will find vulnerabilities and remediate them before an attacker has an opportunity to exploit them. Most will agree that it makes sense to work your way down from the top to the bottom—starting with the high risk findings and moving to the lows. This is great except that most organizations put too much weight in the default risk score. Additionally, we notice that some organizations do not even bother examining or remediating anything that is not a high risk finding. This article will hopefully stress the importance of regularly using a vulnerability scanner and remediating all findings—not just the high risk ones.
Why make this point?
Nessus and McAfee Vulnerability Manager (MVM) are two very popular and robust vulnerability scanners. Both of them are able to find misconfigured LDAP servers and produce findings such as:
LDAP NULL BASE Search Access – Medium Risk (CVSS Base Score : 5.0)
LDAP Server NULL Bind Connection Information Disclosure – Medium Risk (CVSS Base Score : 5.0)
Explanation
If you perform regular vulnerability scans and discover that your LDAP server suffers from these issues, what do they mean?
NULL Base Search
An LDAP server that allows a NULL base search means that the attacker does not need to know a base object before querying. A very good explanation can be found here:
“LDAP implementations are required to return some information as a result of a search. This information is required for LDAP clients to bind and interact with the directory. When this event occurs, users can dump the base of the tree or issue a request without knowing the base object. LDAP implementations vary on how or whether it is possible or necessary to constrain or prevent NULL base requests. Some implementations use an access control list (ACL), others provide the ability using a utility program or user interface, and others may not be able to prevent these requests.”
NULL/Anonymous Bind
An LDAP server that allows anonymous binds does not require any type of credentialed authentication. Specifically:
“The NULL bind entry allows a user to access the Lightweight Directory Access Protocol (LDAP) directory anonymously. An attacker could take advantage of the NULL bind entry to anonymously view files on the LDAP director.”
Note that as mentioned in our statement above, many organizations will not, or cannot (sometimes due to time or resource constraints) remediate anything lower than the high risk findings. But these LDAP findings shown above default to medium risk, so what is the big deal?
Consequences
In the past few years, we cannot tell you how many LDAP findings we have encountered (just like the ones above). However in a handful of instances these medium risk vulnerabilities turned into a high risk finding (maybe even ludicrous! – <insert popular nerd movie reference>). The irony is that in both situations below, the organizations regularly used vulnerability scanners and were proactive about remediating the findings. However, both organizations had resource and/or policy limitations which allowed them to only remediating the high risk findings.
Let’s examine the two instances:
Instance 1:
This is one of the most egregious misconfigurations we have seen to date, but others are not far off. This group of misconfigured LDAP servers contained the following information:
- All users in the environment
- First and last name
- Email
- Default shell
- Home directory
- Username
- Password!
Figure 1: Real-world scenario in which LDAP held the keys to the kingdom.
With this information we could log into any host as any user—thank you centralized authentication.
Instance 2:
This was not quite as bad as the first instance, but it is still significant as it exposed Personally Identifiable Information (PII) including first and last name, middle initial, personal phone numbers, usernames, titles, salary information, and last password change date.
Figure 2: Personally Identifiable Information (PII) leakage via LDAP
Popular LDAP implementations
When deploying LDAP, you have a multitude of vendors to choose from. Due to the prevalence of Microsoft Windows environments we mostly see Windows Active Directory, however, they are not the only game in town. We often encounter a significant amount of Sun Directory Services, Novell Directory Services (NDS), and OpenLDAP.
Microsoft Windows Active Directory
Microsoft has historically not done very well in protecting LDAP data. However, with each release of Windows they become more security conscious. Windows 2000 had much of the same information disclosure issues that we have seen above. Windows 2003 has had less of an issue with this unless intentionally misconfigured. Finally, Windows Server 2008 has had even fewer issues.
Sun Directory Services
Often when we have an information disclosure issue, it is a misconfigured Sun Directory Services server. When first binding to the LDAP server, it will generally tell you the version of LDAP running. This is helpful when making note of trends.
Novell Directory Services (NDS)
We do not seem to encounter these as often as we did about 3 years ago as they are most likely losing market share. However, the companies that do have them were at one point huge consumers of Novell and may have legacy applications around that are still utilizing this infrastructure. As with the Sun Directory Services server, this usually synchronizes with Windows Active Directory. So, even if you cannot query the data out of the Windows LDAP servers, you can get a copy from a misconfigured NDS.
OpenLDAP
While this is certainly an LDAP option, we have not run into many that have been misconfigured in a large enterprise. Though, we would love to hear feedback from others who have more experience dealing with them.
How to validate
When testing these findings, we will generally use Softerra’s LDAP Browser (http://www.ldapbrowser.com/info_softerra-ldap-browser.htm). It is a free Windows application that is read-only and object-limited compared to Softerra’s commercial product called LDAP Administrator. Even though it is limited, it often efficiently completes the task of validating the severity of the LDAP findings. The connection profile wizard will walk you through setting up connection options in less than 30 seconds as shown in the screenshots below:
Figure 3: Softerra LDAP Browser setup for NULL base
Figure 4: Softerra LDAP Browser anonymous bind
If you are more Linux oriented, you could use a number of Linux tools, including ldapsearch. Its syntax would resemble the following:
ldapsearch -x -s base -b '' -H ldap://my.lapdap.server "(objectClass=*)" "*" +
Options explanation:
-x = simple authentication
-s = scope is defined as base
-b = search base
-H = specify LDAP uri
Countermeasures
Countermeasures here include restricting anonymous binds and NULL base searches. However, as with any potential remediation this should be tested in a development or QA environment to ensure that there will be no adverse side effects. Extra care should be taken when applications are utilizing LDAP for user authentication or information lookup. Locking down the LDAP server without testing the applications could result in many angry users.
Conclusion
In this article, we have illustrated very common LDAP findings that may not get the attention they deserve based on their default risk rating. We are not necessarily advocating raising the default risk rating because many times this check turns out to be less serious than the two scenarios highlighted above. The problem is that machines are not always able to intelligently determine the severity of the findings. This should indicate that companies and security practitioners that utilize vulnerability scanners need to be especially careful to validate and remediate as many of the findings as they can—not just the high risk ones. They can then determine an appropriate risk management strategy.
Have you ever run into this finding and discovered gold? Do you have any other “Medium/Low/Informational” findings then ended up being critical? All comments are appreciated; feel free to leave them below. Happy hacking!
Special Thanks
Dan Dumond
Dennis Hanzlik
Rudolph Araujo
Great article :D
ReplyDeletegracias!!
ReplyDelete