If you're an infrastructure-oriented security professional, the focus on application security in IT these days may leave you feeling out of the loop. However, in many cases, application security pros rely on the infrastructure team to provide a secure foundation. Naming and directory services are one of the primary areas where this holds true.
In this tip, we'll look at how securing one such naming and directory service, Lightweight Directory Access Protocol (LDAP), will help build a solid platform that applications can trust.
LDAP is used extensively by both internal and external applications to provide user directory services with a wide variety of platforms. LDAP can provide authentication services, aid applications in authorization and access control decisions by representing membership in application-specific roles, and can also be used to store general information for user preferences and entitlements.
Microsoft Active Directory provides an LDAP interface to Windows-specific user data, and both Active Directory and its lighter cousin, Active Directory Application Mode (ADAM), are used by applications as primary data stores for user information. Other options for user directory services include the OpenLDAP project, and enterprise software, such as IBM Lotus Domino and Novell e-Directory, are often extended through the use of LDAP.
Securing LDAP requires an initial threat assessment to find out how it is being used in a specific application environment. If the protocol is used for authentication or access control decisions, several potential threats must be addressed. Top threats for this scenario include interception of LDAP traffic, disclosure of user credentials, excessive privileges abused by anonymous or standard user roles, and errors caused by overreliance on LDAP data.
There are ways to harden an LDAP installation against each of these threats. First off, all LDAP connections should be restricted to use only transport layer security, usually SSL, to prevent interception of credentials. Microsoft also supports encryption of the LDAP query and response through the client and server integrity configuration options.
However, transport-layer encryption that does not have a strict server certificate validation policy for each client is not sufficient to protect credential theft from a man-in-the-middle attack. LDAP authentication can use a variety of authentication mechanisms, including submission of a user's credentials directly to the server in plaintext, digest authentication, Kerberos or a challenge-response mechanism. Use of Kerberos or challenge-response is recommended, especially if transport layer encryption is not supported.
Additionally, if LDAP stores user passwords in the datastore (usually hashes of the passwords), they can be retrieved from the LDAP directory by anyone if permissions are not set correctly. Only privileged applications should be able to query this value and deny access to anonymous or standard user profiles.
If you use a specialized LDAP installation that is not intended for use by end users or if all of your users are on a single authentication platform such as Active Directory, you should consider disabling anonymous binding to the LDAP directory. Failure to do so will result in information disclosure, including user information, and in the case of Active Directory, some basic configuration information about the datastore.
When applications extend the LDAP directory schema to include data fields specific to the application's functionality, the application ID used to access LDAP should be added into a group that is authorized to query those specific fields and deny access to other users and group roles.
There are two specific security risks relating to directory architecture and integration that will require collaboration between the application team and infrastructure security professionals. In these cases, there should be a review process and set of guidelines for the use of LDAP across the teams. The first issue is LDAP injection, which is an application-layer vulnerability similar to SQL injection. If the application accepts user input and places it directly into an LDAP query, the vulnerability may be present.
The second issue is the use of LDAP for access control decisions instead of user identification, group membership and property retrieval. LDAP entries for users that explicitly state access control rules are indicative of this problem. Developers should keep access control lists local to the application's configuration data, and leverage LDAP to identify the user and group membership and provide non-security context around the user's identity.
A cautionary point: While a given directory service may only be used as a limited deployment in a couple of applications to start, these resources often organically grow to take on more responsibility and perform critical security functions for important applications. As a result, it's better to design some of the security controls at deployment instead of retrofitting them in later when applications may break.
For more information on LDAP security, take a look at the Microsoft Best Practices document on Active Directory and the Center for Internet Security's Benchmark for OpenLDAP.
About the author:
Cory Scott is the regional director for consulting services at Matasano Security.
This was first published in February 2010