Blog

Database Password Pen Testing

By Adrian Lane

A few years back I worked on a database password checker at the request of my employer. A handful of customers wanted to periodically audit passwords, verifying that they complied with their password policies. As databases can use internal password management – outside the scope of primary access control systems like LDAP – they wanted auditing capabilities across the database systems. The goal was to identify weak passwords for service and general database user accounts. This was purely a research effort, but as I was recently approached by yet another IT person on this subject, I thought it was worth discussing the practical merits of doing this.

There were four approaches that I took to solve the problem:

  1. Run the pen test against the live database. I created a password dictionary and tried to brute force known accounts. The problems of user account discovery, how to handle databases that supported lockout on failed login attempts, load on the database, and even the regional nature of the dictionary made this a costly choice.

  2. Run the pen test against a mirrored or VM copy of the database. Similar to the above in approach except I made the assumption I had credentialed access to the system. In this way I could discover the local accounts and disable lockout if necessary. But this required a copy of an entire production database be kept, resources allocated, logistical problems in getting the copy and so on.

  3. Hash comparisons: Extract the password hashes from the database, replicate the hashing method of the database, pre-hash the dictionary, and run a hash comparison of the passwords. This assumes that I can get access to the hash table and account names, and that I can duplicate what the database does when producing the hashes. It requires a very secure infrastructure to store the hashed passwords.

  4. Use a program to intercept the passwords being sent to the database. I tried login triggers, memory scanning, and network stack agents, all of which worked to one degree or another. This was the most invasive of the methods and needed to be used on the live platform. It solved the problem of finding user accounts and did not require additional processing resources. It did however violate separation of duties, as the code I ran was under the domain of the OS admin.

We even discussed forgetting the pen test entirely, forcing subsequent logins to renew all password, and using a login trigger to enforce password policies. But that was outside the project scope. If you have a different approach I would love to hear it.

As interesting as the research project was, I’m of the opinion that pen testing database passwords is a waste of time! While it was technically feasible to perform, it’s a logistical and operational nightmare. Even if I could find a better way to do this, is it worth it? A better approach leverages enforcement options for password length, attributes, and rotation built into the database itself. Better still, using external access control systems to support and integrate with database password management overcomes limitations in the database password options. Regardless, there are some firms that still want to audit passwords, and I still periodically run across IT personnel cobbling together routines to do this.

Technical feasibility issues aside, this is one of those efforts that, IMO, should not ever have gotten started. I have never seen a study that shows the value of password rotation, and while I agree that more complex passwords help secure databases from dictionary attacks, they don’t help with other attack vectors like key-loggers and post-it notes stuck to the monitor. This part of my analysis, included with the technical findings, was ignored because there was a compliance requirement to audit passwords. Besides, when you work for a startup looking to please large clients, logic gets thrown out the window: if the customer wants to pay for it, you build it! Or at least try.

No Related Posts
Comments

Adrian, I believe that #3 is feasible and moreover easy to implement technically.
The password algorithms for all major database vendors are known. Retrieving the hashes is simple enough (using a simple query). You don’t have to store the hashes anywhere (just in memory of the scanning process). With today’s capabilities (CUDA, FPGA, etc.) you can do tens of millions of password hashes per second to even mount brute-force attacks.

The real problem is what do you do then? From my experience, even if you find weak passwords, it will be very hard for most organizations to change these passwords.
Large deployments just do not have a good map of who connects to what and managers are afraid that changing a password will break something.

Just my 2 cents…
Slavik

By Slavik Markovich


Adrian

It’s true the options are not pretty.

A modified approach for #1 is to export only the tables that store the user account information (including hashes).  A mini-clone DB can be built quickly and then whatever level of live checking you desire can take place.

The problem I consistently see when people rely on platform policy controls is that not everyone plays along (hello DBA, I’m looking at you!).  Those problems go hidden until the pen-test team shows up…

Cheers

Craig

By Craig Balding


If you like to leave comments, and aren’t a spammer, register for the site and email us at info@securosis.com and we’ll turn off moderation for your account.