Welcome to Volume 3, Issue 18 of The Internet Security Conference Newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.
TISC is about sharing clue. So is the newsletter. We promise to provide something useful each issue. If we don't, flame me.
Enjoy, and be safe,
Dave
In this issue, Sacha Faust gives an introduction to securing LDAP servers. Like so many Internet applications, LDAP does its thing and leaves security as "someone else's problem". The weakness of this philosophy is obvious: "someone else" always seems to be the administrator. Sacha includes some invaluable links to resources and tools at the end of his column. Enjoy...
The diversity of network components is rapidly becoming a serious issue in corporate networks. Systems that were not originally designed to talk to each other now need to share information to simplify administration. To solve this, many organizations and product vendors are now relying on Lightweight Directory Access Protocol (LDAP)-based directories to store and easily share information across network devices.
LDAP servers solve the sharing problem very effectively, but LDAP wasn’t designed with security in mind, and many vendors don't secure their LDAP installation by default. This leaves the LDAP server very vulnerable to simple attacks. The fact that most LDAP servers will not be directly exposed to the Internet might make administrators feel safe. However, those who rely more and more on LDAP to support critical network operations (e.g., user repository, profile server, configuration information storage) must take the time to secure the underlying server.
[Note: For the purpose of this column, I will only focus on the Netscape (iPlanet) Directory Server because it is the most widely used LDAP server (most iPlanet software uses it). However, the same concepts can be applied to all LDAP directory server implementations. Many other very good alternatives are available; for example, the OpenLDAP directory server.]
The default installation of the Directory server is left quite unsecured. The administrator must change the structure and information "schema" of the Directory information to fit his needs. Thus, there are three things to consider when securing the Directory server:
1. Operating System
2. Application (LDAP Service)
3. Communication (LDAP Client/Server <-> Server)
When Netscape (iPlanet) installs an LDAP Directory Service on a Windows NT platform, no consideration is made for the DACL (Discretionary Access Control List) for the installed files and folders. All the files and folders are installed with what is called "world accessible" in the *NIX community: specifically, the Everyone Group is allowed full Change permissions (Read + Write + Execute + Delete). The Directory Server is built for multi-platform interoperability, and relies heavily on flat (ASCII) text files for configuration information like listening port, administration password, code to load, maintenance scripts, etc.. Giving the Everyone Group the ability to modify files is therefore especially dangerous, given the fact that the service runs as SYSTEM. Administration of the LDAP Directory Service is handled via the Administration Service, so there is no need to allow anyone to manually change configuration files. Removing the Everyone Group and every other user/group except Administrators and SYSTEM from the DACL for each file and folder brings the LDAP Server to a decent security level (presuming all OS security patches and hot fixes are applied). A list of file and folder DACLs and the files you should consider dangerous to leave "world accessible" is available from http://www.smugline.net/zorky/ldap/misc/.
LDAP uses Access Control Instructions (ACI, also called Instances in some documentation) to control access to information inside the Directory Server. ACIs allow the administrator to grant access by user/group, IP address, domain name, authentication method, time of day, etc.. The ACI syntax differs across vendors, so you must read the documentation for your LDAP Directory Server's ACI syntax. Netscape (iPlanet) ACI syntax information is available from http://docs.iplanet.com/docs/manuals/directory/41/admin/acl.htm#1013769 . Careful ACI configuration can address several application-level vulnerabilities; a few are explored here.
Default ACIs for Netscape's LDAP Server allow anyone to view directory configuration information. Output from the LDAPMiner LDAP security tool, when run against a default Netscape Server, gives sobering evidence of how important securing LDAP ACIs truly is. Such configuration information can help an attacker gain a good understanding of the operating system and sufficient information about the Directory Server configuration to help him craft more specific attacks to gain access to the system.
Many ACIs in o=NetscapeRoot (the entry point where the Directory Server stores its configuration) allows anyone to access this information. Here is a example of the default ACI for o=NetscapeRoot that allows anyone to view the Directory Server configuration information :
dn: o=NetscapeRoot
aci: (targetattr="*")(targetfilter=(o=NetscapeRoot))(version 3.0; acl "Default anonymous access"; allow (read, search) userdn="ldap:///anyone";)
The ACI with userdn="ldap:///anyone" should be removed, or access should be restricted to selected groups or users that are really authorized to access this configuration information.
LDAP Servers provide a very useful means of storing user information to create a single sign-on solution for a hybrid network. However, when using Directory Servers as repositories of user information so that other systems can replicate or access such information, one must exercise caution. Here are two examples of things to consider when using the Directory Server for NT authentication (PAM LDAP). The same concept applies to other methods of using the Directory Server to store critical information collected by various systems.
To enable NT authentication using Netscape Directory Server, the Server replicates its user and group information to the NT system that is the authentication authority for the network (i.e., the Primary Domain Controller (PDC) or standalone NT server). This information is replicated by using the Netscape NT Sync service to receive and fetch information from the Directory Server. To do this, a special ntUser objectclass has to be added to the Directory user.
This object class includes attributes from NT user information. Granting users the privilege and opportunity to change NT user information can create serious security problems, because the user information (username, home directory, group, etc.) will be automatically replicated to the NT SAM. A list of sensitive user attributes is available from http://docs.iplanet.com/docs/manuals/directory/schema/oc_hpu12.htm#1301640.
A simple modification to the ACI to prevent users from modifying NT user information and control NT user creation eliminates this vulnerability. A quick way to eliminate this and similar vulnerabilities is to restrict modification of any attribute that starts with "NT". Make sure that no important attributes you are using are unintentionally affected.
For example, to secure the NtUser objectclass attributes used when synchronizing users with an NT system, add the following ACI to the root of your user entry point:
(targetattr != "userPassword || telephoneNumber || nt*")(version 3.0; acl "Allow self entry modification Protecting NtUser attributes"; allow (write)userdn = "ldap:///self";)
The PAM LDAP module uses the posixAccount objectclass attributes to get its information. A list of specific attributes is available from http://docs.iplanet.com/docs/manuals/directory/schema/oc_hpu12.htm#1278312. Included among these attributes are the uidNumber and gidNumber. Since all attribute values can be changed, the action of setting uid and gid to 0 basically lets a user become whomever they want on the system that relies on the Directory Server for credential information. By preventing access to uidnumber and gidnumber in the ACI, an attacker will not be able to change his user level on the system using PAM LDAP for authentication. An efficient way to accomplish this is to add the uidnumber and gidnumber attributes to the list of attributes that a user cannot change; for example, add the following ACI in the root of your user entry point from the previous ACI that secured the NtUser attributes:
(targetattr != "userPassword || telephoneNumber || nt* || uidnumber || gidnumber")(version 3.0; acl "Allow self entry modification Protecting posixAccount and ntUser attributes"; allow (write)userdn = "ldap:///self";)
The LDAP protocol is a cleartext protocol. Communication between Directory hosts is not encrypted and can be viewed by others with access to the network that carries this communication. LDAP communications often contain sensitive information that should not be seen by just anyone. The LDAPS (LDAP over SSL) protocol should be used to secure communication between hosts exchanging LDAP information to be certain that this information is encrypted during transfers. Most vendors support LDAPS. If your LDAP vendor does not, consider using VPN technology such as IPsec between sites that share LDAP information. Client-Server LDAP communication should also be encrypted (and authenticated), so consider using IPsec here as well. You may also wish to change LDAP vendors: any decent LDAP server should support LDAPS.
There are many security considerations beyond those discussed in this overview column. Take the time to consult some of the URLs mentioned below if you are considering using a LDAP Directory Server in your network environment.
Solaris 8 LDAP Setup and Configuration Guide
LDAP Overview by Bruce Greenblatt
Why LDAP & Security Are Critical to Your Success
Information on Default Netscape Directory Server settings
Securing Netscape Directory Server paper by Sacha Faust ( work in progress )
LDAPMiner is an LDAP information collection tool.
NetscapeGetACL will show you all the ACIs on your Netscape Directory Server.
LDAPRootDSE will show you the information contained in your LDAP v3 RootDSE.
LDAP Browser/Editor is a basic LDAP browser and editor written in Java. It can be very useful to manually modify directory information or to browse the directory.
Sacha is now working as a Technical Security Director for PricewaterhouseCooper in Canada. Prior in joining PWC, Sacha joined Itemus Solutions as a Senior Internet Security consultant. As a senior security consultant, Sacha as been part of security contracts for large organizations and has helped Itemus R&D build a new kind of Digital Service Provider model for Business Web services. Prior in joining Itemus, Sacha held positions in the parent company of Hartco Enterprises, where he contributed to the cutting edge of network security automation as the Director of Research and helped the consulting and software side as an effective Technical director.