We’ve all got password policies.  In fact, if there’s one policy that your company has in the IT Security arena, it’s probably a password policy!  We require all kinds of things of our users.  You have to pick a password that’s at least eight characters long, includes upper and lower case, has at least one number or a special character, etc., etc.  Even with all of this, there’s an enormous vulnerability in our deployed systems that our security personnel tends not to notice.  What if I told you that there’s a trick that I use when performing penetration tests that always recovers at least five percent of the accounts in the domain without requiring that I capture the password hashes and that can be performed without locking out anyone?  If you want the answer, read to the end!

What this technique is based on is a failure to really think through the complete problem of authentication.  In fact, most organizations write policy and train users in security awareness about only a part of the authentication equation and this leads to a rather sizable vulnerability that we’ve probably ignored.  The problem is that we’re only paying attention to half of the authentication problem.

“What problem?”, you ask?  The username/password equation.  In our policies we tend to put all of our energy, or at least the vast majority, into the selection and protection of a password.  To be frank, whatever policy you create for passwords I can promise you that some user somewhere can select a password that completely adheres to your policy yet is obviously an extremely poor password.  For example, when we require the standard three out of four (upper, lower, number, special), which seems like a great starting point and which is the standard almost everywhere, I guarantee that you will find users selecting “Password1”, which meets all of the requirements.  Indeed, if you enable password histories with forced password changes, their next most likely password will be “Password2”.  You can see where this is going.

In any event, back to the equation.  We focus on the password half of the authentication problem, but tend to overlook the sensitivity of the username.  If I can discover the most complex password every created but I lack the username for which it is the key that password has no value.  In fact, you can turn this problem around in your head for a second.  If we kept our usernames secret, we could theoretically tell people our password with no enormous risk of compromise.

I’m sure there’s some part of you that fights against the logic of that last sentence.  Even if we kept our usernames secret, there’s something in us that tells us that passwords still have to be secret.  That’s fine, but see if you can apply that same logic to the username.  What makes it any less sensitive?  The real answer is that it is equally sensitive, but because we tend to base them on common schemes (first initial last name, first initial middle initial last name, etc.) we don’t view them as sensitive even though they are.

So what can we do with this bit of reasoning?  One thing is that we can use it defensively to demonstrate to people why selecting strong passwords matters.  Let’s take a moment and examine how we could leverage this information if we were a less than honorable employee in an organization.

If we wanted to compromise other accounts in our company, we have everything we need without requiring extra permissions or rights.  First of all, we’ll want to find out what our password lockout policy is.  This is pretty easy to do.  If you’re somewhat technical, you can easily discover the password lockout policy by querying your local system or examining the group policies that apply to you.  Let’s assume that accounts lock out after six bad password attempts.

The next thing we need is a list of usernames to attack.  Again, this is a simple problem.  If we were to imagine a Windows infrastructure, we could use the free Microsoft Admin Pack tools for 2003 or 2000 Server to run DSQuery and DSGet.  For instance, we could do something like this:

dsquery user -limit 0 > fdn_users.txt
for /f "skip=1" %%i in (fdn_users.txt) do dsget user %%i -samid >> UserIDs.txt

The first command extracts all of the fully qualified user names from the Active Directory.  This, by the way, requires no special rights or permissions in the domain.  Any user can extract this data provided that we haven’t added access controls to our schema (which is pretty unusual in practice in my experience).  The second line uses a simple “for” statement to loop through the results file and to query the actual SAM account name for each user that was discovered.  Voila!  We now have half of our username/password formula.

What about the other half?  Let’s take what we know about users and their behavior.  That is, we know that regardless of our policies, some users will find a way to pick a poor password.  We might start with our example password formula (Password1).  Now we’re not going to write the script for you to go and recover accounts with, but how difficult would it be to do something like this in a script and use the exit code to test for success?

for /f %%i in (UserIDs.txt) do TryUser.bat %%i

And in a script named TryUser.bat to do something like this (This won’t work as is...):

net use \\domain_server\NetworkShare /user:%%1 Password1
if( not successful ) {
    net use \\domain_server\NetworkShare /user:%%1 Password2
    } else if( not successful ) {
       net use \\domain_server\NetworkShare /user:%%1 Password3
        } else if( not successful ) {
           net use \\domain_server\NetworkShare /user:%%1 Password4
            }
        }
    }

The only thing actually missing (aside from working code is a test that we were successful that then reports the users with weak passwords.  If nothing else, this should serve to illustrate how serious selection of a good password is.  It might be worthwhile to include a discussion or demonstration of this type of technique in a security awareness training environment.  Of course, the danger is that you might be giving people good ideas of how to attack your own network!

Of course, the real beauty of this type of test (which is an excellent thing to do during a penetration test) is that we never violate the account lockout policy.  It also doesn’t require us to actually recover the password hashes and break them.  Instead, we start with one captured account and leverage that into a family of compromised accounts very quickly.  From there, it’s really only a matter of time, but we’ve managed to fly under the radar.  Unless someone is watching for multiple password failures from a single system (that don’t actually lock out) we won’t be discovered.

Even so, it is important that we stop viewing this as simply a password problem but instead we must view it as a complete problem.  Both halves of the equation are equally important.  Users must learn to protect both and to select passwords that will fail this type of test.